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

From: Luke Howard <[email-masked]>
Date: Sun, 5 Apr 2020 10:02:30 +1000

Changes:

Remove references to SASL GS2 (thanks Simon)
Explanation of initiator name-based anonymous authentication selection, and compromises it entails
Remove GSS_C_MA_AUTH_INIT/TARG mechanism attributes
Fix IANA considerations to ask for OID
General cleanups

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-howard-gss-sanon-01.txt
> Date: 5 April 2020 at 9:58:41 am AEST
> To: "Luke Howard" <[email-masked]>
> 
> 
> A new version of I-D, draft-howard-gss-sanon-01.txt
> has been successfully submitted by Luke Howard and posted to the
> IETF repository.
> 
> Name:		draft-howard-gss-sanon
> Revision:	01
> Title:		A Simple Anonymous GSS-API Mechanism
> Document date:	2020-04-05
> Group:		Individual Submission
> Pages:		10
> URL:            https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-howard-gss-sanon/
> Htmlized:       https://tools.ietf.org/html/draft-howard-gss-sanon-01
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-howard-gss-sanon-01
> 
> Abstract:
>   This document defines protocols, procedures and conventions for a
>   Generic Security Service Application Program Interface (GSS-API)
>   security mechanism that provides key agreement without authentication
>   of either party.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
>

---

From: Nico Williams <[email-masked]>
Date: Sun, 5 Apr 2020 18:49:31 -0500

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

---

From: Nico Williams <[email-masked]>
Date: Sun, 5 Apr 2020 19:44:45 -0500

>         -> base64_encode(hash(dh_pubkey))

Even better: base64(dh_pubkey).

And even better too if that can be used as a target name.

Then we'd have the building blocks of a modern mech_dh.

 - Section 6.1.2

   The acceptor should also send a MIC along with the key, thus proving
   it has possession of the shared secret.  This is important, otherwise
   reply tokens could be replayed, and though it wouldn't be much of an
   attack, it's worth doing.

 - Section 6

   There should be a requirement that new DH keys be generated every
   time, no?  Especially on the initiator side, and especially if you
   don't add the use of a MIC in the response token (see previous
   comment).

 - If you allow a target name to be imported as an anonymous name whose
   value is the base64 encoding of a raw public key, then the initial
   context token should send two public keys, and the response token
   should be just a MIC.

   I->A: {PK_i, PK_a}
   A->I: MIC(SK, {PK_i, PK_a}) || <error>

         (ahh, you'd have to define an error message, but it could just
          be a 1-byte code)

   Note that to reuse keys really does require nonces.  So those would
   have to be added:

   I->A: {PK_i, PK_a, nonce}
   A->I: MIC(SK, {PK_i, PK_a}) || <error>

   You could even have a half round-trip variant where the initiator
   sends {PK_i, PK_a, nonce, MIC} and the acceptor sends nothing.

   The length of the initiator context token would say all that's
   needed -- no ASN.1/DER or whatever would be needed.

 - Section 7

|  context       the concatenation of the initiator and acceptor public
|                keys, along with the channel binding application data
|                (if present)

   Add "in that order"?

 - Section 7

|  The session key K1 is used as the base key for the generation of per-
|  message tokens and the GSS-API PRF.  The encryption type of K1 is
|  aes128-cts-hmac-sha256-128 as defined in [RFC8009].

   There should be a reference here to RFC4121.  Also, RFC4121 doesn't
   mention a K1.  I suspect you need to state how to derive a key of the
   enctype (aes128-cts-hmac-sha256-128) that would be equivalent to the
   AcceptorSubkey.  You might want to mention that four keys are to be
   derived from that per RFC4121 section 2, plus the GSS_Pseudo_random()
   key (GSS_C_PRF_KEY_FULL) [RFC8009].

 - Test vectors?

 - Section 10

   This section should repeat something about the importance of SAnon
   not being negotiated when it's not appropriate.

Done.

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Mon, 6 Apr 2020 10:51:01 +1000

Hi Nico,

Thanks for your feedback as usual!

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

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

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

>   Hmm, I'd say that if "anonymity is not desired" then SAnon MUST NOT

Fixed.

>   initiator imposes on SPNEGO/NegoEx, so an update might be

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

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

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

---

From: Nico Williams <[email-masked]>
Date: Sun, 5 Apr 2020 20:10:27 -0500

On Mon, Apr 06, 2020 at 10:51:01AM +1000, Luke Howard wrote:
> 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.

> We could say may be subject to application and/or local policy but
> simpler to remove the sentence, which I have done.

+1

>       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

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.

> >   initiator imposes on SPNEGO/NegoEx, so an update might be

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

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

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

---

From: Luke Howard <[email-masked]>
Date: Mon, 6 Apr 2020 11:24:31 +1000

