FAST cookies

[Greg Hudson]

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

* The cookie contains a version tag and an encrypted blob.  This would
probably be hand-encoded such that "MIT" is a possible value of the
version tag.

* The blob is encrypted with the first krbtgt key and a key usage in the
512-1023 range ("reserved for uses internal to a Kerberos
implementation").

* The blob contains a timestamp and a sequence of {numeric pa type,
octet string}.  pa type values are expected to be unique within the
sequence.  This would probably be ASN.1-encoded.

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

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

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.