krb5_gss_delete_sec_context on semi-established context fails when output token requested
ghudson at MIT.EDU
Mon Jan 13 11:58:40 EST 2014
On 01/09/2014 07:51 AM, Tomas Kuthan wrote:
> My question is:
> Is there a reason for providing such a non-zero-length output token?
I don't think so; the code just predates RFCs 2743/4121 and hasn't been
changed to match the new recommendations. Since you brought it up, I
will most likely apply your patch or a variation of it.
> On a related note, would it ever be useful to encrypt messages or
> create MICs on a context, that is not fully established yet? There is
> a check in the code, that prevents it, but in theory if there are keys
> available, this could succeed...
There is a provision for this in GSSAPIv2 (the GSS_C_PROT_READY flag),
but I don't see anything in 4121 about it for the krb5 mech, so I'm not
sure it would be kosher to allow this. There are also some security
* Tokens created this way would have to be protected in the initiator's
subkey, not the acceptor's subkey, which makes them subject to replay
attacks. Replay caches aren't 100% effective.
* If we added a perfect forward secrecy feature to the krb5 mech, tokens
created this way wouldn't be able to take advantage of it.
More information about the krbdev