Suggested update to RFC 5653 JGSS-API: Provide a way to return a token when context establishment fails

[Weijun Wang]

Hi All

I am Weijun Wang from the Java SE Seurity Team at Oracle, and this mail 
is about a design flaw in the initSecContext and acceptSecContext 
methods of the GSSContext class defined in RFC 5653 7.4.3 [1] and 7.4.9 [2].

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().

On the other hand, the C bindings of GSS-API has a chance to return 
both, and it does try to make use of both of them (according to RFC 2743 
2.2.1 [3]):

    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.

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

My current proposal is to add a new method getOutputToken() to the 
GSSException class (which will be thrown when an error occurs) to return 
this last token. This means the method calls will be something like

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

The getOutputToken() method can only return a non-null value when it's 
thrown by an initSecContext or acceptSecContext call. The method won't 
throw another GSSException even if the exception was thrown in other calls.

We can use the new JDK 8 default method feature [1] to add this new 
method to the existing GSSException interface.

Thanks
Weijun

[1] http://tools.ietf.org/html/rfc5653#section-7.4.3[2] 
http://tools.ietf.org/html/rfc5653#section-7.4.9
[3] http://tools.ietf.org/html/rfc2743#page-46
[4] http://tools.ietf.org/html/rfc5653#section-7.4.5