jspωiki
Kerberos Cryptosystem Negotiation Extension

Overview#

Kerberos Cryptosystem Negotiation Extension is defined in RFC 4537

If the client prefers an enctype over that of the Service Ticket Session Key, then it SHOULD send a list of enctype in decreasing preference order to the server. Based on local policy, the client selects enctypes out of all the enctype available locally to be included in this list, and it SHOULD NOT include enctype that are less preferable than that of the ticket session key in the service ticket. In addition, the client SHOULD NOT include negative (local- use) enctype numbers unless it knows a priori that the server has been configured to use the same negative enctype numbers for the same enctype.

The client sends the enctype list via the authorization-data of the authenticator in the AP_REQ RFC 4120. A new authorization data element type AD-ETYPE-NEGOTIATION is defined.

AD-ETYPE-NEGOTIATION 129

This authorization data element itself is enclosed in the AD-IF-RELEVANT container; thus, a correctly implemented server that does not understand this element should ignore it RFC 4120. The value of this authorization element contains the DER X.680 X.690 encoding of the following ASN.1 type:

EtypeList ::= SEQUENCE OF Int32
    -- Specifies the enctypes supported by the client.
    -- This enctype list is in decreasing preference order
    -- (favorite choice first).
    -- Int32 is defined in [RFC 4120].
If the EtypeList is present and the server prefers an enctype from the client's enctype list over that of the AP_REQ authenticator subkey (if that is present) or the service ticket session key, the server MUST create a subkey using that enctype. This negotiated subkey is sent in the subkey field of AP_REP message, and it is then used as the protocol key or base key RFC 3961 for subsequent communication.

If the enctype of the ticket session key is included in the enctype list sent by the client, it SHOULD be the last on the list; otherwise, this enctype MUST NOT be negotiated if it was not included in the list.

This negotiation extension SHOULD NOT be used when the client does not expect the subkey in the AP_REP message from the server.

A note on key generation: The KDC has a strong Pseudorandom number generator (PRNG); as such, the client can take advantage of the randomness provided by the KDC by reusing the KDC key data when generating keys. Implementations SHOULD use the service ticket session key value as a source of additional entropy when generating the negotiated subkey. If the AP_REQ authenticator subkey is present, it MAY also be used as a source of entropy.

The server MAY ignore the preference order indicated by the client. The policy by which the client or the server chooses an enctype (i.e., how the preference order for the supported enctypes is selected) is a local matter.

More Information#

There might be more information for this subject on one of the following: