krb5_gss_delete_sec_context on semi-established context fails when output token requested

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

krb5_gss_delete_sec_context on semi-established context fails when output token requested

Tomas Kuthan
Hi all,

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
not to.

RFC 2744:
    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...

src/lib/gssapi/krb5/k5seal.c:
345    if (! ctx->established) {
346        *minor_status = KG_CTX_INCOMPLETE;
347        return(GSS_S_NO_CONTEXT);
348    }

Thanks,
Tomas

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

zero_output_token.patch.txt (943 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev