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

Weijun Wang <weijun.wang@oracle.com> Mon, 15 July 2013 03:59 UTC

Return-Path: <weijun.wang@oracle.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAE821F9DF0 for <kitten@ietfa.amsl.com>; Sun, 14 Jul 2013 20:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIuDPX5J0Ev6 for <kitten@ietfa.amsl.com>; Sun, 14 Jul 2013 20:59:01 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id F394421F9DB4 for <kitten@ietf.org>; Sun, 14 Jul 2013 20:59:00 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6F3wxKq019012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Jul 2013 03:59:00 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6F3wwVa014936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 03:58:59 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6F3ww5J015895; Mon, 15 Jul 2013 03:58:58 GMT
Received: from mini.local (/123.122.156.63) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 14 Jul 2013 20:58:58 -0700
Message-ID: <51E37377.1030704@oracle.com>
Date: Mon, 15 Jul 2013 11:58:47 +0800
From: Weijun Wang <weijun.wang@oracle.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: kitten@ietf.org, OpenJDK <security-dev@openjdk.java.net>
References: <51B1E355.2090301@oracle.com>
In-Reply-To: <51B1E355.2090301@oracle.com>
X-Forwarded-Message-Id: <51B1E355.2090301@oracle.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a way to return a token when context establishment fails
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 03:59:06 -0000

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