FAST cookies

Linus Nordberg linus at nordu.net
Wed Jun 29 09:53:33 EDT 2011


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

| * A preauth system's verify_padata function gets the unpacked cookie
| value corresponding to its pa type as input, or a null value if there
| isn't one.

OK.


| * A preauth system's return_padata function can provide a cookie value
| which is packed into the inner sequence.  If no preauth systems supply
| cookies, we send an old-style "MIT" cookie in order to save space and
| processing time.

In order to add a cookie to a PA-OTP-CHALLENGE, we need to be able to
do this in the edata function too.


| 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.

I'm unsure about this.  I'll try to find out.




More information about the krbdev mailing list