Subject: [Ietf-krb-wg] FAST: extent of a conversation

From: Sam Hartman <[email-masked]>
Date: Wed, 04 Mar 2009 11:37:37 -0500

Larry and I had a discussion yesterday about the extent of
conversations in the preauth framework.  We think the draft is
correct, although we believe a couple of explicit clarifications would
help.  We want to describe our understanding and make sure others
agree.

It's important for the client and KDC to have the same idea about the
lifetime of the conversation.  This is particularly true if FAST is
being used so the client can verify the checksum in the finish
message.  It is also true in other cases because affects of various
state modification such as changes to the reply key or progress in an
authentication set is important to keep in sync.  Outside of FAST, it
is more likely that a client and KDC could have different ideas about
the lifetime of a conversation and have things still work in at least
some cases.  However it is actually important that we get it right.

>From the KDC's standpoint the conversation lifetime is tied to a
cookie.  If the client does not include a cookie, the KDC has no way
(or at least should not) tie the message to a previous conversation.
As a consequence of this, if the client wants to start a new
conversation it should not include the cookie.  As another consequence
of this, if the client does not include the cookie it should throw
away its conversation state.

So then the question of whether the KDC can terminate a conversation
comes up.  It seems clear that by not returning a cookie the KDC can
force termination.

When should the KDC do this?  The simplest answer is that this is an
implementation matter.  That's mostly correct.

I had initially thought that for my implementation, most errors should
terminate a conversation.  However I realized that's undesirable in a
number of cases.  Consider pkinit errors that include DH parameters.

I can view that two ways:

1) Conversation: client tries pkinit.  KDC  responds with new DH parameters.

2) Converssation: client tries pkinit; kdc responds with  an as-rep

Or the second view is that you have a single authentication attempt
(and thus a single conversation) where the client tries using
optimistic DH parameters and is told to update and try again by the
KDC.

I find the second option more natural.

Obviously there are a lot of KDCs out there (MIT included) that don't
include a cookie and at least in the non-FAST case force the client to
treat them as two conversations.  For pkinit that's basically OK.  For
future mechanisms the distinction may become more important.

So, I think in the FAST case it is reasonable for clients to take the
absence of a cookie to mean that the KDC would like to stop talking to
the client.  That means that for most errors, you want the KDC to
include a cookie.

I propose to add some clarification around this in draft 10.  However
I wanted to make sure that people are OK with the approach I've
outlined here and agree this is consistent with the current draft.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 05 Mar 2009 23:50:09 -0500

> I find the second option more natural.

So do I, and more importantly, I think it is necessary if you are going to 
rely on the finish message checksum to avoid an attacker from forcing a 
downgrade.  Such protection requires that the client not retain any state 
from one authentication attempt to the next.

-- Jeff