Fwd: Kitten Digest, Vol 104, Issue 14

[Mayank Upadhyay]

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?

   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?

   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.

Thanks,
Mayank

---------- Forwarded message ----------
From: <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>
To: kitten at ietf.org, OpenJDK <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>
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>
To: Weijun Wang <weijun.wang at oracle.com>
Cc: kitten at ietf.org, OpenJDK <security-dev at openjdk.java.net>,
        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>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20130718/1b83d02b/attachment.htm>