<div dir="ltr">Hi Weijun,<div><br></div><div>You point out a legitimate problem, but I want to understand a couple of assumptions:</div><div><ol><li>Why allow only initSecContext() and acceptSecContext() to have this new behavior? Imagine a mechanism built on top of TLS which is renegotiating the session intermixed with actual payload, and had some error it wanted to communicate to the peer (e.g., a TLS Alert). Is there any particular reason you'd like to avoid that scenario?<br>
<br></li><li>I didn't quite follow the comment about the default method (maybe it shows that my Java is dated :). GSSException is not an interface but a concrete class, and adding a method to it adds it in the JRE starting at some particular version. What happens when applications that call the new method are run on an older JRE?<br>
<br></li><li>Don't we also need to set this token when the mechanism creates a GSSException instance? Note that the concrete class has no setter methods of any kind at this time, but two constructors.</li></ol><div>Thanks,</div>
<div>Mayank</div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername"></b> <span dir="ltr"><<a href="mailto:kitten-request@ietf.org">kitten-request@ietf.org</a>></span><br>
Date: Mon, Jul 15, 2013 at 12:01 PM<br><br>
Message: 4<br>
Date: Mon, 15 Jul 2013 11:58:47 +0800<br>
From: Weijun Wang <<a href="mailto:weijun.wang@oracle.com">weijun.wang@oracle.com</a>><br>
To: <a href="mailto:kitten@ietf.org">kitten@ietf.org</a>, OpenJDK <<a href="mailto:security-dev@openjdk.java.net">security-dev@openjdk.java.net</a>><br>
Subject: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a way<br>
to return a token when context establishment fails<br>
Message-ID: <<a href="mailto:51E37377.1030704@oracle.com">51E37377.1030704@oracle.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
Hi All<br>
<br>
I am Weijun Wang from the Java SE Seurity Team at Oracle, and this mail<br>
is about a design flaw in the initSecContext and acceptSecContext<br>
methods of the GSSContext class defined in RFC 5653 7.4.3 [1] and 7.4.9 [2].<br>
<br>
The GSSContext::initSecContext() method could either return a token<br>
(possibly null if no more token is needed) when the call succeeds or<br>
throw a GSSException if there is a failure, but not *both*. The same<br>
applies to acceptSecContext().<br>
<br>
On the other hand, the C bindings of GSS-API has a chance to return<br>
both, and it does try to make use of both of them (according to RFC 2743<br>
2.2.1 [3]):<br>
<br>
It is the caller's responsibility to establish a communications path<br>
to the target, and to transmit any returned output_token (independent<br>
of the accompanying returned major_status value) to the target over<br>
that path.<br>
<br>
Without the ability to send a token when there is a failure, a Java<br>
program has no chance to tell the other side what's happening. This is<br>
very user-unfriendly. Also, in the case of SPNEGO, a "reject"<br>
NegTokenResp token will never be able to sent out.<br>
<br>
My current proposal is to add a new method getOutputToken() to the<br>
GSSException class (which will be thrown when an error occurs) to return<br>
this last token. This means the method calls will be something like<br>
<br>
try {<br>
send(initSecContext(inToken));<br>
} catch (GSSException e) {<br>
if (e.getOutputToken() != null) {<br>
send(e.getOutputToken());<br>
}<br>
throw e;<br>
}<br>
<br>
The getOutputToken() method can only return a non-null value when it's<br>
thrown by an initSecContext or acceptSecContext call. The method won't<br>
throw another GSSException even if the exception was thrown in other calls.<br>
<br>
We can use the new JDK 8 default method feature [1] to add this new<br>
method to the existing GSSException interface.<br>
<br>
Thanks<br>
Weijun<br>
<br>
[1] <a href="http://tools.ietf.org/html/rfc5653#section-7.4.3[2]" target="_blank">http://tools.ietf.org/html/rfc5653#section-7.4.3[2]</a><br>
<a href="http://tools.ietf.org/html/rfc5653#section-7.4.9" target="_blank">http://tools.ietf.org/html/rfc5653#section-7.4.9</a><br>
[3] <a href="http://tools.ietf.org/html/rfc2743#page-46" target="_blank">http://tools.ietf.org/html/rfc2743#page-46</a><br>
[4] <a href="http://tools.ietf.org/html/rfc5653#section-7.4.5" target="_blank">http://tools.ietf.org/html/rfc5653#section-7.4.5</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Mon, 15 Jul 2013 13:33:41 -0400<br>
From: Jeffrey Hutzelman <<a href="mailto:jhutz@cmu.edu">jhutz@cmu.edu</a>><br>
To: Weijun Wang <<a href="mailto:weijun.wang@oracle.com">weijun.wang@oracle.com</a>><br>
Cc: <a href="mailto:kitten@ietf.org">kitten@ietf.org</a>, OpenJDK <<a href="mailto:security-dev@openjdk.java.net">security-dev@openjdk.java.net</a>>,<br>
<a href="mailto:jhutz@cmu.edu">jhutz@cmu.edu</a><br>
Subject: Re: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a<br>
way to return a token when context establishment fails<br>
Message-ID: <<a href="mailto:1373909621.23365.286.camel@minbar.fac.cs.cmu.edu">1373909621.23365.286.camel@minbar.fac.cs.cmu.edu</a>><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
On Mon, 2013-07-15 at 11:58 +0800, Weijun Wang wrote:<br>
<br>
> My current proposal is to add a new method getOutputToken() to the<br>
> GSSException class (which will be thrown when an error occurs) to return<br>
> this last token. This means the method calls will be something like<br>
<br>
This seems like an elegant solution to the problem.<br>
<br>
-- Jeff<br>
<br>
<br></div></div></div>