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

[Weijun Wang]

Hi Mayank

On 7/19/2013 1:37 PM, Mayank Upadhyay wrote:
> (My apologies for resending, but with the right subject this time.)
>
> Hi Weijun,
>
> You point out a legitimate problem, but I want to understand a couple of
> assumptions:
>
>  1. 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?

No, there isn't. I just haven't expected any usage outside these 2 
methods. In the final spec, I think I would write something like "If the 
underlying mechanism defines any error token to be sent to the peer, ....".

>
>  2. 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?

Oh, I was wrong. I thought everything in JGSS is an interface. We can 
just add the method there.

If someone call the new method on an older JRE, a NoSuchMethodException 
is thrown. I had thought about creating a new ExtendedGSSException, but 
I really don't want to create ExtendedExtendedGSSException one day.

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

New constructors will be provided.

Thanks
Weijun

>
> Thanks,
> Mayank
>
> ---------- Forwarded message ----------
> From: **<kitten-request at ietf.org <mailto:kitten-request at ietf.org>>
> Date: Mon, Jul 15, 2013 at 12:01 PM
>
> Message: 4
> Date: Mon, 15 Jul 2013 11:58:47 +0800
> From: Weijun Wang <weijun.wang at oracle.com <mailto:weijun.wang at oracle.com>>
> To: kitten at ietf.org <mailto:kitten at ietf.org>, OpenJDK
> <security-dev at openjdk.java.net <mailto:security-dev at openjdk.java.net>>
> Subject: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a way
>          to return a token when context establishment fails
> Message-ID: <51E37377.1030704 at oracle.com
> <mailto:51E37377.1030704 at oracle.com>>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 15 Jul 2013 13:33:41 -0400
> From: Jeffrey Hutzelman <jhutz at cmu.edu <mailto:jhutz at cmu.edu>>
> To: Weijun Wang <weijun.wang at oracle.com <mailto:weijun.wang at oracle.com>>
> Cc: kitten at ietf.org <mailto:kitten at ietf.org>, OpenJDK
> <security-dev at openjdk.java.net <mailto:security-dev at openjdk.java.net>>,
> jhutz at cmu.edu <mailto:jhutz at cmu.edu>
> Subject: Re: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a
>          way to return a token when context establishment fails
> Message-ID: <1373909621.23365.286.camel at minbar.fac.cs.cmu.edu
> <mailto:1373909621.23365.286.camel at minbar.fac.cs.cmu.edu>>
> Content-Type: text/plain; charset="UTF-8"
>
> On Mon, 2013-07-15 at 11:58 +0800, Weijun Wang wrote:
>
>  > 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
>
> This seems like an elegant solution to the problem.
>
> -- Jeff