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

Nico Williams <nico@cryptonector.com> Mon, 16 February 2015 04:21 UTC

Return-Path: <nico@cryptonector.com>
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 46A5C1A8739 for <kitten@ietfa.amsl.com>; Sun, 15 Feb 2015 20:21:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.233
X-Spam-Level:
X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 f82VZA0e0b56 for <kitten@ietfa.amsl.com>; Sun, 15 Feb 2015 20:21:09 -0800 (PST)
Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 20ECC1A8738 for <kitten@ietf.org>; Sun, 15 Feb 2015 20:21:09 -0800 (PST)
Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id 036052004EE8B; Sun, 15 Feb 2015 20:21:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=LXfoPi0EoZqOKD fkzXPUjPXpbyo=; b=MQOWqDhGjxPrdYCMoWxMJvqbt8D7QOFvxqYmxXZgkCZIR2 FaD2yxVmxQGH/pOdxVmS9JULs1HEcpvYQpfuPG1QE3nQ4Si5P4Z5KKarz9aAfwrX ARnh+/V42O/aupJnwPVtDvJAcNen3nm0JOsmPUmHL4udX1F1JGPJR6gn59mzg=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPA id 99FC22004EE8A; Sun, 15 Feb 2015 20:21:08 -0800 (PST)
Date: Sun, 15 Feb 2015 22:21:08 -0600
From: Nico Williams <nico@cryptonector.com>
To: Benjamin Kaduk <kaduk@MIT.EDU>
Message-ID: <20150216042107.GC5246@localhost>
References: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.GSO.1.10.1502061704130.3953@multics.mit.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/vkIkz45w3t9xyp9bXeRNFpzVHr0>
Cc: 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: Mon, 16 Feb 2015 04:21:10 -0000

On Fri, Feb 06, 2015 at 06:13:19PM -0500, Benjamin Kaduk wrote:
> First, I should note that the Java bindings explicitly do not implement
> GSS_Process_context_token.  This does not directly affect any of the
> [...]

Perhaps not, but a Java equivalent for GSS_Process_context_token would
be nice to have.

> 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
> [...]

I *think* what's happening here is that the streams in question are
synthetic ones containing *only* the GSS tokens.  Therefore there should
be no framing issue.  It's just a different way to represent a token.
The use of streams can be helpful in some applications, I'm sure, and
though an adaptor class would work just as well, these methods should
result in less application code.

That said, the use of streams strikes me as dangerous: in the presence
of a self-framing mechanism, an application that passes in streams
corresponding to the application protocol streams... would function
correctly, whereas it would fail to work with non-self-framing
mechanisms.

(The GSI mechanism that uses TLS is a self-framing mechanism.  When the
application writes the tokens without further framing the result is TLS
on the wire, even though a GSS interface is used!)

> 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.

The above applies here as well.

Nico
--