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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: zero_output_token.patch.txt
Url: http://mailman.mit.edu/pipermail/krbdev/attachments/20140109/91749efc/attachment.txt