[kitten] On stream-based GSSContext methods in RFC 5653

Wang Weijun <weijun.wang@oracle.com> Mon, 16 March 2015 03:46 UTC

Return-Path: <weijun.wang@oracle.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 1ACF11A0077 for <kitten@ietfa.amsl.com>; Sun, 15 Mar 2015 20:46:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9C6khFNl0FS8 for <kitten@ietfa.amsl.com>; Sun, 15 Mar 2015 20:46:56 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF83A1A0074 for <kitten@ietf.org>; Sun, 15 Mar 2015 20:46:56 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com []) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2G3kssM014060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Mar 2015 03:46:56 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com []) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t2G3kqxw018963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Mar 2015 03:46:53 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com []) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t2G3kq0L018960; Mon, 16 Mar 2015 03:46:52 GMT
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 15 Mar 2015 20:46:52 -0700
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: text/plain; charset=us-ascii
From: Wang Weijun <weijun.wang@oracle.com>
In-Reply-To: <alpine.GSO.1.10.1502061704130.3953@multics.mit.edu>
Date: Mon, 16 Mar 2015 11:46:46 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <A3256456-DACB-44B3-B614-599640744405@oracle.com>
References: <alpine.GSO.1.10.1501201753140.23489@multics.mit.edu> <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> <54D40D6A.7010704@mit.edu> <54D4100E.7070200@oracle.com> <alpine.GSO.1.10.1502061704130.3953@multics.mit.edu>
To: kitten@ietf.org, OpenJDK Dev list <security-dev@openjdk.java.net>
X-Mailer: Apple Mail (2.2070.6)
X-Source-IP: acsinet21.oracle.com []
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/gXcCTJZF8Cm4kbY66dWY5M3-JX4>
Cc: Thomas.Maslen@software.dell.com
Subject: [kitten] On stream-based GSSContext methods in RFC 5653
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Mar 2015 03:46:58 -0000

Hi All

I discussed with my colleagues on the stream-based methods and we think they are not well-designed:

1. A library should not define a wire protocol and assume the peer is using the same. http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-05 requires the application to define it.

2. It's impossible to implement these methods correctly when the mechanism token has no self-framing or the library has no knowledge of the token format (for example,
as a bridge talking to another GSS library).

Therefore, I propose to deprecate these methods in an I-D. By deprecation, I'd like to remove the methods from the main content and describe the reason in a "Changes since RFC 5653" section. The specification for the methods will be moved to an appendix or the "Changes since RFC 5653" section will contain links to sections inside RFC 5653.

In Oracle JDK and OpenJDK, we would like to mark these methods as @deprecated. The existing implementations will be still supported.