This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Kerberos Cryptosystem Negotiation Extension
Kerberos Cryptosystem Negotiation Extension

Version management

Difference between version and

At line 1 added 77 lines
!!! Overview
[{$pagename}] is defined in [RFC 4537]
If the [client] prefers an [enctype|Etype] over that of the [Service Ticket] [Session Key], then it [SHOULD] send a list of [enctype|Etype] in decreasing preference order to the [server]. Based on local policy, the client selects enctypes out of all the [enctype|Etype] available locally to be included in this list, and it [SHOULD NOT] include [enctype|Etype] 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|Etype] numbers unless it knows a priori that the server has been configured to use the same negative enctype numbers for the same [enctype|Etype].
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:
%%prettify
{{{
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|Etype] 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:
[{ReferringPagesPlugin before='*' after='\n' }]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop