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

[Luke Howard <[e-mail]>]

Hi Nico,

Thanks for your feedback as usual!

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

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

>   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

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

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.

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.

> |                                              [...].  If anonymity is
> |  not desired, mechanisms that provide authentication SHOULD be
> |  preferred.  [...]
> 
>   Hmm, I'd say that if "anonymity is not desired" then SAnon MUST NOT
>   be used.

Fixed.

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

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

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

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

Cheers,
Luke