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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E06BE1A1AFB for <>; Wed, 18 Feb 2015 13:45:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JjNxSRmnbvrH for <>; Wed, 18 Feb 2015 13:45:14 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 435D81A1AE2 for <>; Wed, 18 Feb 2015 13:45:14 -0800 (PST)
X-AuditID: 1209190d-f792d6d000001fc7-6e-54e507e848a9
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 6C.E7.08135.9E705E45; Wed, 18 Feb 2015 16:45:13 -0500 (EST)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t1ILjCh3017764; Wed, 18 Feb 2015 16:45:12 -0500
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (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 ( 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 <>
In-Reply-To: <>
Message-ID: <>
References: <>, <> <>
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: <>
Cc: "" <>
Subject: Re: [kitten] draft-ietf-kitten-rfc5653bis-02 review
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
> 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,