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

[Nico Williams <[e-mail]>]

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