[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
- [kitten] Suggested update to RFC 5653 JGSS-API: P… Weijun Wang
- Re: [kitten] Suggested update to RFC 5653 JGSS-AP… Jeffrey Hutzelman
- Re: [kitten] Suggested update to RFC 5653 JGSS-AP… Mayank Upadhyay
- Re: [kitten] Suggested update to RFC 5653 JGSS-AP… Nico Williams
- Re: [kitten] Suggested update to RFC 5653 JGSS-AP… Weijun Wang