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

[Thomas Maslen <[e-mail]>]

On 10 Feb 2015 18:40:25 +0800, Wang Weijun <[e-mail]> wrote
(in response to one of Ben's review comments):
> [...]
> I will spend some time talking with my colleagues on your opinions on stream-based methods.

For whatever it's worth...

I agree with most of what Ben wrote in his review, particularly the long-standing text he flagged in RFC 2853 / 5653 / rfc5653bis which seems to assume that all tokens -- not just initial tokens -- received by GSSContext.initSecContext() and GSSContext.acceptSecContext() use the mechanism-independent token format.

However, I don't agree with this comment in the review:

>> [...]
>> Since this essentially involves generating byte-array tokens everywhere
>> and generating single-use streams from them, it makes me wonder what
>> utility the stream forms of these routines provide.

I believe that the "Since this essentially involves generating byte-array tokens everywhere" premise isn't really true, and I believe that the stream-based methods are definitely useful and don't need to be revisited.

(Aside:  now that I have read the sample code in RFC 2853 et seq for the stream-based methods, I see what led Ben to believe that this essentially involves generating byte-array tokens everywhere, but I believe that's just a problem with the usefulness of the sample code, not a problem with the usefulness of the stream-based methods).

To me the stream-based methods are the fundamental form, whereas the byte-array methods are just convenience methods:  they provide a convenient but less efficient alternative, and it wouldn't have been a tragedy if RFC 2853 had omitted the byte-array methods and included only the stream-based methods.

Since I regard the byte-array methods as just convenience methods, I think that it's nice if they can provide all the same functionality as the stream-based methods but it definitely isn't a requirement -- to me it's OK if the byte-array methods don't support some more arcane cases.

Given that, my reaction to the rfc5653bis drafts is similar (I think) to Greg Hudson's comment on 1 Feb 2015:  the stream-based methods already kinda sorta provide a way to do this -- write the error token to the OutputStream, then throw the GSSException.  For me it's fine that only the stream-based methods support this and the byte-array methods don't, but I understand that others may differ, including of course Weijun.

w.r.t. the main change in the rfc5653bis drafts (i.e. adding the getOutputToken() method to GSSException), ideally I would like to see some tweaks:

(1) In the updated example code for the stream-based methods, the "sendToken(new ByteArrayOutputStream(outTok));" code in the catch-block is bogus (and also won't compile), right?

(2) [Perhaps someone already mentioned this one, maybe Greg?]  The stream-based methods now have two ways that they could convey an error token:  either write it to the OutputStream or return it in the GSSException (but not both, I trust).  I didn't notice any text that specifies (a) what the JGSS implementation is required to do (and not do) w.r.t. this, and (b) what the calling code should / shouldn't expect, but perhaps I overlooked it.  Would the rule be "If the implementation is generating an error token, it must never write any bytes to the OutputStream, and must always return the token in the GSSException", or something else?

(3) GSSException is used throughout the JGSS API:

        http://docs.oracle.com/javase/7/docs/api/org/ietf/jgss/class-use/GSSException.html

but I assume that the only places where GSSException.getOutputToken() can be non-null (and calling code should handle it) are after the two initSecContext() methods and the two acceptSecContext() methods -- right?  That's more or less implicit in the current draft, but could the section 6.8 intro and / or section 6.8.7 be a bit more explicit that getOutputToke() is only pertinent to initSecContext() and acceptSecContext() ?

... but none of them are anywhere close to being "over my dead body" issues.

Overall, given a choice between RFC 5653 and the current rfc5653bis drafts, my 0.02 would be just to keep RFC 5653 as-is, but again that's just a mild preference.