Subject: [Ietf-krb-wg] FAST: bye bye finish checksum

From: Sam Hartman <[email-masked]>
Date: Wed, 11 Mar 2009 16:53:30 -0400

I realize there is not consensus in the WG to do this yet, but in my
implementation, I'm planning to drop the finish checksum and use the
following finish encoding:

I'm sending out specific ASN.1 because I understand a number of people
are implementing and it would be good if we all did the same thing.

     KrbFastFinished ::= SEQUENCE {
         timestamp   [0] KerberosTime,
         usec        [1] Microseconds,
             -- timestamp and usec represent the time on the KDC when 
             -- the reply was generated.        
         crealm      [2] Realm,
         cname       [3] PrincipalName,
             -- Contains the client realm and the client name.
         ticket-checksum [4] Checksum, 
             -- checksum  of the ticket in the KDC-REP  using the armor 
             -- and the key usage is KEY_USAGE_FAST_FINISH.
             -- The checksum type is the required checksum type 
             -- of the armor key.
         ...
     }            

And the following encoding of the response message:

     KrbFastResponse ::= SEQUENCE {
         padata      [0] SEQUENCE OF PA-DATA,
             -- padata typed holes.
         rep-key     [1] EncryptionKey OPTIONAL,
             -- This, if present, replaces the reply key for AS and 
             -- TGS.
             -- MUST be absent in KRB-ERROR.
         finished    [2] KrbFastFinished OPTIONAL,
             -- Present in AS or TGS reply; absent otherwise.
         nonce       [3] UInt32,
         ...
             -- The client's nonce from the inner request body
     }

If the WG adopts this change it is also important to require that
clients not reuse nonces within a conversation.

In addition, the cookie should move into the inner padata.  That means
that in an as-req the only outer padata is the FAST padata.  In a
tgs-req, you expect both the pa-tgs-req and the fast as outer padata.

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Larry Zhu <[email-masked]>
Date: Tue, 24 Mar 2009 11:30:04 -0700

+1. I support removing the TLS "finished" style checksum given the complexity and benefits tradeoff.

While reviewing this proposal, I quickly came to realize that the finished checksum is not fully specified after all. This is because it says the checksum key is the armor key but it does not say which armor key it should use.

Let's recall the armor key is the combined key using the ticket session key and the subkey, and the subkey is generated afresh for every KDC request, so effectively the armor key changes within the same conversation.

It is unclear to me that if it is reasonable to require the same armor ticket to be used within a given conversation. For example, the armor ticket might expire in the middle of a conversation, or when the KDC decides to change its krbtgt keys hence the client needs to get a new TGT in the middle of a conversation in order to continue the authentication ceremony.

More specifically I found the following text hard to digest in the current daft:

   Any FAST armor scheme MUST provide a fresh armor key for each
   conversation.  Clients and KDCs can assume that if a message is
   encrypted and integrity protected with a given armor key then it is
   part of the conversation using that armor key.

The good news is that all the above does not seem to matter if we remove the "finished" checksum as Sam proposed, given the client is no longer obligated to keep track what is within a conversation and what is not.

I would still recommend removing the second part of the paragraph quoted above given that the armor key changes but the text implies it does not change.

--larry

---

From: Sam Hartman <[email-masked]>
Date: Tue, 24 Mar 2009 20:46:34 -0400

>>>>> "Larry" == Larry Zhu <[email-masked]> writes:

    Larry> Let's recall the armor key is the combined key using the
    Larry> ticket session key and the subkey, and the subkey is
    Larry> generated afresh for every KDC request, so effectively the
    Larry> armor key changes within the same conversation.

The document claims that the armor key is constant for a conversation.
I assumed that was accomplished by keeping the subkey (and probably
the entire ap-req) constant.  There are no replay issues I can see.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg