Re: rcf4120 vs. rfc4121
Martin Rex <martin.rex <at> sap.com>
2005-10-11 17:54:38 GMT
Michael Chapel wrote:
> I'm a bit confused by the wording between the two rfc's about the KRB_CRED
> encyption key. They don't seem to be in sync with each others statements:
It appears that you're rightfully confused.
> In rfc4120 it states:
> The current
> time and, if they are specifically required by the application, the
> nonce, s-address, and r-address fields are placed in the encrypted
> part of the KRB_CRED message, which is then encrypted under an
> encryption key previously exchanged in the KRB_AP exchange (usually
> the last key negotiated via subkeys, or the session key if no
> negotiation has occurred).
> Which I assumed if a subkey was asserted that it would be encrypted with
> the subkey.
This is exactly what was written in rfc1510 Section 3.6.1 generating
the KRB_CRED message.
RFC-1964 (predecessor of rfc4121) is unfortunately silent about the details
of the generation of the KRB_CRED message.
> Yet in rfc4121 it states:
> The checksum type MUST be 0x8003. When delegation is used, a
> ticket-granting ticket will be transferred in a KRB_CRED message.
> This ticket SHOULD have its forwardable flag set. The EncryptedData
> field of the KRB_CRED message [RFC4120] MUST be encrypted in the
> session key of the ticket used to authenticate the context.
> Doesn't these two contradict each other. And if not, could you explain to
> me why this is so.
They don't fully contradict, the use of negotiated subkeys is described
as some sort of "tradition", which I read as a "MAY".
From previous discussions about subkey negotiation, it appears to me that
implementations often lacked (real) subkey negotiation, so it was not really
a tradition after all, in spite of what rfc1510 and rfc4121 suggests.
Keep in mind that the KRB_CRED message in rfc-1964 Kerberos and CFX
is included in the AP_REQ message, so it could NEVER be protected under
a subkey asserted by an acceptor in AP_REP in the way rfc1510 and rfc4120
suggest in the parentheses "last subkey".
Looking at MIT Kerberos 1.0.5, it appears that the KRB_CRED message
is created before AP_REQ is created (during gss_init_sec_context),
so there KRB_CRED will be protected under the ticket session key
and not the initiator-asserted subkey from the accompanying AP_REQ.