Internet-Draft | AEAD Encryption Types for Kerberos 5 | January 2023 |

Howard | Expires 20 July 2023 | [Page] |

- Workgroup:
- Network Working Group
- Internet-Draft:
- draft-howard-krb-aead-01
- Published:
- Intended Status:
- Experimental
- Expires:

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 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 https://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 20 July 2023.¶

Copyright (c) 2023 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

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].¶

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].¶

[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.¶

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

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].¶

[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.¶

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.¶

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].¶

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:¶

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¶

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 [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.¶

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:¶

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 Section 5.9 and the chacha20-poly1305 profile defined in Section 5.11 use the counter mode key derivation function from [SP800-108] Section 5.1, using HMAC-SHA-256 as the PRF. The composition is given below:¶

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

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

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:¶

- 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.¶

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)¶

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)¶

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 [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)¶

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 [RFC5116] Section 5.3. The OCB authenticated encryption algorithm works as specified in [RFC7253] 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 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: 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 [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)¶

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.)¶

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]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
- [RFC3961]
- Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, , <https://www.rfc-editor.org/info/rfc3961>.
- [RFC5116]
- McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, , <https://www.rfc-editor.org/info/rfc5116>.
- [RFC7253]
- Krovetz, T. and P. Rogaway, "The OCB Authenticated-Encryption Algorithm", RFC 7253, DOI 10.17487/RFC7253, , <https://www.rfc-editor.org/info/rfc7253>.
- [RFC7539]
- Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 7539, DOI 10.17487/RFC7539, , <https://www.rfc-editor.org/info/rfc7539>.
- [CCM]
- Dworkin, M., "Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality", , <http://csrc.nist.gov/publications/nistpubs/800-38C/SP-800-38C.pdf>.
- [GCM]
- Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", , <http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf>.
- [SP800-108]
- Chen, L., "Recommendation for Key Derivation Using Pseudorandom Functions", , <http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf>.

- [RFC3962]
- Raeburn, K., "Advanced Encryption Standard (AES) Encryption for Kerberos 5", RFC 3962, DOI 10.17487/RFC3962, , <https://www.rfc-editor.org/info/rfc3962>.
- [RFC4537]
- Zhu, L., Leach, P., and K. Jaganathan, "Kerberos Cryptosystem Negotiation Extension", RFC 4537, DOI 10.17487/RFC4537, , <https://www.rfc-editor.org/info/rfc4537>.