Re: [kitten] draft-ietf-kitten-rfc5653bis-02 review

Benjamin Kaduk <kaduk@MIT.EDU> Wed, 18 February 2015 21:45 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06BE1A1AFB for <kitten@ietfa.amsl.com>; Wed, 18 Feb 2015 13:45:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjNxSRmnbvrH for <kitten@ietfa.amsl.com>; Wed, 18 Feb 2015 13:45:14 -0800 (PST)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435D81A1AE2 for <kitten@ietf.org>; Wed, 18 Feb 2015 13:45:14 -0800 (PST)
X-AuditID: 1209190d-f792d6d000001fc7-6e-54e507e848a9
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 6C.E7.08135.9E705E45; Wed, 18 Feb 2015 16:45:13 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t1ILjCh3017764; Wed, 18 Feb 2015 16:45:12 -0500
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1ILjAU8019492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Feb 2015 16:45:11 -0500
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1ILj9HL002706; Wed, 18 Feb 2015 16:45:09 -0500 (EST)
Date: Wed, 18 Feb 2015 16:45:09 -0500 (EST)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Thomas Maslen <Thomas.Maslen@software.dell.com>
In-Reply-To: <D5847DD823005F4E9DB94FE77DCEDF68319F0A7A@ALVMBXW01.prod.quest.corp>
Message-ID: <alpine.GSO.1.10.1502181644180.3953@multics.mit.edu>
References: <D5847DD823005F4E9DB94FE77DCEDF68319E4B4C@ALVMBXW02.prod.quest.corp>, <alpine.GSO.1.10.1502121726170.3953@multics.mit.edu> <D5847DD823005F4E9DB94FE77DCEDF68319F0A7A@ALVMBXW01.prod.quest.corp>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrPuS/WmIwawWLoujm1exWLxubGJy YPJYsuQnk0ffMZcApigum5TUnMyy1CJ9uwSujCX/H7AUXBCu2HX1JVsDY49AFyMnh4SAiURL yyM2CFtM4sK99UA2F4eQwGImiVf7t0A5GxklHj34yg7hHGKS6GjdAJVpYJR4MeMXWD+LgLbE hf23WUBsNgEViZlvNoLFRQSMJT4tXQ5mMwuoS3w784axi5GDQ1jARuLkh3CQMKdAoMTaEx8Z QWxeAQeJZXffM0LMP8Uo8fjzQ2aQhKiAjsTq/VNYIIoEJU7OfMICMVNLYvn0bSwTGAVnIUnN QpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdILzezRC81pXQTIzhUJXl3ML47qHSIUYCD UYmHt4PpSYgQa2JZcWXuIUZJDiYlUd40tqchQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4d+wD KudNSaysSi3Kh0lJc7AoifNu+sEXIiSQnliSmp2aWpBaBJOV4eBQkuBdATJUsCg1PbUiLTOn BCHNxMEJMpwHaPhpkBre4oLE3OLMdIj8KUZFKXHeRpCEAEgiozQPrheWSl4xigO9IszLDUws QjzANATX/QpoMBPQ4Pl/HoEMLklESEk1MHqdlUuZtOnRhMyLcfKlimePyZxNPM1jcfb4SrX6 pBnb3/QXd20/4bulKO3ktBdK+8rUVCP+Z2hc6Z48d175+rmdkvcMshdobG3x33W1MPLMujcB Qb/OS046LBrTcHntZ85Uox/MCdU1Gyf8Zud8qtV5eanRIo0GDpNbSw4rGtVHyT9XYI7QZlZi Kc5INNRiLipOBABP5FlwAAMAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/RTWFsEqVwnnoPaQHURi60QYA_fM>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] draft-ietf-kitten-rfc5653bis-02 review
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: Wed, 18 Feb 2015 21:45:17 -0000

On Sat, 14 Feb 2015, Thomas Maslen wrote:

> On Thu, 12 Feb 2015, Benjamin Kaduk wrote:
> > [...]
> > While there is a strong sequencing requirement for context-level tokens
> > (the negotiation loop proceeds in lockstep), and so a stream-based method
> > would definitely be workaboe there, the per-message operations do not have
> > that ordering requirement.  I think it would be an unreasonable burden on
> > an application to expect it to supply input streams to the per-message
> > GSS operations which are guaranteed to only supply a single token.  Even
> > though it is possible to do, it requires a lot of effort to do correctly.
>
> Quite possibly I'm missing something obvious or just haven't thought this through, but:
>
> Even in really complex scenarios, e.g. running with requestSequenceDet(false) + concurrent / unordered delivery of application messages from the peer (e.g. using UDP or a separate TCP connection for each) + multiple threads operating concurrently to receive these application messages and present their per-message tokens to the GSSContext instance, I believe that it's as easy (or as difficult) to use the stream-based methods as it is to use the byte-array methods.
>
> Possibly relevant:  note that the spec (2853, 5653, 5653bis) doesn't promise anything about concurrency w.r.t. the methods of a GSSContext instance (nor about anything else in the API, for that matter) -- in particular, the Java keyword "synchronized" doesn't appear anywhere.  [Yes, it might be a good thing if this were more explicit in the spec, whereas at present it's very very implicit;  by contrast, GSSContext's Javadoc in the JDK
>
>     http://docs.oracle.com/javase/1.5.0/docs/api/org/ietf/jgss/GSSContext.html
>
> comes right out and says "Also note that none of the methods in this interface are synchronized. Therefore, it is not advisable to share a GSSContext among several threads unless some application level synchronization is in place"].
>
> The byte-array methods may intuitively seem to be kinda sorta "more
> atomic" than the stream-based methods, but they aren't;  if you're using
> multiple threads to feed per-message tokens to a GSSContext instance
> then you're responsible for serializing the calls, regardless of whether
> you're using the byte-array methods or the stream-based methods.

I suspect you are right, and I am just having a hard time getting out of
my array-based mindset instilled from the C bindings.

Sorry about that,

Ben