AEAD Encryption Types for Kerberos 5
draft-howard-krb-aead-00

Abstract

This document updates RFC3961 to support encryption mechanisms that can authenticate associated data, such as Counter with CBC-MAC (CCM) and Galois/Counter Mode (GCM). These mechanisms are often more performant and need not expand the message as much as conventional modes.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on June 15, 2016.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Requirements notation
• 3. Authenticated Encryption with Associated Data (AEAD) Overview
• 4. Updates to RFC 3961
• 4.1. Additional Requirements
• 4.2. Removal of Mandatory Requirements
• 4.3. Application-managed Cipherstate
• 4.4. Encrypt/decrypt with Associated Data
• 4.5. AEAD with Simplified Profile
• 5. Native AEAD Algorithm Profiles
• 5.1. Protocol Key Representation
• 5.2. Key Derivation Functions
• 5.2.1. Common Definitions for Key Derivation
• 5.2.2. KDF for AES-GCM and AES-CCM
• 5.2.3. KDF for chacha20-poly1305
• 5.3. Cipherstate Chaining
• 5.4. Common Profile Definitions
• 5.5. aes128-gcm-128
• 5.6. aes256-gcm-128
• 5.7. aes128-ccm-128
• 5.8. aes256-ccm-128
• 5.9. chacha20-poly1305
• 6. Security Considerations
• 7. IANA Considerations
• 8. Acknowledgements
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Author's Address

1. Introduction

This document updates [RFC3961] for encryption mechanisms that support Authenticated Encryption with Associated Data (AEAD), such as Counter with CBC-MAC (CCM) and Galois/Counter Mode (GCM). These mechanisms provide the ability to authenticate additional data associated with a plaintext.

In addition, these mechanisms often have performance advantage over conventional encryption modes such as Cipher Block Chaining (CBC) and Ciphertext Stealing (CTS) as they can be efficiently parallelized and the absence of a confounder allows for shorter messages. For example, the ciphertext output by the AEAD encryption mechanisms described in this document is 28 bytes shorter than those specified in [RFC3962].

2. Requirements notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Authenticated Encryption with Associated Data (AEAD) Overview

[RFC3961] provides for authenticated encryption of plaintext in Kerberos 5, that is, it provides both for confidentiality and a way to check the for integrity and authenticity of a message. Some applications can benefit from protecting the integrity and authenticity of unencrypted data accompanying a ciphertext: this is termed Authenticated Encryption with Associated Data (AEAD). (A general description of AEAD is given in [RFC5116].)

Existing encryption and checksum mechanisms can provide AEAD through generic composition, where the checksum is made over both the associated data and plaintext. Alternatively, modern encryption mechanisms such as those profiled in [RFC5116] explicitly provide for AEAD. Both approaches are discussed in this document.

Algorithms that are specifically designed for AEAD may have additional constraints to be imposed on cryptosystems that would otherwise be definable in terms of [RFC3961]. We term these algorithms native AEAD, to distinguish them from the generic composition of non-AEAD encryption and checksum types.

4. Updates to RFC 3961

The changes described below amend [RFC3961] for use with native AEAD encryption types.

4.1. Additional Requirements

The native AEAD algorithms profiled in [RFC5116] and [RFC7539] have the property where the reuse of a particular combination of secret key and initialization vector destroys all security guarantees of the underlying mechanism. This contrasts with existing Kerberos ciphers such as those defined in [RFC3962] where the random confounder (used instead of an initialization vector) need not be non-repeating.

To accommodate the use of native AEAD cryptosystems with Kerberos, we allow an encryption mechanism profile to adjust its behavior depending on whether a long-term is being used. It is valid for a profile to not support long-term keys.

Where an ephemeral key is used, applications MUST guarantee that each invocation of the encryption function with a particular key will use a unique cipherstate. (An example of an ephemeral key is the subkey present in an AP-REP message.)

Native AEAD encryption types share the same namespace as existing Kerberos algorithms so they may take advantage of existing cryptosystem negotiation facilities such as [RFC4537].

