Subject: [Ietf-krb-wg] FAST: when does the reply key change

From: Sam Hartman <[email-masked]>
Date: Fri, 20 Mar 2009 15:40:37 -0400

As discussed in section 6.5 of the preauth framework, FAST provides a
facility that allows a KDC to replace a reply key if some other form
of client authentication has taken place.  The encrypted challenge fast
factor uses this facility.

The reply key is one of the state items of the preauth framework.  So,
it's important to specify when the FAST reply key is actually
replaced within the processing of the AS rep.  The current  text does not do this.

I propose that the reply key is replaced after handling all
pre-authentication methods.  The other option is that the reply key is
replaced immediately before the first mechanism.
That option doesn't make sense because

1) it creates complex interactions with pkinit

2) The mechanisms influence whether it is appropriate to replace the reply key.
_______________________________________________
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 10:55:07 -0700

This is implicit but not ambiguous in the current draft and the reply key can only be replaced after handling all the pre-authentication data.

This is because unless all the preauth data are handled, the KDC cannot reply a ticket and if the KDC does not reply with a ticket, the message sent by the KDC is always an error message. Incidentally it is not a really error condition when the client receives an error message, but in any case the reply key is not defined if the KDC message in the reply is an error message.

The current draft does not say anything about whether the replace-reply key should be used and that seems to be correct. The exact text is quoted below:

   The rep-key field, if present, contains the reply key that is used to
   encrypted the KDC reply.  The rep-key field MUST be absent in the
   case where an error occurs.  The enctype of the rep-key is the
   strongest mutually supported by the KDC and the client.

I would think would help to make this super clear if we add text to say the rep-key is omitted for auth factors such as PKINIT, and I am totally with you that the actual auth factors influence whether it is appropriate to replace the reply key.

--Larry