Internet DRAFT - draft-howard-krb-aead
draft-howard-krb-aead
Network Working Group L. Howard
Internet-Draft PADL
Intended status: Experimental 16 January 2023
Expires: 20 July 2023
AEAD Encryption Types for Kerberos 5
draft-howard-krb-aead-01
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 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 Notice
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.
Howard Expires 20 July 2023 [Page 1]
Internet-Draft AEAD Encryption Types for Kerberos 5 January 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
3. Authenticated Encryption with Associated Data (AEAD)
Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Updates to RFC 3961 . . . . . . . . . . . . . . . . . . . . . 3
4.1. Additional Requirements . . . . . . . . . . . . . . . . . 3
4.2. Removal of Mandatory Requirements . . . . . . . . . . . . 4
4.3. Application-managed Cipherstate . . . . . . . . . . . . . 4
4.4. Encrypt/decrypt with Associated Data . . . . . . . . . . 5
4.5. AEAD with Simplified Profile . . . . . . . . . . . . . . 6
5. Native AEAD Algorithm Profiles . . . . . . . . . . . . . . . 6
5.1. Protocol Key Representation . . . . . . . . . . . . . . . 6
5.2. Key Derivation Functions . . . . . . . . . . . . . . . . 6
5.2.1. Common Definitions for Key Derivation . . . . . . . . 7
5.2.2. KDF for AES-GCM and AES-CCM . . . . . . . . . . . . . 7
5.2.3. KDF for AES-OCB-128 and chacha20-poly1305 . . . . . . 7
5.2.4. KDF for AES-OCB-256 . . . . . . . . . . . . . . . . . 8
5.3. Cipherstate Chaining . . . . . . . . . . . . . . . . . . 8
5.4. Common Profile Definitions . . . . . . . . . . . . . . . 9
5.5. aes128-gcm-128 . . . . . . . . . . . . . . . . . . . . . 9
5.6. aes256-gcm-128 . . . . . . . . . . . . . . . . . . . . . 10
5.7. aes128-ccm-128 . . . . . . . . . . . . . . . . . . . . . 10
5.8. aes256-ccm-128 . . . . . . . . . . . . . . . . . . . . . 11
5.9. aes128-ocb-128 . . . . . . . . . . . . . . . . . . . . . 11
5.10. aes256-ocb-128 . . . . . . . . . . . . . . . . . . . . . 11
5.11. chacha20-poly1305 . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
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
Howard Expires 20 July 2023 [Page 2]
Internet-Draft AEAD Encryption Types for Kerberos 5 January 2023
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.
Howard Expires 20 July 2023 [Page 3]
Internet-Draft AEAD Encryption Types for Kerberos 5 January 2023
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.
Howard Expires 20 July 2023 [Page 4]
Internet-Draft AEAD Encryption Types for Kerberos 5 January 2023
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].
// 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)
Howard Expires 20 July 2023 [Page 5]
Internet-Draft AEAD Encryption Types for Kerberos 5 January 2023
* 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, 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.
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
Howard Expires 20 July 2023 [Page 6]
Internet-Draft AEAD Encryption Types for Kerberos 5 January 2023
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 AES-OCB-128 and chacha20-poly1305
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:
K0: all zero bits
Ki: HMAC-SHA-256(key, i | label | 0x00 | k)
KDF-HMAC-SHA256(key, label) = k-truncate(K1)
Howard Expires 20 July 2023 [Page 7]
Internet-Draft AEAD Encryption Types for Kerberos 5 January 2023
5.2.4. KDF for AES-OCB-256
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:
K0: all zero bits
Ki: HMAC-SHA-384(key, i | label | 0x00 | k)
KDF-HMAC-SHA384(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.
Howard Expires 20 July 2023 [Page 8]
Internet-Draft AEAD Encryption Types for Kerberos 5 January 2023
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)
Howard Expires 20 July 2023 [Page 9]
Internet-Draft AEAD Encryption Types for Kerberos 5 January 2023
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)
// 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.
Howard Expires 20 July 2023 [Page 10]
Internet-Draft AEAD Encryption Types for Kerberos 5 January 2023
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. aes128-ocb-128
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)
5.10. aes256-ocb-128
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.
5.11. 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.
Howard Expires 20 July 2023 [Page 11]
Internet-Draft AEAD Encryption Types for Kerberos 5 January 2023
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:
Howard Expires 20 July 2023 [Page 12]
Internet-Draft AEAD Encryption Types for Kerberos 5 January 2023
+=======+===================+=================+
| 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] |
+-------+-------------------+-----------------+
Table 1
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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February
2005, <https://www.rfc-editor.org/info/rfc3961>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.
[RFC7253] Krovetz, T. and P. Rogaway, "The OCB Authenticated-
Encryption Algorithm", RFC 7253, DOI 10.17487/RFC7253, May
2014, <https://www.rfc-editor.org/info/rfc7253>.
Howard Expires 20 July 2023 [Page 13]
Internet-Draft AEAD Encryption Types for Kerberos 5 January 2023
[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
<https://www.rfc-editor.org/info/rfc7539>.
[CCM] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: The CCM Mode for Authentication and
Confidentiality", May 2004,
<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", November
2007, <http://csrc.nist.gov/publications/nistpubs/800-38D/
SP-800-38D.pdf>.
[SP800-108]
Chen, L., "Recommendation for Key Derivation Using
Pseudorandom Functions", October 2009,
<http://csrc.nist.gov/publications/nistpubs/800-108/
sp800-108.pdf>.
9.2. Informative References
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
Encryption for Kerberos 5", RFC 3962,
DOI 10.17487/RFC3962, February 2005,
<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, June 2006,
<https://www.rfc-editor.org/info/rfc4537>.
Author's Address
Luke Howard
PADL Software
PO Box 59
Central Park VIC 3145
Australia
Email: lukeh@padl.com
Howard Expires 20 July 2023 [Page 14]
