]>
AEAD Encryption Types for Kerberos 5PADL SoftwarePO Box 59Central ParkVIC3145Australialukeh@padl.com
Security Area
Internet-Draft
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.
This document updates 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 .
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 . 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 .)
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 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 . We term these algorithms native AEAD, to distinguish them from the generic composition of non-AEAD encryption and checksum types.
The changes described below amend for use with native AEAD encryption types.
The native AEAD algorithms profiled in and 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 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 . 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.
Whilst 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.
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 .
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)
We allow the authentication of associated data with existing cryptosystems that follow the Simplified Profile defined in through the generic composition of the encryption and checksum functions. The is-longterm parameter is ignored. For consistency with the following definition uses 1-based indexing.
This section defines native AEAD profiles for using the AES-GCM, AES-CCM, AES-OCB, and chacha20-poly1305 algorithms and modes 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.
Because the key spaces for the cryptosystems defined below are dense, random or pseudo-random octet strings are used directly as keys.
The key derivation functions from Section 5 are used.
The initial session key from which subsequent keys are derived
An octet string describing the intended usage of the derived key
A counter, expressed as four octets in big endian order
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.
As defined in Section 5.1.
The | operator indicates concatenation.
The GCM and CCM profiles defined below use the counter/feedback key derivation function from 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:
all zero bits
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.
The AES-OCB-128 profile defined in and the chacha20-poly1305 profile defined in use the counter mode key derivation function from Section 5.1, using HMAC-SHA-256 as the PRF. The composition is given below:
all zero bits
HMAC-SHA-256(key, i | label | 0x00 | k)
KDF-HMAC-SHA256(key, label) = k-truncate(K1)
The AES-OCB-256 profile defined in uses the counter mode key derivation function from Section 5.1, using HMAC-SHA-384 as the PRF. The composition is given below:
all zero bits
HMAC-SHA-384(key, i | label | 0x00 | k)
KDF-HMAC-SHA384(key, label) = k-truncate(K1)
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:
M - N + 1 octets of D, starting at octet M (1-based)
oldstate[1..4]
oldstate[5..12]
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 Section 3.2.
Note also that the invocation counter described above is independent of the block counter implemented by the underlying encryption function.
The following parameters apply to all the encryption types defined below.
protocol key format: as defined in
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
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)
This profile is based on Section 5.1. The GCM authenticated encryption algorithm works as specified in 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 . 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)
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).
This profile is based on Section 5.3. The CCM authenticated encryption algorithm works as specified in 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 . 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)
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.
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).
This profile is based on Section 5.3. The OCB authenticated encryption algorithm works as specified in 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 TAGLEN of 16 octets (128 bits). The nonce length bitlen(N) is 96 bits.
The following parameters apply to the aes128-ocb-128 encryption type:
key-generation seed length: key size (128 bits)
key-deriviation function: KDF-HMAC-SHA256 as defined in . 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: AES encryption in OCB mode using Ke
decrypt-with-ad function: AES decryption in OCB mode using Ke
pseudo random function: PRF = KDF-HMAC-SHA256(base-key, "prf" | octet-string)
As for aes128-ocb-128, but using AES-256 as the block cipher, with key and key-generation seed lengths of 32 octets (256 bits), and using KDF-HMAC-SHA384 instead of KDF-HMAC-SHA256.
This profile is based on 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 . 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)
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 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 limits the number of invocations to 2^32 when using GCM with a randomly generated initialization vector.)
IANA is requested to assign:
Etype
Encryption type
Reference
TBD1
aes128-gcm-128
[this document]
TBD2
aes256-gcm-128
[this document]
TBD3
aes128-ccm-128
[this document]
TBD4
aes256-ccm-128
[this document]
TBD5
aes256-ocb-128
[this document]
TBD7
aes256-ocb-128
[this document]
TBD7
chacha20-poly1305
[this document]
The author would like to thank the following individuals for their comments and suggestions: Nicolas Williams and Greg Hudson.&RFC2119;
&RFC3961;
&RFC5116;
&RFC7253;
&RFC7539;
Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and ConfidentialityNational Institute of Standards and TechnologyRecommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMACNational Institute of Standards and TechnologyRecommendation for Key Derivation Using Pseudorandom FunctionsNational Institute of Standards and Technology&RFC3962;
&RFC4537;