[AFS3-std] Finishing the core rxgk document

[Jeffrey Hutzelman]

On Fri, 2013-10-18 at 14:38 -0500, Nico Williams wrote:
> On Fri, Oct 18, 2013 at 02:46:34PM -0400, Jeffrey Hutzelman wrote:
> > On Thu, 2013-10-17 at 23:08 -0400, Benjamin Kaduk wrote:
> > > > - Section 6.2, structure of loop.  I think this is a bit odd and
> > > >   redundant.  The structure of the loop is quite standard; repeating it
> > > >   is useful when the reader doesn't know anything about the GSS-API,
> > > >   but otherwise it could be a source of bugs and confusion.
> > 
> > Unfortunately, while the structure of the loop _should_ be quite
> > standard, there is no standards-track GSS-API document which describes
> 
> RFC2744 has sample C code.  What's wrong with it, besides being C and
> depending on the API in RFC2744?

Well, for starters, it assumes the GSS loop is driving communications
with the peer, rather than the other way around.  In practice, servers
aren't in a loop where they do a "receive token from peer" step.  They
get a message, which may be a GSS token or something else, and act on
it.  Similarly for clients -- there, the client usually _is_ in a loop
driven by context establishment, but it still doesn't control what the
server sends.

In other words, there are a lot of cases the RFC2744 sample code doesn't
cover because it assumes that you get to control whether and when you
receive a non-empty token, when in reality you do not.  A proper
prescription needs to take into account not only the possibility that a
token may not be available when you expect one, but also that one may
arrive when you are not expecting it.

For example, consider what happens if an initiator calls
gss_init_sec_context, gets an output token and GSS_S_COMPLETE, then
sends that token to the server.  The server responds "context
establishment was successful!  Here's a token.".  What is the client
supposed to do with that token?  It no longer has an in-progress context
establishment, so calling gss_init_sec_context would be inappropriate.
Instead, that is a protocol error.  It's not strictly a GSS protocol
error, but it's something the client needs to deal with.


> Keep the text, rewrite it, or remove it.  I don't care -- it's only an
> informational RFC.

Well, no.  It's not Internet standards track, but it is nonetheless
destined to become a standard, and we want it to be right.  Otherwise,
we wouldn't have spent so much time looking for someone to review this
part.



>   KITTEN WG should publish a nice guide RFC sometime
> though.  The problem is that the text as written may have subtle bugs.

It may.  I don't think it does, and this is an exercise I've been
through before.  But I might be wrong, which is why we're having this
discussion.


> For *me* it's much easier to assume all the generic GSS usage
> information I know and apply only the bits that are specific to rxgk.

For most people, myself included, that may lead to subtle bugs.  Better
to get it right once, produce a description, and update it if any
problems are found, than to re-derive it from scratch every time.


> If you'll keep text then I'll need to re-review.  I mostly punted when
> the redundancy annyed me :(
> 
> > There's a reason we described the negotiation in this level of detail in
> > RFC4462.
> 
> Other RFCs for app protocols using GSS also do this.  It's kind of
> annoying...

I don't know about any other app protocols.  At the time we did RFC4462,
I don't think there were any.  A fair amount of time was spent on that
part.  I don't think I've reviewed corresponding text in any other app
protocols, so I can't speak for their quality.  I agree it would be much
better to do this once.

-- Jeff