Hi Nico,

> Then we'd have the building blocks of a modern mech_dh.

Agreed. I would like to implement mech_ecdh. :) But I would also like to avoid scope creep for SAnon due to time and funding constraints.

>   attack, it's worth doing.

Happy to add this, but is it much of an attack? Both parties are anonymous, so (as we discovered with GS2) this mechanism is completely superfluous unless you intend to use a message protection service (or PRF), which will fail in a replay attack.

Having said that: is there value in the putative MIC being of the public keys (as opposed to a constant) given the public keys are already input to the KDF?

>   don't add the use of a MIC in the response token (see previous

I will clarify the text to say that it must be a fresh key pair.

>   sends {PK_i, PK_a, nonce, MIC} and the acceptor sends nothing.

How does the initiator learn of the acceptor’s public key? It seems to me this is useful for mech_ecdh but not SAnon?

>   Add "in that order”?

Fixed.

>   key (GSS_C_PRF_KEY_FULL) [RFC8009].

How about:

   This session key is equivalent to the acceptor-asserted subkey
   defined in [RFC4121] Section 2 and is used as the base key for
   generating keys for per-message tokens and the GSS-API PRF.

   The session key encryption type is aes128-cts-hmac-sha256-128 as
   defined in [RFC8009].  The [RFC3961] algorithm protocol parameters
   are as given in [RFC8009] Section 5.

I’ll also add a note in 6.2 that AcceptorSubkey MUST be set.

> - Test vectors?

I will add.

>   not being negotiated when it's not appropriate.

“It MUST not be selected if either party requires identification of its peer.” – is that OK? I would prefer not to use the word negotiated, as SAnon can be explicitly selected outside of SPNEGO/NegoEx.

Cheers,
Luke

---

From: Luke Howard <[email-masked]>
Date: Mon, 6 Apr 2020 11:28:12 +1000

> having to also progress NegoEx.

We can do this but, then we have an interoperability problem (unless we say it’s always negotiable directly under SPNEGO as well as NegoEx if available?).

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

Fixed.

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

Hah, got me. Fixed.

— Luke

---

From: Nico Williams <[email-masked]>
Date: Mon, 6 Apr 2020 10:28:30 -0500

On Mon, Apr 06, 2020 at 11:35:37AM +1000, Luke Howard wrote:
> The progressing requirement is not an issue if SAnon is experimental
> track, though?

It's not, but there's no reason for SAnon not to make it to the
Standards Track either...

The simplest thing to do is to say that the requirement about NegoEx is
only for initiators that implement NegoEx.  Heck, you might not even
need to say anything: NegoEx itself already imposes that requirement,
does it not?  If so, why restate it here?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 6 Apr 2020 10:43:27 -0500

On Mon, Apr 06, 2020 at 11:24:31AM +1000, Luke Howard wrote:
> Agreed. I would like to implement mech_ecdh. :) But I would also like
> to avoid scope creep for SAnon due to time and funding constraints.

Understood.  SAnon will be a trivial base for a new mech_dh.

> Happy to add this, but is it much of an attack? Both parties are
> anonymous, so (as we discovered with GS2) this mechanism is completely
> superfluous unless you intend to use a message protection service (or
> PRF), which will fail in a replay attack.

For pure GSS/SAnon apps it probably makes no difference, but it might
for future stacks combining SAnon with other things.

> Having said that: is there value in the putative MIC being of the
> public keys (as opposed to a constant) given the public keys are
> already input to the KDF?

It can be a MIC over the empty string.

> >   [...]
> How does the initiator learn of the acceptor’s public key? It seems to
> me this is useful for mech_ecdh but not SAnon?

