Re: A fundamental JGSS-API bug?

[Sean Mullan]

On 06/07/2013 09:42 AM, Weijun Wang wrote:
Hi All
The GSSContext::initSecContext() method could either return a token
(possibly null if no more token is needed) when the call succeeds or
throw a GSSException if there is a failure, but not *both*. The same
applies to acceptSecContext().

However, according to RFC 2743 2.2.1 [1], the C bindings of GSS-API:

    It is the caller's responsibility to establish a communications path
    to the target, and to transmit any returned output_token (independent
    of the accompanying returned major_status value) to the target over
    that path.

In fact, MIT krb5's gss-client.c sample does show:

         do {
             maj_stat = gss_init_sec_context(..., &send_tok, ...);
             ...
             if (send_tok.length != 0) {    # send the token anyway
                 if (send_token(..., &send_tok) < 0) {
                     ...
                     return -1;
                 }
             }                              # before return value check
             if (maj_stat != GSS_S_COMPLETE
                 && maj_stat != GSS_S_CONTINUE_NEEDED) {
                 ...
                 return -1;
             }

             if (maj_stat == GSS_S_CONTINUE_NEEDED) {
                 ...
             }
         } while (maj_stat == GSS_S_CONTINUE_NEEDED);

Without the ability to send a token when there is a failure, a Java
program has no chance to tell the other side what's happening. This is
very user-unfriendly. Also, in the case of SPNEGO, a "reject"
NegTokenResp token will never be able to sent.

I cannot find a good way to fix it without changing the semantic of
current APIs. Maybe we can add a new GSSException::getResidue() method
to return this last token. But that means the method call will be quite
complicated, something like

         try {
             send(initSecContext(inToken));
         } catch (GSSException e) {
             if (e.getResidue() != null) {
                 send(e.getResidue());
             }
             throw e;
         }

That doesn't seem too complicated to me, all things considered. I think 
this would be a reasonable solution. I would simply name the method 
getToken instead of getResidue.

As for the overloaded initSecContext(InputStream, OutputStream) style,
it looks easier to update this method to do the correct thing without
any new API. However, the change will be very confusing because there is
no more number of written bytes to return. More importantly, if it's
just a silent behavior change, we'll have to care about compatibility
(Maybe someone already added his/her own KRB-ERROR sending codes?),
which makes the situation much tougher.

Can you describe how the application code would use this method like you 
did above for the other initSecContext method?

--Sean


Thanks
Max

[1] http://tools.ietf.org/html/rfc2743#page-46