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

From: Simon Josefsson <[email-masked]>
Date: Sat, 04 Apr 2020 13:18:44 +0200

Luke Howard <lukeh=[email-masked]> writes:

> Hi everybody,
>
> Below is a specification for a simple anonymous mechanism based on
> curve25519 that does not authenticate either initiator or acceptor.

Interesting!  When would this be useful in SASL?  GS2 requires that the
mechanism supports mutual authentication, so while I definitely see
value in having this as a GSS-API mechanism I don't understand when it
would provide value for a SASL application, and how it would actually
work in GS2.

/Simon

---

From: Luke Howard <[email-masked]>
Date: Sat, 4 Apr 2020 22:23:08 +1100

> would provide value for a SASL application, and how it would actually

I hadn’t really thought through the GS2 use case, to be honest. Remind me (sorry if it’s a dumb question) why GS2 requires mutual?

It does support channel bindings because the key derivation includes the channel binding application data.

---

From: Luke Howard <[email-masked]>
Date: Sat, 4 Apr 2020 22:26:13 +1100

> It does support channel bindings because the key derivation includes the channel binding application data.

Ah yes, SASL GS2 doesn’t give you message protection does it. So you can’t actually do anything much useful with the resulting context.

---

From: Luke Howard <[email-masked]>
Date: Sat, 4 Apr 2020 22:36:38 +1100

Another question: should GSS_C_MA_AUTH_INIT_ANON/GSS_C_MA_AUTH_TARG_ANON be set? Is a mechanism valid if it sets neither of these attributes? (Nico?)

> On 4 Apr 2020, at 10:26 pm, Luke Howard <[email-masked]> wrote:
> 
>

---

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

> would provide value for a SASL application, and how it would actually

Add an option to use previously-agreed peer PKs and you have
authentication.

Add a way to lookup a peer's PK by name and you have a modern version of
mech_dh.

For those who don't know or don't remember, mech_dh is a GSS version of
AUTH_DH, and both are premised on using long-term DH keys for key
agreement and authentication, with a directory mapping "netnames"
(principal names) to public keys.  The directory had a files backend
(/etc/publickey) as well as a NIS+ and LDAP backends -- today we'd use
DNSSEC as well, naturally.

(For human principals, their mech_dh private keys could be stored in the
directory encrypted in their passwords, which then allows the equivalent
of "kinit" -- this, however, is a very bad idea, as it allows anyone to
mount off-line dictionary attacks.  Instead, a login protocol should be
required to obtain user private keys.)

Mech_dh even has a half round-trip variant, naturally.  It's remarkably
similar to Kerberos while having nothing like a KDC/AS/TGS -- just a
passive directory instead.

This was the original way that DH was intended to be used by its
inventors!

SAnon can trivially be extended to be the new mech_dh: just allow the
use of  raw public keys as desired_names for credential acquisition and
for acceptor target_names.  The initial context token has to more than
double in length: so the desired acceptor can be identified and a nonce
be conveyed.  A nonce is important in this construction, as otherwise
we'd have key reuse, though in the Kerberos cryptosystem, that's not so
important given that we use confounders, but still, it would be
essential for GSS_Pseudo_random().

Nico
--