There's two options: the mech_dh method (add a directory) and
leap-of-faith (learn the keys once, keep reusing them.

You wanted to leave the mech_dh thing out of scope, so let's do that.

In Sun's mech_dh there were pluggable name service switch modules for
the "publickey" DB, with files, nisplus, and ldap shipping in Solaris.
That was... a long time ago.  Today we'd use DNS w/ DNSSEC (DANE).

The leap-of-faith thing would work like this: the initiator uses
well-known anon names to set up a security context with some acceptor,
then inquires the resulting initiator and acceptor names, and later sets
up new contexts using the same keys (which might not work if the private
keys are gone).  To make this work at all we'd need a bit on the wire
for indicating that you want the keys to be less-ephemeral.

Anyways, forget the leap-of-faith case for now too.

> I’ll also add a note in 6.2 that AcceptorSubkey MUST be set.

Works for me!

> “It MUST not be selected if either party requires identification of
> its peer.” – is that OK? I would prefer not to use the word
> negotiated, as SAnon can be explicitly selected outside of
> SPNEGO/NegoEx.

Works for me!

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 6 Apr 2020 14:52:16 -0500

> for future stacks combining SAnon with other things.

Well, one nice thing about the MIC is that it allows the initiator to
detect CB failure earlier.  Heck, if the application protocol were to
only have per-message tokens flowing from the initiator to the acceptor,
then the initiator would never find out about CB failures.  So we want
the MIC.

(Not that CB is terribly useful in a mechanism that provides no
authentication, but let's ignore that for this purpose.)

---

From: Luke Howard <[email-masked]>
Date: Tue, 7 Apr 2020 08:59:14 +1000

Jeff suggests informational track.

I’ve fixed the NegoEx thing anyway in the most recent draft.

The NegoEx authors did not envisage a mechanism being negotiated under both SPNEGO and NegoEx, so it doesn’t say anything about the preference order of such a mechanism. (It was possible to build such a mechanism up to Windows 8, but this was an accident that was then corrected.)

MIT and Heimdal support mechanisms being negotiable under both and always preference negotiating it under NegoEx.

Luke Howard
web <http://lukehoward.com/> / facebook <https://www.facebook.com/lukehowardmusic> / instagram <http://instagram.com/lukehowardmusic/> / spotify <https://open.spotify.com/artist/3duTXsC49HoPt4f4EySDKf>

> On 7 Apr 2020, at 1:28 am, Nico Williams <[email-masked]> wrote:
>

---

From: Luke Howard <[email-masked]>
Date: Tue, 7 Apr 2020 09:02:32 +1000

> for future stacks combining SAnon with other things.

Fixed in draft and implementation. It is (as we discussed off-list) a MIC of the empty string.

> for indicating that you want the keys to be less-ephemeral.

Given mech_ecdh will be a new mechanism with a new OID (and GUID!), then we can change the wire format to include a flags field.

Thanks again for the input!

Cheers,
Luke

---

From: Luke Howard <[email-masked]>
Date: Tue, 7 Apr 2020 11:59:59 +1000

> On 7 Apr 2020, at 11:51 am, Jeffrey E Altman <[email-masked]> wrote:
> 
>> The NegoEx authors did not envisage a mechanism being negotiated under
>> both SPNEGO and NegoEx, so it doesn’t say anything about the preference
>> order of such a mechanism. (It was possible to build such a mechanism up
>> to Windows 8, but this was an accident that was then corrected.)
> 
> I don't believe that SAnon is a good choice for SPNEGO.  One reason I
> want to negotiate it under NegoEx is to prefer krb5-anon if its
> configured and only use SAnon for the case where krb5-anon is unavailable.

That should be fine anyway, as long as Kerberos is ordered before SAnon (which is in our implementation, SAnon is ordered after not only the built-in mechanisms, but dynamically loaded ones as well).

We seem to have one vote for NegoEx-only, one against; I’m neutral (slight preference towards NegoEx-only). What to do?

— Luke

---

From: Nico Williams <[email-masked]>
Date: Mon, 6 Apr 2020 21:37:25 -0500

On Mon, Apr 06, 2020 at 09:51:40PM -0400, Jeffrey E Altman wrote:
> On 4/6/2020 6:59 PM, Luke Howard wrote:
> In my opinion getting something shipped quickly requires a private
> organization oid and informational track.   We should publish NegoEx as
> informational as well since we are going to depend on it.

I don't think anything prevents quick publication, whether on the
Experimental or Informational tracks.

> I don't think there is any benefit to experimental since NegoEx is
> unpublished.  I suspect that all of the original Microsoft editors have
> moved on.

I don't see how NegoEx not being an RFC has anything to do with which of
Experimental or Informational this I-D goes onto.

> configured and only use SAnon for the case where krb5-anon is unavailable.

Apps can set preference.  Otherwise local configuration can set
preference.  NegoEx or no NegoEx makes no difference to this.  The only
reason to discuss NegoEx at all is that Windows apparently insists on it
for new mechanisms, but as we have NegoEx widely implemented now, it
almost doesn't matter.

---

From: Nico Williams <[email-masked]>
Date: Mon, 6 Apr 2020 21:39:23 -0500

On Tue, Apr 07, 2020 at 11:59:59AM +1000, Luke Howard wrote:
> We seem to have one vote for NegoEx-only, one against; I’m neutral
> (slight preference towards NegoEx-only). What to do?

IMO you can simply not even mention it.  If you must say anything about
negotiation, you can speak of it generically -- after all, GSS envisions
arbitrary mechanism-negotiation pseudo-mechanisms, not just SPNEGO, or
SPNEGO+NegoEx.

Nico
--

---

From: Jeffrey E Altman <[email-masked]>
Date: Mon, 6 Apr 2020 21:51:40 -0400

Jeffrey Altman