[AFS3-std] Finishing the core rxgk document

[Nico Williams]

On Fri, Oct 18, 2013 at 04:13:41PM -0400, Jeffrey Hutzelman wrote:
> On Fri, 2013-10-18 at 14:38 -0500, Nico Williams wrote:
> > 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.

Notionally a synchronous I/O loop is sufficient.  Async I/O event loop
conversions are straightforward.  Any English prose to describe this is
going to look a lot like the code in RFC2744 ("when the server receives
a token" is very much compatible with async, but such text would be
embedded in very synchronous first-this-then-that text).

Also, if you have a notion of thread-lets then your code will look
remarkably like the code in RFC2744.

if I were writing a new RFC to describe how to use the GSS-API, I might
do something exactly along those lines, and the end result would be very
similar to the code in RFC2744.

IOW, I don't care for this particular objection.

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

It must call GSS_Process_context_token().  In practice this could only
happen if the server called GSS_Delete_sec_context(), which is
deprecated, so this shouldn't happen, and if it does then the client
might as well assume that's what happened, and assume a server-side
error.

> Instead, that is a protocol error.  It's not strictly a GSS protocol
> error, but it's something the client needs to deal with.

See above.

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

Hmm, OK well, when it gets to the Standards-Track we could put more
effort into it.  Or if you'd like to write better text, feel free to
adapt the text from RFC4462.

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

Then leave it alone.  I'll re-read it later.

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

As long as you get the req/ret_flags, error token/signalling,
authorization message, and target_name parts right it's very hard to end
up with a subtle bug: there's not that much variation allowed here.

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

DNS GSS-TSIG, SASL/GS1, SASL/GS2, RPCSEC_GSS, ...

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

Well, it's on my ever-growing list.  Somewhere near the bottom.