4.2. Removal of Mandatory Requirements

[RFC3961] requires that an encryption mechanism profile define both an associated checksum type and a string-to-key function.

Native AEAD algorithms do not provide for integrity protection outside of authenticated encryption, so we remove the requirement for an associated checksum type. (An application that only requires integrity protection may invoke the authenticated encryption function with a zero length plaintext.)

These ciphers are not required to support long-term keys, so we remove the requirement that a string-to-key function be defined.

4.3. Application-managed Cipherstate

Whilst [RFC3961] requires that the cipherstate be opaque to the application, we relax this so that the application may manage some or all of the cipherstate explicitly. Native AEAD ciphers SHALL nominate how many bits of their cipherstate may be deterministic and, by extension, may be managed by the application. (The encryption types defined in this document allow all bits of the cipherstate to be managed by the application.)

In order to meet the security requirements of the underlying cryptosystems, applications using ephemeral keys MUST NOT invoke the authenticated encryption function with a previously used (key, cipherstate) combination.

Applications that support native AEAD ciphers MAY impose a minimum deterministic octet length requirement on the cipherstate. Such applications MUST NOT be used with ciphers with a shorter cipherstate length.

Applications MAY set the deterministic cipherstate component directly on each invocation of the authenticated encryption function. This allows a non-repeating counter such as a sequence number to be embedded in the cipherstate, without preventing the application from processing out-of-order messages. Alternatively, an application MAY set the initial cipherstate to a random value and pass the cipherstate output from the authenticated encryption and decryption functions to subsequent invocations. Using a randomly generated cipherstate on each invocation may place a limit on the number of invocations of the authenticated encryption function when compared with a deterministic construction.

4.4. Encrypt/decrypt with Associated Data

We define the following functions for encrypting and decrypting with associated data:

• encrypt-with-ad (specific-key, state, associated data, octet string, is-longterm)->(state, octet string)
• decrypt-with-ad (specific-key, state, associated data, octet string, is-longterm)->(state, octet string)

The associated data parameter is input only and contains data that is to be authenticated, but not encrypted. If the associated data or plaintext are zero length strings, then these functions are equivalent respectively to the checksum and encryption functions described in [RFC3961].

[CREF1]NB: these functions only allow a single associated data and plaintext buffer to be supplied, which is not compatible with applications such as DCE RPC that interleave the associated data and plaintext buffers. Support for such applications is implementation dependent and not guaranteed to work with native AEAD ciphers that only take a single buffer of each.

The boolean is-longterm parameter indicates whether specific-key is a long-term key or a session key.

Correspondingly, the encrypt and decrypt functions are updated to take the is-longterm parameter, which shall be ignored for non-native AEAD encryption types:

• encrypt (specific-key, state, octet string, is-longterm)->(state, octet string)
• decrypt (specific-key, state, octet string, is-longterm)->(state, octet string)

4.5. AEAD with Simplified Profile

We allow the authentication of associated data with existing cryptosystems that follow the Simplified Profile defined in [RFC3961] through the generic composition of the encryption and checksum functions. The is-longterm parameter is ignored. For consistency with [RFC3961] the following definition uses 1-based indexing.

encrypt-with-ad    conf = Random string of length c
                   pad  = Shortest string to bring confounder
                          and plaintext to a length that's a
                          multiple of M
                   (C1, newIV) = E(Ke, conf | plaintext | pad,
                                   oldstate.ivec)
                   H1 = HMAC(Ki, conf | associated data |
                             plaintext | pad)
                   ciphertext = C1 | H1[1..h]
                   newstate.ivec = newIV

decrypt-with-ad    (C1, H1) = ciphertext
                   (P1, newIV) = D(Ke, C1, oldstate.ivec)
                   conf = P1[1..c]
                   signdata = conf | associated data | P1[c+1..]
                   if (H1 != HMAC(Ki, signdata)[1..h]))
                       report error
                   newstate.ivec = newIV

5. Native AEAD Algorithm Profiles

