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-requ...@ietf.org <mailto:kitten-requ...@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.w...@oracle.com <mailto:weijun.w...@oracle.com>>
To: kit...@ietf.org <mailto:kit...@ietf.org>, OpenJDK
<security-dev@openjdk.java.net <mailto:security-dev@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.1030...@oracle.com
<mailto:51e37377.1030...@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 <jh...@cmu.edu <mailto:jh...@cmu.edu>>
To: Weijun Wang <weijun.w...@oracle.com <mailto:weijun.w...@oracle.com>>
Cc: kit...@ietf.org <mailto:kit...@ietf.org>, OpenJDK
<security-dev@openjdk.java.net <mailto:security-dev@openjdk.java.net>>,
jh...@cmu.edu <mailto:jh...@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.ca...@minbar.fac.cs.cmu.edu
<mailto:1373909621.23365.286.ca...@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
