Subject: rcf4120 vs. rfc4121

From: Michael Chapel <[email-masked]>
Date: Tue, 11 Oct 2005 12:10:48 -0500

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:

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. 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. 

Michael W. Chapel
Java Kerberos/JGSS Development
IBM/Tivoli Java Security 
Austin Texas

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 11 Oct 2005 13:21:17 -0400

Michael Chapel wrote:

> Doesn't these two contradict each other. And if not, could you explain
> to me why this is so.

The text from 4121 is describing the requirements of the KRB_AP
exchange.  Therefore, you have not yet negotiated a subkey via KRB_AP.

Jeffrey Altman

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Oct 2005 19:54:38 +0200 (MET DST)

> encyption key. They don't seem to be in sync with each others statements:

It appears that you're rightfully confused.

> 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:
> 
> 

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.

-Martin

---

From: Michael Chapel <[email-masked]>
Date: Tue, 11 Oct 2005 12:57:32 -0500

That seems resonable, yet somewhat confusing. I as an application am 
asserting a subkey in the AP_REQ authenicator which has a subkey 
available, Yet "this" KRB_CRED will be decrypted with the session key, 
even though the sub key is present once the authenticator is decrypted. It 
seem historically this was encrypted with the subkey.

Michael W. Chapel

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 11 Oct 2005 20:17:22 -0700

it does not make sense to encrypt something with a key sitting next it, does it?

________________________________

From: [email-masked] on behalf of Michael Chapel
Sent: Tue 10/11/2005 10:57 AM
To: Jeffrey Altman
Cc: [email-masked]; [email-masked]
Subject: Re: rcf4120 vs. rfc4121

That seems resonable, yet somewhat confusing. I as an application am asserting a subkey in the AP_REQ authenicator which has a subkey available, Yet "this" KRB_CRED will be decrypted with the session key, even though the sub key is present once the authenticator is decrypted. It seem historically this was encrypted with the subkey. 

Michael W. Chapel

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 12 Oct 2005 06:29:02 +0200

> encyption key. They don't seem to be in sync with each others statements:
[...]
> Doesn't these two contradict each other. And if not, could you explain to me
> why this is so.

There are some implementations that both uses subkey and some uses session
key existing today, so its a good idea to check both. To makes things
"better", there is also the "NULL" encrypted KRB_CRED used for GSS-API for
older enctypes.

Love

---

From: Michael Chapel <[email-masked]>
Date: Wed, 12 Oct 2005 09:43:23 -0500

About as much since as double encrypting it in the authenticator with the 
same key.

Michael W. Chapel

"Liqiang(Larry) Zhu" <[email-masked]>
Sent by: [email-masked]
10/11/2005 10:17 PM

To
Michael Chapel/Austin/IBM@IBMUS, "Jeffrey Altman" <[email-masked]>
cc
<[email-masked]>, <[email-masked]>
bcc

Subject
RE: rcf4120 vs. rfc4121

it does not make sense to encrypt something with a key sitting next it, 
does it?

Michael W. Chapel

---

From: Sam Hartman <[email-masked]>
Date: Mon, 17 Oct 2005 15:31:11 -0400

>>>>> "Jeffrey" == Jeffrey Altman <[email-masked]> writes:

    Jeffrey> Michael Chapel wrote:
    >> Which I assumed if a subkey was asserted that it would be
    >> encrypted with the subkey. Yet in rfc4121 it states:
    >> 
    >> 
    >> 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.

    Jeffrey> The text from 4121 is describing the requirements of the
    Jeffrey> KRB_AP exchange.  Therefore, you have not yet negotiated
    Jeffrey> a subkey via KRB_AP.

I actually don't believe this is true.  The application has asserted a
subkey.  However the text in RFC 4120 only requires that it be a key
exchanged in the ap_req exchange.  It says it is usually the last key
exchanged.

Note that the session key is exchanged in the ap_req exchange so the
requirement of 4120 is met.