Re: [kitten] New Version Notification for draft-howard-gss-sanon-01.txt

[Nico Williams <[e-mail]>]

On Mon, Apr 06, 2020 at 10:51:01AM +1000, Luke Howard wrote:
> > |  The means of discovering GSS-API peers and their supported mechanisms
> > |  is out of this specification's scope.  However, when the Simple and
> > |  Protected Negotiation mechanism (SPNEGO) defined in [RFC4178] is
> > |  used, the mechanism MUST be negotiated under [I-D.zhu-negoex].  [...]
> > 
> >   Hmm, well, can this MUST be relaxed to apply only when the initiator
> >   supports [I-D.zhu-negoex]?  Alternatively, maybe remove it.  After
> >   all, [I-D.zhu-negoex] imposes the requirement, not this document.
> 
> If we wish to support interoperability with SSPI for both initiators
> and acceptors, then to me it makes sense to require NegoEx. We could
> make the mechanism negotiable under both SPNEGO directly and NegoEx
> but it seems that we should avoid that if possible in the interests of
> simplicity. Although SAnon could be deployed as a pluggable mechanism,
> in reality I imagine it will arrive after shipping NegoEx (both MIT
> and Heimdal have it).

All I'm saying is that where a GSS implementation doesn't support NegoEx
there should not be a requirement that NegoEx be used.  Relaxing the
requirement this way will make it possible for SAnon to progress without
having to also progress NegoEx.

> > |  The selection of SAnon is subject to local policy.  [...]
> > 
> >   Did you mean, its selection via SPNEGO/NegoEx?  But apps can use
> >   GSS_Set_neg_mechs(), so I'd say that selection is not a matter of
> >   local policy, except in any case where multiple mechanisms are
> >   supported by both the initiator and the acceptor, and no preference
> >   can be gleaned from the applications (is that possible?)
> 
> We could say may be subject to application and/or local policy but
> simpler to remove the sentence, which I have done.

+1

> >   In any case, I think you might want to say that when using the
> >   default credential and a non-anonymous target name, and when
> >   GSS_Set_neg_mechs() was not used (or was used and did not list
> >   SAnon), then SAnon MUST NOT be negotiated.
> 
> Suggest the following text (the third case is new):
> 
>    On the first call to GSS_Init_sec_context(), the mechanism checks
>    for one of the following:
> 
>       The caller set anon_req_flag (GSS_C_ANON_FLAG); or
> 
>       The claimant_cred_handle identity is the well known anonymous
>       name; or
> 
>       The claimant_cred_handle is the default credential and targ_name
>       is the well known anonymous name

I'd change the last item to:

   The claimant_cred_handle is the default credential and targ_name is
   an anonymous name.

There's no need to say "well known anonymous name".

>    If neither of the above are the case, the call MUST fail with
>    GSS_S_UNAVAILABLE.

That's three conditions, s/neither/none/ :)

> I don’t think it’s necessary to point out that GSS_Set_neg_mechs() can
> be used to exclude SAnon, because this is not specific to this
> mechanism.

Well, if GSS_Set_neg_mechs() is used to exclude SAnon then SAnon's
init_sec_context() can't be invoked, so, indeed, there's no need to
point that out.

> Using GSS_Set_neg_mechs() to force SAnon when it would otherwise not
> be used would be an abstraction violation (at lease
> implementation-wise). Applications can use GSS_C_ANON_FLAG.

Fair point.

> >   Also, phrasing it as "mechanisms that .... SHOULD be preferred"
> >   sounds like an update to SPNEGO/NegoEx.  Indeed, the need to
> >   understand that SAnon cannot authenticate the acceptor to the
> >   initiator imposes on SPNEGO/NegoEx, so an update might be
> >   unavoidable.

(Actually, the mech attrs mean that SPNEGO/NegoEx can know that SAnon
doesn't authenticate the target.)

> I suppose I was looking for some text to reflect that in our
> implementation, SAnon is at the very end of the list of preferred
> mechanisms (even after runtime loaded ones).

Sure, so make that clear and downcase that SHOULD?

> > - Section 4
> > 
> >   It's important to state that the name as observed by the peer is
> >   always GSS_C_NT_ANONYMOUS.
> 
> I’ll put this text in the GSS_C_NT_ANONYMOUS description (not sure if
> it needs its own section?) and also move the text directly under
> Section 4 re: names as a mechanism selection hint, to a new section.

Sure.

> > - Section 4.1.4
> > 
> >   The name string displayed should either be a constant OR, better yet,
> >   a base64-encoded hash of the peer's DH key!  The latter especially
> >   after context establishment.
> > 
> >    - GSS_Display_name(GSS_Canonicalize_name(
> >                         mech=SAnon,
> >                         name=GSS_Import_name(GSS_C_NT_ANONYMOUS, "whatever")))
> >        -> "whatever"
> > 
> >    - GSS_Display_name(GSS_Inquire_context_peer_name(context))
> >        -> base64_encode(hash(dh_pubkey))
> 
> This makes sense for a mechanism that supports non-ephemeral keys but
> I believe this is out of scope for SAnon. ;)

I've a feeling that even for SAnon these could be useful.

Nico
--