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

[Thomas Maslen <[e-mail]>]

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

    http://docs.oracle.com/javase/1.5.0/docs/api/org/ietf/jgss/GSSContext.html

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.


[Skipping...]

> My ideological preference would be consistency between the flavors, but I
> would accept a solution that explicitly spelled out that the stream-based
> methods handled error tokens in one way and the byte-array methods handled
> error tokens in a different way.  The reason that I am arguing for the
> exception to carry the error token in the stream method is that it seems
> the best way to clearly spell out how to generate error tokens in the way
> which is most likely to be backwards-compatible.  Having the
> implementation automatically insert the error token into the stream seems
> like it introduces a risk of duplicating the token (albeit a very small
> one), and I don't see that risk if the exception carries the token.

I agree;  if, per the rfc5653bis drafts, GSSException is extended to carry the error token, then I think it's reasonable (and probably a good idea) to say that the implementation should always convey the error token in the GSSException, never in the OutputStream.

[One caveat, but it's probably not worth worrying about because this may be strictly hypothetical:  if there are any cases where an existing JGSS implementation has already been using the OutputStream to convey an error token (because that was the only approach that was available in 2853 or 5653) and real application code has been making use of this, then we might be outlawing something that has worked up until now...  but my guess is that this is only a hypothetical concern].