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

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Luke Howard
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:

Subject: New Version Notification for draft-howard-gss-sanon-01.txt
Date: 5 April 2020 at 9:58:41 am AEST
To: "Luke Howard" <[hidden email]>


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




_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
On Sun, Apr 05, 2020 at 06:49:31PM -0500, Nico Williams wrote:

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

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Luke Howard
In reply to this post by Nico Williams
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
_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Luke Howard
In reply to this post by Nico Williams
Hi Nico,

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

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.

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

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?

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

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

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

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

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

Fixed.

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

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.

> - Section 10
>
>   This section should repeat something about the importance of SAnon
>   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
_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Luke Howard
In reply to this post by Nico Williams
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 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?).

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

Fixed.

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

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

Hah, got me. Fixed.

— Luke

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
In reply to this post by Luke Howard
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.

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

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

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

Works for me!

> > - Test vectors?
>
> I will add.
>
> > - Section 10
> >
> >   This section should repeat something about the importance of SAnon
> >   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.

Works for me!

Nico
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
On Mon, Apr 06, 2020 at 10:43:27AM -0500, Nico Williams wrote:

> On Mon, Apr 06, 2020 at 11:24:31AM +1000, Luke Howard wrote:
> > > - 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.
> >
> > 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.

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Luke Howard
In reply to this post by Nico Williams
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

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

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


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Luke Howard
In reply to this post by Nico Williams

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

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

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

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
_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey E Altman
In reply to this post by Luke Howard
On 4/6/2020 6:59 PM, Luke Howard wrote:
> Jeff suggests informational track.

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 there is any benefit to experimental since NegoEx is
unpublished.  I suspect that all of the original Microsoft editors have
moved on.
> 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.)

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.

Jeffrey Altman


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

jaltman.vcf (283 bytes) Download Attachment
smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Luke Howard

On 7 Apr 2020, at 11:51 am, Jeffrey E Altman <[hidden email]> 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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
In reply to this post by Jeffrey E Altman
On Mon, Apr 06, 2020 at 09:51:40PM -0400, Jeffrey E Altman wrote:
> On 4/6/2020 6:59 PM, Luke Howard wrote:
> > Jeff suggests informational track.
>
> 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.

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

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.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
In reply to this post by Luke Howard
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
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten