Kerberos Cryptosystem Negotiation Extension
updates
- rfc-4120 — The Kerberos Network Authentication Service (V5)
Extracted elements (18)
The KDC has a strong PRNG, so clients can benefit from its randomness by reusing KDC key data as entropy when generating the negotiated subkey, rather than relying solely on local entropy sources.
Under RFC 4120, the KDC must limit the ticket session key enctype to one it believes both client and server support, so if both sides understand a stronger enctype the KDC did not select, they cannot negotiate it. This extension allows the client and server to negotiate a stronger cryptosystem in subsequent communication, independent of the KDC's choice.
The AD-ETYPE-NEGOTIATION element is placed in the AD-IF-RELEVANT container so that servers not implementing this extension will safely ignore it and fall back to the enctype of the service ticket session key, preserving backward compatibility with RFC 4120.
If EtypeList is present and the server prefers an enctype from the list over the AP-REQ authenticator subkey (if present) or the service ticket session key, the server MUST create a subkey using that enctype and send it in the subkey field of the AP-REP message.
If the client prefers an enctype over the service ticket session key enctype, it SHOULD send the EtypeList to the server via AD-ETYPE-NEGOTIATION in the AP-REQ authenticator.
If the ticket session key enctype is included in the client's EtypeList, it SHOULD be the last entry; otherwise (if not included), that enctype MUST NOT be negotiated.
Implementations SHOULD use the service ticket session key value as a source of additional entropy when generating the negotiated subkey, to take advantage of the KDC's strong PRNG.
The AP-REQ authenticator subkey, if present, MAY also be used as a source of entropy when generating the negotiated subkey.
The client SHOULD NOT include enctypes that are less preferable than the ticket session key enctype in its EtypeList.
The client SHOULD NOT include negative (local-use) enctype numbers in the EtypeList unless it knows a priori that the server uses the same negative enctype numbers for the same enctypes.
The server MAY ignore the preference order indicated by the client's EtypeList; the policy for choosing an enctype is a local matter for both client and server.
This negotiation extension SHOULD NOT be used when the client does not expect a subkey in the AP-REP message from the server.
A new authorization data element AD-ETYPE-NEGOTIATION (type 129) is defined. It is carried in the authorization-data of the AP-REQ authenticator and contains the client's ordered list of supported enctypes.
The AD-ETYPE-NEGOTIATION element is enclosed in the AD-IF-RELEVANT container, so a correctly implemented server that does not understand this element will ignore it per RFC 4120 semantics.
The negotiated subkey (using the server-selected enctype from the EtypeList) is sent in the subkey field of the AP-REP message and is then used as the protocol key or base key per RFC 3961 for subsequent communication.
If a stronger enctype key is negotiated beneath a weaker enctype key, an attacker able to break the weaker enctype can also recover the stronger enctype key. The extension's benefit is minimizing the amount of ciphertext encrypted under a weak enctype that is exposed to an attacker.
The client's enctype list and the server's reply enctype are carried within encrypted data, so their security properties are the same as those of Kerberos encrypted data generally.
The EtypeList is encoded as DER (per X.680/X.690) of the ASN.1 type `EtypeList ::= SEQUENCE OF Int32`, representing enctypes in decreasing preference order (most preferred first). Int32 is as defined in RFC 4120.