[17035] in Kerberos_V5_Development
Re: FAST cookies
daemon@ATHENA.MIT.EDU (Linus Nordberg)
Sun Jul 17 09:39:49 2011
To: krbdev@mit.edu
From: Linus Nordberg <linus@nordu.net>
Date: Sun, 17 Jul 2011 15:39:29 +0200
Message-ID: <87pql9rppq.fsf@nordberg.se>
Mime-Version: 1.0
X-Complaints-To: usenet@dough.gmane.org
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Greg Hudson <ghudson@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.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
