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

Benjamin Kaduk <kaduk@MIT.EDU> Fri, 06 February 2015 23:13 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 7402D1A1ABB for <kitten@ietfa.amsl.com>; Fri, 6 Feb 2015 15:13:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.811
X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 HY9uvkVszTsG for <kitten@ietfa.amsl.com>; Fri, 6 Feb 2015 15:13:25 -0800 (PST)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFCF1A0673 for <kitten@ietf.org>; Fri, 6 Feb 2015 15:13:24 -0800 (PST)
X-AuditID: 1209190e-f799e6d000000cfe-13-54d54a93c323
Received: from mailhub-auth-1.mit.edu ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 3F.75.03326.39A45D45; Fri, 6 Feb 2015 18:13:23 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu []) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t16NDMqN016911; Fri, 6 Feb 2015 18:13:22 -0500
Received: from multics.mit.edu (system-low-sipb.mit.edu []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t16NDKZo026296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Feb 2015 18:13:21 -0500
Received: (from kaduk@localhost) by multics.mit.edu ( id t16NDKd3023336; Fri, 6 Feb 2015 18:13:20 -0500 (EST)
Date: Fri, 6 Feb 2015 18:13:19 -0500 (EST)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Weijun Wang <weijun.wang@oracle.com>
In-Reply-To: <54D4100E.7070200@oracle.com>
Message-ID: <alpine.GSO.1.10.1502061704130.3953@multics.mit.edu>
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>
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+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrDvZ62qIQU+/qsXRzatYLL4u3cDs wOSxZMlPJo+PT2+xBDBFcdmkpOZklqUW6dslcGUcbrvNVtBqX3Hm90+mBsaXRl2MnBwSAiYS j5oes0PYYhIX7q1n62Lk4hASWMwkcXDhGihnA6PE7bOnoJyDTBI9V48wg7QICdRL3H/bywpi swhoSTydfh0sziagIjHzzUY2EFtEQEOi4UETUJyDg1nASOLCrwwQU1hAX+LaYnmQCk6gzlPv rzGChHkFHCTuT5OG2HSUSWLCtTtgE0UFdCRW75/CAmLzCghKnJz5BMxmBupdPn0bywRGwVlI UrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdbLzSzRS00p3cQIDlNJvh2MXw8qHWIU 4GBU4uFN4L0SIsSaWFZcmXuIUZKDSUmUV8f8aogQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd6e pUDlvCmJlVWpRfkwKWkOFiVx3k0/+EKEBNITS1KzU1MLUotgsjIcHEoSvByeQEMFi1LTUyvS MnNKENJMHJwgw3mAhveB1PAWFyTmFmemQ+RPMSpKifOGgiQEQBIZpXlwvbA08opRHOgVYd4e kCoeYAqC634FNJgJaPBisKuLSxIRUlINjKzqbheOKE3nzTotFXZwtdxJ7cdfFgh/2dERe89O 8pv28oNVbEdk/trw2tcH/O3usfK+fCNe10rlyomlVxjtdzoe28Wi/2JmbOuu9BzJhiaLhS3d N5SZ3W6qSucxL5pUWb3iprbWp9Srqy4dXZ91zdu0L8HnGfu6LOYZU1R8Jc3sb/5+vJAhQIml OCPRUIu5qDgRANiIc3T+AgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/3GTvo05BVY9vb1P3GxNmnghkt7U>
Cc: kitten@ietf.org
Subject: [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: Fri, 06 Feb 2015 23:13:28 -0000

(was Re: [kitten] WGLC for three "bis" documents:
draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01,

[changing subject line to avoid complicating the threading if there are
discussions for the other two documents]

On Thu, 5 Feb 2015, Weijun Wang wrote:

> On 2/6/2015 8:40, Greg Hudson wrote:
> > On 02/05/2015 07:04 PM, Weijun Wang wrote:
> > > One problem is that if the app "have already written extra code to
> > > generate that token and send it", now it will send it twice.
> >
> > How would an app generate its own GSSAPI error token?  Surely it would
> > have to have intimate knowledge of the mech in order to do so.
> I don't know if there exists an app doing that. Still possible. Maybe I am
> just looking for reasons to persuade myself. :-)
> >
> > > Stream methods are not used by many. So most people would have to
> > > rewrite their apps to make use of this feature.
> >
> > Fair enough.
> >
> > If, considering all of the arguments given thus far, you still feel that
> > it's better for the stream methods to be consistent with the byte
> > methods, I don't have any strong objection to keeping it the way it is.
> That's still my position. I just don't want to introduce a behavior change.

I got a chance to read more closely more of the bulk of the document.
(That is, read the whole text, not just the diff, though I skipped some
uninteresting API descriptions.)

First, I should note that the Java bindings explicitly do not implement
GSS_Process_context_token.  This does not directly affect any of the
reasoning about whether the application protocol can transmit
post-completion error tokens or the peer's ability to process them, since
the peer is not necessarily written in Java.

I have some serious concerns about the stream-based routines in general,
though.  Section 6.4.5 (and 6.4.9) contain the text:

          The GSS-API authentication tokens contain a definitive start and end.
          This method will attempt to read one of these tokens per invocation,
          and may block on the stream if only part of the token is available.

This is simply not true.  Only the initial context token is required to
use the ASN.1-like framing; subsequent context tokens are known to be from
a particular mechanism, and that mechanism can specify a token format
which does not contain framing information.  It happens that the Kerberos
and SPKM mechanisms mentioned in the introduction do use self-describing
token formats, but a generic mechanism is not bound to do so.  As
described in section 2 of
https://tools.ietf.org/html/draft-ietf-kitten-gss-loop-04 , the
application protocol using the GSS-API must specify how to frame and
identify context negotation tokens.

Similarly, the format of wrap tokens is mechanism specific, and is not
required to include framing information.  The discussion in 6.4.15 and
6.4.17 do not seem to include explicit claims that the wrap tokens are
self-describing, but the use of stream interfaces does tend to imply that
wrap() and unwrap() could be used to filter a data stream from an
application for encryption on the wire.

Because neither the context nor per-message tokens are required to be
self-describing, a generic GSS-API-using application protocol must specify
its own token framing, and the only safe way to use the stream forms of
these routines is to read the entire token from the network using the
application's framing, then construct a single-use stream for a single GSS
call, discarding the stream afterwards.  (It might be possible for an
application to limit itself to a specific mechanism which is known to use
token framing, but that completely loses the "Generic" part of "GSS-API".)
Since this essentially involves generating byte-array tokens everywhere
and generating single-use streams from them, it makes me wonder what
utility the stream forms of these routines provide.  That is, it seems
they could be removed from the specification, since they only increase the
programmer effort required, when used correctly.  However, I have no
experience writing GSS-API-using software in Java, so perhaps I am missing
something about how and why the stream forms might be preferred in some

Finally, I believe I can say a bit more about keeping the transmission of
error tokens under the application's control even when streams are used.

It seems that the intended workflow in section 7.4.5 of RFC 5653 is that
the initSecContext implementation will generate an output token and place
it into the OutputStream buffer; the application would then explicitly
call flush() on the stream to trigger the token transmission.  The
expectation would be that the stream provides complete buffering for each
token, so that each flush() or GSS call would transmit or consume exactly
one token on the stream.  Given the above commentary about non-framed
tokens, though, I don't see how this could work reliably.  In any case,
even in this model where the GSS implementation places bytes in the stream
to be flush()ed by the application, sections 7.4.5 and 7.4.9 of RFC 5653
are still ambiguous about whether the implementation places bytes in the
stream before throwing an exception.  A given implementation could either
place the token in the stream or not do so, and still be compliant with
what RFC 5653 specifies.

Since we are now discovering the issue, we should take advantage of the
opportunity to resolve the ambiguity, but are obligated to do so in a
backwards-compatible way.  It seems that erring on the side of not sending
error tokens is mroe backwards-compatible than erring on the side of
sending duplicate error tokens (though I have not given a great deal of
thought to it), so that would be my current preference.  That is, I think
Weijun is justified in his position of using an exception for error tokens
in the stream case.

A few other notes from my reading that probably do not affect the actual
specified behavior:

Comparing the descriptions of the initSecContext flavors in 6.4.3 and
6.4.5, it seems that the byte-array version's description in 6.4.3 started
out as a copy of the stream-based description in 6.4.5 and was not fully
updated for the byte-array case.  That is, it refers to "[t]his is
equivalent to the stream-based method except that the token buffers are
handled as byte arrays instead of using stream objects.", but the stream
version has not been introduced yet, so this is a forward reference that
is not marked as such.  It also has the text that "Typically, the
application would do so by calling the flush() method on an OutputStream
that encapsulates the connection between the two peers.", which does not
seem quite appropriate for a routine dealing in byte arrays.

The phrase "informational purpose" appears in three places in the new
text, but should be "informational purposes" with a trailing 's'.

RFC 5653 had a notice about the use of RFC 2119 keywords that is removed
in the current draft, which seems correct as I do not see any capitalized
RFC 2119 keywords in my reading.  I wonder how that notice slipped into
RFC 5653....

Section 6.8 of the -02 adds "For example, when an initSecContext call
fails due to a fatal error, the mechanism may define an error token [...]"
I wonder if "generate" might be better than "define".

In 6.8.2, I think that the text about the outputToken where "When
provided, the array will be cloned to protect against subsequent
modifications" could be more clear that the GSS implementation will make a
copy of the outputToken which was provided as input to the GSSException
constructor (as opposed to the copy being made at some later time).  In
particular, the word "clone" is a bit unusual to use here.

The unchanged text from RFC 5653 could also benefit from a general
copyediting pass, but I do not think I am prepared to perform one during
the WGLC period.