krb5_gss_delete_sec_context on semi-established context fails when output token requested
I'd like to ask about the correct behavior in this (marginal) case.
There are two aspects to this issue:
- When output token is provided to krb5_gss_delete_sec_context, the
implementation creates a non-zero-length output token by sealing
an empty buffer. This does not comply with recommendations in
RFC 2743, 2744 and 4121.
- When deleting a context, that was not fully established, seal fails
resulting in context deletion failure.
Providing a non-null buffer to gss_delete_sec_context is discouraged
by GSS-APIv2 RFCs, but it is not forbidden. The implementation is
allowed to return some output token in that case, but is encouraged
The output_token parameter is retained for compatibility with version
1 of the GSS-API. It is recommended that both peer applications
invoke gss_delete_sec_context passing the value GSS_C_NO_BUFFER for
the output_token parameter, indicating that no token is required, and
that gss_delete_sec_context should simply delete local context data
structures. If the application does pass a valid buffer to
gss_delete_sec_context, mechanisms are encouraged to return a zero-
length token, indicating that no peer action is necessary, and that
no token should be transferred by the application.
RFC 4121 explicitly states, that context deletion tokens are empty
in Kerberos mechanism.
My question is:
Is there a reason for providing such a non-zero-length output token?
If not, I propose deleting the code responsible for generating this
dummy context (patch attached). This way a zero-length token is returned
and semi-established context deletion no longer fails.
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...
Re: krb5_gss_delete_sec_context on semi-established context fails when output token requested
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.