Subject: Re: [kitten] I-D documenting the structure of the GSS negotiation loop

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 5 Nov 2013 12:13:48 -0500 (EST)

On Mon, 28 Oct 2013, Greg Hudson wrote:

> Here are a couple of issues Ben and I discussed before the draft was
> submitted, which Ben thought we could use list input on:
>
> 1. Overlap with 2743
>
> It wasn't immediately clear to me whether this draft is a distillation
> of RFC 2743 or whether it imposes new requirements.  I think there might
> be some new requirements (like "The initiator MUST NOT change any of the
> input parameters to GSS_Init_sec_context() between calls", while 2743
> only mentions the claimant_cred_handle parameter), but they aren't
> differentiated from repeated requirements.

This is probably closely related to whether the new document ends up being 
standards-track or just informational.  If there are no new actual 
requirements, it probably makes sense to have it just be informational. 
On the other hand, maybe we do want requirements like the constancy of 
init/accept_sec_context arguments through the loop (per (2)) to be added, 
in which case it would need to go on the standards track.

I will try to make time to do a close read of 2743 side-by-side with this 
draft, but it would be helpful to have input from other reviewers, too.

> 2. Handling of impossible situations
>
> Sections 2.2 and 2.5 describe what the application "SHOULD" do if GSSAPI
> returns GSS_S_CONTINUE_NEEDED from init/accept_sec_context with an empty
> output token.  This is a nonsense answer from the GSS implementation,
> indicative of a serious bug, and I don't think a spec like this needs to
> describe what applications should do in the face of bugs.  I think most
> applications I have seen will just send an empty token to the other
> side, which will reject it, and that's not a problem.

The thread seems to have mostly diverged into considering whether or not 
an empty token would be appropriate.  The volume of discussion makes me 
suspect that mentioning it in some form is appropriate, though it's 
unclear that the text in my -00 is correct.

> 3. Example code
>
> The draft is written completely at the RFC 2743 level, independent of
> language bindings.  I was sort of expecting a draft like this to have
> example code using the C bindings.  There is already example code for
> gss_init_sec_context and gss_accept_sec_context in RFC 2744, but it
> could perhaps be improved to cover some of the statements in the draft,
> like checking ret_flags after the context is established.

I agree that there would be value in example code, I was just not 
convinced that it was necessary for the -00.  It sounds like there is some 
WG interest in the document; if we decide to adopt it, I'm happy to add 
example code.  Looking at the charter, this work seems to fall under 
"develop extensions and/or updates to the GSS-API", but not any more 
specific items.

On Mon, 28 Oct 2013, Nico Williams wrote:

> I'll review later today in detail.  I think pseudo-code would be nice to

Hmm, maybe I should have sent a reminder sooner.

> have.  I don't mind if it's synchronous-looking pesudo-code: between
> threadlets (the JavaScript literature is filled to the brim, and long
> ago spilled, with libraries along these lines) and such, and programmers
> who know how to turn synchronous code into async code, I don't think
> that's a problem.  I realize that normative text is also desirable, but
> we already have it: in RFC2743.  So for an informative I-D I think
> pseudo-code would be very good to have, and since we have C code in

I don't think the normative/informative question is fully settled yet, 
actually.

> RFC2744, it shouldn't be difficult to adapt.

I agree that the 2744 example code should be easy to adopt.

> Also, given that we have consensus for the channel-bound flag extension
> that introduces a stepper model, I think we'll need to do this again...

Probably.  But, one thing at a time, I suppose.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 13 Nov 2013 13:08:59 -0500 (EST)

On Tue, 5 Nov 2013, Benjamin Kaduk wrote:

> requirements, it probably makes sense to have it just be informational. On 
> the other hand, maybe we do want requirements like the constancy of 
> init/accept_sec_context arguments through the loop (per (2)) to be added, in 
> which case it would need to go on the standards track.
>

Having finished a 2743 re-read, it looks like the only "real" new 
requirement in the -00 of my draft is the one Greg quoted above, "the 
initiator MUST NOT change any of the input parameters to 
GSS_Init_sec_context() between calls" -- 2743 only requires that the 
claimant_cred_handle remain unchanged between calls.  That seems like a 
bug in 2743 (what behavior would one want to get by changing things?), but 
I'll accept that my gss-loop document is not the right place to fix it.

I haven't finished a 2744 re-read yet, but it seems to only note that "a 
typical portable caller should always invoke gss_init_sec_context within a 
loop", with pseudocode that shows all the input arguments to 
gss_init_sec_context() remaining unchanged between calls.  It would be a 
stretch to interpret that as a normative requirement, though.

I use 2119 langauge elsewhere in my document,for things like "MUST 
transmit the context token to the peer", "SHOULD send error tokens", and 
"MUST verify the returned flags", but I think that these can be read as 
reflecting existing requirements in 2743.  (Since 2743 doesn't use 2119 
language, judging what exactly the normative requirements are is a matter 
of interpretation, unfortunately.)  Maybe I don't need to use 2119 
language at all in a document like this.

> The thread seems to have mostly diverged into considering whether or not an 
> empty token would be appropriate.  The volume of discussion makes me suspect 
> that mentioning it in some form is appropriate, though it's unclear that the 
> text in my -00 is correct.

I also used 2119 language for "SHOULD indicate failure to the [peer]" when 
GSS_S_CONTINUE_NEEDED produces an empty token.  The discussions we've had 
have convinced me that I should instead note that 2743 prohibits this 
behavior, but for compatibility with existing deployments, applications 
should [lowercase] transmit such an empty token and/or be prepared to 
accept one.

> I agree that there would be value in example code, I was just not convinced 
> that it was necessary for the -00.  It sounds like there is some WG interest 
> in the document; if we decide to adopt it, I'm happy to add example code. 
> Looking at the charter, this work seems to fall under "develop extensions 
> and/or updates to the GSS-API", but not any more specific items.

-01 will include sample code, probably bits from 2744 with 
modification/correction.

Greg noted in person that a separate sample code for the anonymous 
case would probably be useful, too; I'll try to do that.

> Hmm, maybe I should have sent a reminder sooner.

I don't think we saw anything more from Nico on-list.  Even a "looks okay" 
would be good, I think...

-Ben