This section defines native AEAD profiles for using the AES-GCM, AES-CCM and chacha20-poly1305 algorithms with Kerberos. This specification does not define the encrypt-with-ad and decrypt-with-ad functions for the case where is-longterm is true; implementations MUST raise an error if invoked with a long-term key.

5.1. Protocol Key Representation

Because the key spaces for the cryptosystems defined below are dense, random or pseudo-random octet strings are used directly as keys.

5.2. Key Derivation Functions

5.2.1. Common Definitions for Key Derivation

The key derivation functions from [SP800-108] Section 5 are used.

key:

The initial session key from which subsequent keys are derived

label:

An octet string describing the intended usage of the derived key

i:

A counter, expressed as four octets in big endian order

k:

The length in bits of the key to be outputted, identical to the length of the original key, expressed as four octets in big endian order.

k-truncate:

As defined in [RFC3961] Section 5.1.

The | operator indicates concatenation.

5.2.2. KDF for AES-GCM and AES-CCM

The GCM and CCM profiles defined below use the counter/feedback key derivation function from [SP800-108] Section 5.2, using CMAC as the PRF with either AES-128 or AES-256 (depending on the input key). The composition is given below:

K0:

all zero bits

Ki:

CMAC(key, K(i-1) | i | label | 0x00 | k)

KDF-CMAC(key, label) = k-truncate(K1 | K2...)

The iteration count i is one for AES-128 keys and two for AES-256 keys.

5.2.3. KDF for chacha20-poly1305

The chacha20-poly1305 profile defined in Section 5.9 uses the counter mode key derivation function from [SP800-108] Section 5.1, using HMAC-SHA-256 as the PRF. The composition is given below:

K0:

all zero bits

Ki:

HMAC-SHA-256(key, i | label | 0x00 | k)

KDF-HMAC-SHA256(key, label) = k-truncate(K1)

5.3. Cipherstate Chaining

Kerberos applications using native AEAD cryptosystems may choose to explicitly compose the cipherstate (for example, from a sequence number). However the only requirement imposed by this profile is that the application guarantee that the combination of key and deterministic cipherstate be unique for a particular invocation of the authenticated encryption function. For the encryption types defined in this section, all bits of the cipherstate may be managed by the application.

An application MAY use the output cipherstate from encrypt-with-ad and decrypt-with-ad in subsequent invocations of those functions. For the profiles defined in this section, the output cipherstate is composed as follows:

D[N..M]

M - N + 1 octets of D, starting at octet M (1-based)

fixed

oldstate[1..4]

counter

oldstate[5..12]

newstate

fixed | counter + 1

The + operator indicates addition of 64-bit integers expressed as eight octets in big endian order, raising an error after 2^64 invocations. (Note that the application may specify a non-zero initial cipherstate, so the implementation must check the invocation count for overflow rather than the cipherstate counter.) This composition is compatible with the recommended nonce formation defined in [RFC5116] Section 3.2.

Note also that the invocation counter described above is independent of the block counter implemented by the underlying encryption function.

5.4. Common Profile Definitions

The following parameters apply to all the encryption types defined below.

protocol key format: as defined in Section 5.1

specific key structure: one protocol format key, Ke

required checksum mechanism: none

key generation functions

string-to-key function: none

random-to-key function: identity function

cipherstate: a 96-bit initialization vector

initial cipherstate: all bits zero, or specified by application

subsequent cipherstate: the previous cipherstate incremented by one per Section 5.3

empty: the empty (zero length) octet string

encrypt (specific-key, state, octet string, is-longterm): encrypt-with-ad (specific-key, state, empty, octet string, is-longterm)

decrypt (specific-key, state, octet string, is-longterm): decrypt-with-ad (specific-key, state, empty, octet string, is-longterm)

5.5. aes128-gcm-128

This profile is based on [RFC5116] Section 5.1. The GCM authenticated encryption algorithm works as specified in [GCM] Section 7, using AES-128 as the block cipher. A key length of 16 octets (128 bits) is used, along with an authentication tag with a length of 16 octets (128 bits).

The following parameters apply to the aes128-gcm-128 encryption type:

