Subject: [Ietf-krb-wg] FAST: protection of ticket

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Jan 2009 14:34:58 -0500

Folks, I've been writing up a proposal for what it would take to put
together a minimal implementation of FAST.  I've noticed a couple of
inconsistencies while doing so.  The first is that currently, there is
no protection for the AS-REP in FAST.  There is a checksum covering everything prior to the AS-REP, the encrypted part of the AS-REP  is integrity protected, but that's not good enough.

KDC-REP		::= SEQUENCE {
	pvno		[0] INTEGER (5),
	msg-type	[1] INTEGER (11 -- AS -- | 13 -- TGS --),
	padata		[2] SEQUENCE OF PA-DATA OPTIONAL
				-- NOTE: not empty --,
	crealm		[3] Realm,
	cname		[4] PrincipalName,
	ticket		[5] Ticket,
	enc-part	[6] EncryptedData
				-- EncASRepPart or EncTGSRepPart,
				-- as appropriate
}

Now, let's look at the KRBFastResponse and finish:
     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,
             -- MUST be present if the client is authenticated,
             -- absent otherwise.
             -- Typically this is present if and only if the containing
             -- message is the last one in a conversation.
         ...
     }

     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.
         checksum    [4] Checksum,
             -- Checksum performed over all the messages in the
             -- conversation, except the containing message.
             -- The checksum key is the armor key as defined in
             -- Section 6.5.1, and the checksum type is the required
             -- checksum type of the armor key.
         ...
     }

I think the simplest solution is to include a checksum of the ticket
in the finish message.  Absent objections I'll do that.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg