Subject: [Ietf-krb-wg] draft-ietf-krb-wg-preauth-framework and pa-fx-cookie

From: Sam Hartman <[email-masked]>
Date: Tue, 20 Jan 2009 18:36:16 -0500 (EST)

element is always included whenever a FAST padata item is included.

At least initially, the intent of pa-fx-cookie was to save state that
the KDC would need to track a conversation.

However, in the FAST case, it is also tied into the mechanism used to
protect against downgrades and to checksum the entire conversation.

I also note that the cookie field of pa-fx-cookie is optional.

Intuitively, what I'd expect to happen is that there would be no
cookie in the initial request from the client without
pre-authentication, nor in the preauth_required error.  The client
decides somehow to use FAST.  There is no pa-fx-cookie in its first
message using FAST.
I had sort of imagined that  it would use FAST with some set of FAST factors.
The KDC would either respond with an AS-REP or alternatively with an MORE_PREAUTH_NEEDED including a pa-fx-cookie.

However my intuition seems not to agree with the document and I
suspect the document is closer to correct than my intuition.

The document seems to suggest that the client would somehow decide to
use FAST.  It does not yet know what factors to use.  So, it sends a
request containing a PA_FX_FAST padata.  The KDc responds.  In the
error response are two padata items: pa-fx-cooking and pa-fx-fast .
Inside the pa-fx-fast are padata including authentication sets and/or
raw padata items telling the client which factors to use.

The client then generates a second message, copying the cookie, using
some fast factors.  In the typical case this generates an AS-REP
containing two padata items: pa-fx-cookie and PA_FX_FAST.  The
PA_FX_FAST contains additional padata.

Actually, it's kind of unclear whether the pa-fx-cookie needs to be
included.  Section 6.5 says no, but section 6.3 (on cookies) says yes.

So, questions for the WG.

Is the document right that we have a break in conversations between
the point where we decide we're going to do FAST and thus our first
message from the client including PA_FX_FAST is a new conversation point?

Should that first message containing PA_FX_FAST from the client
include a pa-fx-cookie?  I say no, the whole pa-fx-cookie is always
generated by the KDC.  The document seems to imply that the binding
key and conversation ID are generated by the client, and the client
would include a pa-fx-cookie with the actual cookie absent in that
first message.  I'd prefer to say that message does not contain a
cookie and that the cookie element can lose the optional qualifier.

Does the AS-REP/TGS-REP include a pa-fx-cookie?  I'd like to say no,
but if no, how does the client get the binding key in a really short
exchange?

Is there a reason that the binding key needs to be separate from the
armor key?  Or can we do away with the tie between pa-fx-cookie and
FAST and just use the armor key for the checksum in the finish
message?

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Jan 2009 14:19:19 -0500

Larry and I discussed this.
Unless there are objections, we're moving forward with the following:

* The binding key disappears as a concept and the armor key is used for the checksum of the conversation.
* We lose the binding key and conversation ID from the cookie.
It just becomes an octet string always sent by the KDC and echoed back by the client.

Consider the following exchange:
1 client-> KDC: as_req for client
2 kdc->client: preauth_required(fist)
3 client->kdc: as-req(obtain armor ticket)
4 kdc->client: as-rep (armor ticket)
5) client->kdc as-req (uses fast)
6) kdc->client as-rep: uses fast

1-2, 3-4 and 5-6 all form three separate conversations.  Only message
5 would be in message 6's finish checksum.
We think the draft already says this.  However if other people read the draft differently we should make it more clear.
If others believe the consensus of the WG is different about what should be going on, we clearly need to discuss.

A result of the above is that you do not get a protected indication
that FAST is supported.  Since you would never get an unprotected
indication that fast is not supported and since any of the protected
indications that might be discussed so far are subject to stripping by
the attacker, I'm quite sure we don't care.

Larry and I are likely to propose standardizing the enc_padata
Microsoft extension to the KDC reply and using that as a protected
indication of FAST.If we do so, it will be independent of the current
pre-authentication framework.

--Sam