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
