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