Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd)

[Jeffrey Hutzelman <[e-mail]>]

On Wed, 2013-11-20 at 23:01 -0600, Nico Williams wrote:
> On Wed, Nov 20, 2013 at 07:40:28PM -0500, Benjamin Kaduk wrote:
> > On Thu, 21 Nov 2013, Martin Rex wrote:
> > >It is up to the mechanism implementation at which point during the
> > >handshake the src_name output parameter from gss_accept_sec_context()
> > >is populated.  The application caller MUST provide the exact same
> > >parameter as src_name to *ALL* iteration calls of gss_accept_sec_context()
> > 
> > Having recently completed a re-read of RFC 2743 and RFC 2744 (*),
> > I'm sad to say that I do not believe there is a normative reference
> > to support the MUST, there.  I really wish there was, but RFC 2743
> > only calls out the acceptor_cred_handle as being fixed between
> > iterations.
> 
> Well, no other interpretation is sensible but the one that Martin gave.
> Anything else surely would have been mentioned, and, at any rate, would
> not be sensible.
> 
> Why would the name of the initiator *as output to the application* vary
> as the security context token exchange progresses?

Perhaps there's some stackable thing during which the notion of
initiator name is refined as control passes from one mech to another?


That said, since we are writing advice to application implementors here,
and not a mechanism, the question is not the wide range of what
applications _might_ be allowed to do, but rather what we tell them they
_should_ do.

For initiators, the answer is relatively simple: of course you should
allocate everything up front, pass the same arguments on every call, and
not look at the outputs until context establishment is complete.  Of
course, there's the exception of prot_ready, which is AFAIK the only
output whose semantics are explicitly defined even when the context is
incomplete.

For acceptors, things get a bit dicier, because you have acceptors like
RXGK_GSSNegotiate, which get called once per round trip and want to be
completely stateless in between.  Fortunately for us, actually achieving
that would require the ability to export partially-established contexts,
which is already not well-defined.  Therefore, we can advise that
implementations have little choice but to retain some state, and thus
might as well follow the same conservative approach: allocate everything
up front, and don't look at anything other than prot_ready until the
end.



> It is torturing the language to say that gss_release_buffer() outputs a
> token.  It does not.  It modifies a buffer structure to mark it as
> "empty", but that's it.

Indeed.  At the abstract level, the buffer is not an output.  In the
specific case of the C bindings in RFC2744, the gss_buffer_t is
modified, but that's not the same thing as the buffer being an output;
it's just an artifact of the language bindings.


-- Jeff