krb5_gss_delete_sec_context on semi-established context fails when output token requested

[Greg Hudson]

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
concerns:

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