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

[Thomas Maslen <[e-mail]>]

On 11 Feb 2015 11:33:23 -0500, Greg Hudson wrote:
> [...]
> I am having trouble reconciling these statements.
> 
> The issue with token framing is not just an issue with the wording in
> the RFC; it calls into question the whole mode of operation.  An
> implementation of init/accept_sec_context cannot know how much data to
> read from the input stream in order to read a token, since GSS tokens do
> not necessarily have self-describing lengths.  The only way this can
> really work is if the application cooperates by creating a single-use
> input stream which ends at the end of the token.

Yes but no:

I agree that the application must create a single-use input stream which ends at the end of the token.

But you can do that without having to read and buffer the token.

It's easy enough to write a new subclass (I may as well call it BoundedInputStream) that takes an underlying InputStream and a length count, and produces an InputStream which lets you read that number of octets but no more (unless you go around it and get to the underlying InputStream).

This is a pretty normal sort of thing to do in Java, and it's normal enough that even JDK 1.0 had a convenience class -- http://docs.oracle.com/javase/7/docs/api/java/io/FilterInputStream.html -- that acts as a helpful base class for this sort of thing.  (The standard subclasses of FilterInputStream are mostly designed to munge the sequence of octets in the stream, not to virtualize end-of-stream, but the general approach is similar).


> Similarly, output tokens must be externally framed by the protocol.  An
> application cannot simply provide its outgoing network buffer to
> init/accept_sec_context; it must package up the data written to the
> output stream and frame it.  In effect, the output stream must be
> transformed into a byte array.

I agree that the argument is weaker for output tokens, because the majority of application protocols that convey GSS tokens probably use simple framing where the token is preceded by a length count for the entire token -- so yeah, in that case you're pretty much stuck with buffering the token in order to determine its length, so you may as well have used the byte array instead.  Hypothetically an application protocol could use a chunked encoding, e.g. ASN.1 indefinite-length or HTTP/1.1 chunking, and then you could write a subclass of java.io.FilterOutputStream that only had to buffer up to some chunk size, not the whole token...  but likely all non-hypothetical protocols that use GSS tokens just use the simple whole-token length count?