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

[Nico Williams <[e-mail]>]

On Thu, Nov 21, 2013 at 10:09 AM, Jeffrey Hutzelman <[e-mail]> wrote:
> On Wed, 2013-11-20 at 23:01 -0600, Nico Williams wrote:
>> 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?

I addressed that immediately after asking the question :)  I believe
the correct answer for a mechanism that builds knowledge of the
initiator progressively (with each security context token round trip)
is to output the name only when that process is complete.  As for how
to represent all the details learned about the initiator, that's what
display syntax and name attributes are for.

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

Yes, but that requires considering the constraints on the
mechglue/provider.  In this case they must not output multiple
src_names -- that's just not something existing apps are prepared to
handle and makes no sense.

> 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

The mechglue/provider should either a) not output the src_name (and
deleg cred) until complete, or b) once they output either *keep*
outputing it until complete.  Nothing else is safe w.r.t. existing
applications.

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

No, the mechglue/provider must keep state as described above.

Also, src_name can be left NULL -- the application can use
gss_inquire_context() instead.  So the only real problem here is
deleg_cred_handle.

Nico
--