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

[Benjamin Kaduk <[e-mail]>]

On Sat, 14 Feb 2015, Thomas Maslen wrote:

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

I suspect you are right, and I am just having a hard time getting out of
my array-based mindset instilled from the C bindings.

Sorry about that,

Ben