Using KDC's master key to encrypt data

[Alejandro Perez Mendez]

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