linus at nordu.net
Sun Jul 17 09:39:29 EDT 2011
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
Is this scheduled for 1.10? It's not listed in
| 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
More information about the krbdev