key-generation seed length: key size (128 bits)

key-deriviation function: KDF-CMAC as defined in Section 5.2.2. The key usage number is expressed as four octets in big endian order.

Ke = KDF-CMAC(base-key, usage | 0xAA)

encrypt-with-ad function: AES encryption in GCM mode using Ke

decrypt-with-ad function: AES decryption in GCM mode using Ke

pseudo random function: PRF = KDF-CMAC(base-key, "prf" | octet-string)

5.6. aes256-gcm-128

As for aes128-gcm-128, but using AES-256 as the block cipher and with key and key-generation seed lengths of 32 octets (256 bits).

5.7. aes128-ccm-128

This profile is based on [RFC5116] Section 5.3. The CCM authenticated encryption algorithm works as specified in [CCM] Section 6, using AES-128 as the block cipher. A key length of 16 octets (128 bits) is used, along with an authentication tag with a length t of 16 octets (128 bits). The nonce length n is 12 octets, and the corresponding counter length q is 3 octets. (Note that this imposes a maximum message size of 2^24 blocks, which may be unacceptable to some applications.)

The following parameters apply to the aes128-ccm-128 encryption type:

key-generation seed length: key size (128 bits)

key-deriviation function: KDF-CMAC as defined in Section 5.2.2. The key usage number is expressed as four octets in big endian order.

Ke = KDF-CMAC(base-key, usage | 0xAA)

encrypt-with-ad function: AES encryption in CCM mode using Ke

decrypt-with-ad function: AES decryption in CCM mode using Ke

pseudo random function: PRF = KDF-CMAC(base-key, "prf" | octet-string)

[CREF2]TBD: It may be better to use a nonce length of 11 octets (n = 11, q = 4) so the counter length is 32 bits. This would put a more reasonable limit on message size and is compatible with the cipherstate requirements for GSS-API. On the other hand, it may make it more difficult to use TLS-oriented GCM implementations that expose the Fixed-Common and Fixed-Distinct nonce components independently.

5.8. aes256-ccm-128

As for aes128-ccm-128, but using AES-256 as the block cipher and with key and key-generation seed lengths of 32 octets (256 bits).

5.9. chacha20-poly1305

This profile is based on [RFC7539] Section 2.8. A key length of 32 octets (256 bits) is used, along with an authentication tag length of 16 octets (128 bits).

key-generation seed length: key size (256 bits)

key-deriviation function: KDF-HMAC-SHA256 as defined in Section 5.2.3. The key usage number is expressed as four octets in big endian order.

Ke = KDF-HMAC-SHA256(base-key, usage | 0xAA)

encrypt-with-ad function: AEAD construction of chacha20 with poly1305 using Ke

decrypt-with-ad function: AEAD construction of chacha20 with poly1305 using Ke

pseudo random function: PRF = KDF-HMAC-SHA256(base-key, "prf" | octet-string)

6. Security Considerations

This document defines encryption types that would be unsafe when used outside specific applications that are aware of the requirement for non-repeating cipherstate. Implementations that expose [RFC3961] programming interfaces may not be able to completely prevent misuse of these encryption types.

Whilst this document abstractly supports the use of native AEAD ciphers with long-term keys, no such encryption types are defined. A future document may specify this, perhaps by deriving unique keys for each invocation of the encryption function.

Counter modes of encryption such as CCM and GCM require that the initialization vector never repeat. Where the application manages the cipherstate, the burden is on the application to ensure this. If the application uses a randomly generated initial cipherstate on each invocation of the authenticated encryption function, then to avoid a birthday attack the number of invocations should be limited to 2^48 (given a 96-bit initialization vector) or less. (Section 8.3 of [GCM] limits the number of invocations to 2^32 when using GCM with a randomly generated initialization vector.)

7. IANA Considerations

IANA is requested to assign:

8. Acknowledgements

The author would like to thank the following individuals for their comments and suggestions: Nicolas Williams and Greg Hudson.

9. References

9.1. Normative References

9.2. Informative References

Author's Address