Using KDC's master key to encrypt data

[Alejandro Perez Mendez]

After a discussing it with Nico, and since I'm not actually using FAST, 
we realized that it may be better if I don't use PA_FX_COOKIE at all for 
this purpose. The GSS context can be transported within the same PA_DATA 
than the GSS_TOKEN, making the solution more independent from FAST.

The resulting PA-GSS would be something similar to this (ASN1 provided 
by Nico):

PA-TGS ::= SEQUENCE {
     sec-ctx-token [0] OCTET STRING,
     state [1] EncryptedData OPTIONAL -- containing PA-GSS-STATE
}

PA-GSS-STATE ::= SEQUENCE {
     timestamp [0] KerberosTime OPTIONAL,
     exported-sec-ctx-token [1] OCTET STRING OPTIONAL,
     ...
}

PA-GSS-STATE would be encrypted first krbtgt key and a key usage in the 
512-1023 range, as described in previous Greg's mail.

Regards,
Alejandro

> On 09/08/12 10:23, Greg Hudson wrote:
>> On 08/09/2012 04:27 AM, Alejandro Perez Mendez wrote:
>>> as part of the GSS-preauth plugin
>>> (http://k5wiki.kerberos.org/wiki/Projects/GSS-API_preauth), I would like
>>> to encrypt & sign the contents of PA-FX-COOKIE
>> kdcpreauth plugins should not be directly manipulating the cookie; I'm
>> not even sure if it's possible for them to do so at the moment.  The
>> current framework will need to be extended to support cookies.  I wrote
>> a rough design outline for this at:
>>
>> http://mailman.mit.edu/pipermail/krbdev/2011-June/010141.html
>>
> Hi Greg,
>
> well, actually I can create and process PA_FX_COOKIES from my code. What
> I'm doing is the following. In the server side, I'm creating the
> PA_FX_COOKIE by hand and inserting it in the e_data element, along with
> the rest of PA_DATA elements, as specified in 4120 (if I'm not wrong). I
> can access to the cookie created by the client by using this struct:
>
>       cookie = rock->rstate->cookie;
>
> In the client side, I just copy the cookie received into the e_data
> element and insert it into the list of PA_DATA to send. I'm ok with this
> way of operation, it works (my code is working). Of course, some helper
> functions wouldn't hurt :), so preauth programmers can avoid worrying
> about encryption, timestamps and those kind of things.
>
> Sorry I missed your mail about cookies before. I think that the
> interface you are proposing is great. Just a couple of comments:
>
> 1) PA_FX_COOKIE is not intended only for its use with FAST. I can be
> used by any preauth mechanism that follows RFC 6113 framework (like in
> my case, GSS-preauth). I wouldn't call them "FAST cookies", but "preauth
> cookies". O
>
>> * 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.
> 2) This functionality should be available also when return_padata
> function is not called (i.e. error is generated), since this is the
> expected behaviour in multi-round trip mechanisms (i.e. including a
> COOKIE in a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED message).
>
>> 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.
> 3) Actually, as COOKIEs can be used without FAST, a COOKIE could be
> replayed by anyone, not only those who know the armor key. In the case
> of GSS-preauth, this would mean the creation of a second identical GSS
> context in the KDC for a short period of time. But I don't think this is
> a problem, since the attacker would need also to know the whole client
> GSS context.
>
> Regards,
> Alejandro
>
> _______________________________________________
> krbdev mailing listkrbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev