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

[Nico Williams <[e-mail]>]

 - Section 1

   Another potential use of SAnon would be as a substrate for
   constructing other mechanisms.

   (Recall discussion of "stackable" mechanisms... what, 15 years ago?)

 - Section 3, regarding NegoEx...

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

   I see you're aiming to publish this on the Experimental Track.  If
   you want to eventually get on the Standards Track (why not now?),
   [I-D.zhu-negoex] not being an RFC (let alone a Standards-Track RFC)
   would block this document's progress.  Phrasing this as a requirement
   imposed by [I-D.zhu-negoex], or not mentioning it at all, would cure
   that problem.

 - Section 3

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

   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.

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

   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.

   Another option would be to say that SPNEGO/NegoEx can only negotiate
   SAnon when it is explicitly a credential element in the initiator's
   non-default credential or it is referenced in GSS_Set_neg_mechs().
   This approach imposes no need to update SPNEGO/NegoEx.

|      [...].  Initiators use GSS_C_ANON_FLAG or the well known
|  anonymous credential to indicate that anonymous authentication is
|  desired.  Either party can test for the presence of GSS_C_ANON_FLAG
|  to check if anonymous authentication was performed.

   Or the default credential and a GSS_C_NT_ANONYMOUS name for the
   target acceptor!

   It may be useful to enumerate the ways to end up using SAnon.

 - Section 4.1.1

   The SHOULD in this section should be a MUST.

 - Section 4.1.2

   Huh!  Works for me.

 - Section 4.1.3

   Perhaps we could say this for all name-types on the acceptor side.

 - Section 4

   It's important to state that the name as observed by the peer is
   always GSS_C_NT_ANONYMOUS.

   This should probably be its own sub-session inserted before 4.1.

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


More later,

Nico
--