<div dir="ltr"><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px">(My apologies for resending, but with the right subject this time.)</span></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px">Hi Weijun,</span><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">
You point out a legitimate problem, but I want to understand a couple of assumptions:</div><div style="font-family:arial,sans-serif;font-size:13px"><ol><li style="margin-left:15px">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 style="margin-left:15px">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 style="margin-left:15px">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><div><br></div><div class=""><div class="im"><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername"></b><span dir="ltr"><<a href="mailto:kitten-request@ietf.org" target="_blank">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" target="_blank">weijun.wang@oracle.com</a>><br>To: <a href="mailto:kitten@ietf.org" target="_blank">kitten@ietf.org</a>, OpenJDK <<a href="mailto:security-dev@openjdk.java.net" target="_blank">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" target="_blank">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" target="_blank">jhutz@cmu.edu</a>><br>To: Weijun Wang <<a href="mailto:weijun.wang@oracle.com" target="_blank">weijun.wang@oracle.com</a>><br>Cc: <a href="mailto:kitten@ietf.org" target="_blank">kitten@ietf.org</a>, OpenJDK <<a href="mailto:security-dev@openjdk.java.net" target="_blank">security-dev@openjdk.java.net</a>>,<br>
<a href="mailto:jhutz@cmu.edu" target="_blank">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" target="_blank">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</div></div></div></div></div></div>