FAST cookies

[Linus Nordberg]

Greg Hudson <ghudson at MIT.EDU> wrote
Mon, 27 Jun 2011 12:07:37 -0400:

| Here is a rough design proposal for allowing preauth plugins to set
| cookies:

Is this scheduled for 1.10?  It's not listed in
http://k5wiki.kerberos.org/wiki/Release_1.10 .


| What is the appropriate allowable time skew for a cookie?  Clock skew is
| not a factor (except when the KDC's clock changes, which hopefully only
| happens in tiny increments), but the client may have asked the user for
| input, which could take an arbitrary amount of time.
| 
| A cookie could be replayed within the time window, by someone who knows
| the armor key of a previous exchange.  Is this a problem for OTP?  I
| think I still need to do more review before I know the answer to that.

My interest in the PA-FX-COOKIE right now is to use it for "storing" the
nonce during the time between PA-OTP-CHALLENGE (kdc->client) and
PT-OTP-REQUEST (client->kdc).  This would let us get away without a
global, synchronised database for remembering the nonce in the kdc(s).

(Background re nonce: There's a kdc generated nonce (in the 4-pass
variant).  This nonce is primarily used kdc for authenticating the
client by using the Client Key to decrypt the encData field of the
PA-OTP-REQUEST.  A match with what was sent by the kdc in the
PA-OTP-CHALLENGE proves client possession of the Client Key.)

Judging from previous postings to the list regarding replay attacks and
OTP, it seems like this is Someone Else's Problem from a kdc point of
view.  In the case where the solution is to have only a single kdc and
thus no need for the tricky global database, a guarantee that a cookie
hasn't been replayed, not even within the time skew window, would make
implementation of "OTP methods" easier.

I don't know if that use case is significant enough to motivate the work
needed in general code.  It depends on how much extra you'd have to do I
guess.