Subject: Re: [Ietf-krb-wg] FAST: do we need the checksum

From: Tim Alsop <[email-masked]>
Date: Mon, 9 Mar 2009 13:19:32 +0000

Sam,

I wanted you to be aware that we are currently adding FAST to our TrustBroker product (so we can support OTP pre-auth without a password), and were very interested to see your email (below) regarding checksums for FAST. We agree that the use of a checksum, as described in the draft is probably not necessary, and an alternative which is easier to code/implement is desirable.

We will let you know our thoughts on this subject as we make progress during the next few weeks, and will hopefully be able to provide some useful contribution to the IETF Kerberos WG efforts. At the moment we are taking time to understand the drafts and the changes we need to make to our code. I get the impression you are also doing the same with the MIT code ?

Thanks,
Tim Alsop
CyberSafe

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: 04 March 2009 17:13
To: [email-masked]
Subject: [Ietf-krb-wg] FAST: do we need the checksum

The FAST checksum in the finish messages is probably the most
complicated part of FAST.  It requires the KDC to be able to produce a
checksum of the entire conversation with the client in the last
message, even though the KDC's only state is the fast cookie.

You can do this by either having checksum primitives that allow you to
serialize the internal state of the checksum, or by including previous
messages in the cookie.

It's clearly doable but it is kind of ugly and complicated.

I was looking yesterday at what the checksum actually buys us.

Note that similar checksums are important in TLS and SSH because those
protocols exchange negotiation parameters in the clear and need to
confirm them at the end.  FAST starts out with an armor key, so
everything starting with the first message is protected.
(Obtaining the armor key is not, but that is a separate exchange.)

So, what does a checksum of a conversation give you?

* protects all fields in all messages in the conversation [1]
* Guarantees that both sides received the same messages in the same order
    ** no insertions
     * no reorderings
    ** no replays

[1] It turns out that the FAST checksum does not cover the message
that contains it, but other mechanisms protect the content of that
message.

It turns out that the only thing used from outside the encrypted FAST
request in the message from the client to the KDC is the cookie.  The
request body is taken from inside the FAST request, not the outer
body.  The only thing else in a kdc req is the sequence of padata.
Except for the cookie everything else is taken from inside the fast
request.

For error responses, everything except for the padata is taken from the pa-fx-error.

For the as-rep or tgs-rep, everything is taken from the finish message
except for the ticket (and probably absent cookie).  The ticket is
covered by the ticket checksum in the finish message.

So in terms of preventing message modifications, the checksum in the
finish message only protects the cookie.  Of course, the only reason
the cookie is outside of FAST is that the checksum in the finish
message is far easier to deal with that way.

The armor key is unique to a conversation; that prevents a message from one conversation from appearing to be part of another conversation.

So, the checksum buys us replay protection and sequence protection.

I think we could get the same thing by including the nonce in the fast
response for both errors and replies and asking clients to choose a
random nonce.

Does it make sense to do that?  Do other people agree it has adequate security properties?
Do people want to make the change?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg