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

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

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

Luke Howard
Hi everybody,

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


Cheers,
Luke

Begin forwarded message:

Subject: New Version Notification for draft-howard-gss-sanon-00.txt
Date: 31 March 2020 at 1:24:50 pm AEDT
To: "Luke Howard" <[hidden email]>


A new version of I-D, draft-howard-gss-sanon-00.txt
has been successfully submitted by Luke Howard and posted to the
IETF repository.

Name: draft-howard-gss-sanon
Revision: 00
Title: A Simple Anonymous SASL and GSS-API Mechanism
Document date: 2020-03-30
Group: Individual Submission
Pages: 12
URL:            https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-00.txt
Status:         https://datatracker.ietf.org/doc/draft-howard-gss-sanon/
Htmlized:       https://tools.ietf.org/html/draft-howard-gss-sanon-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon


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.  Through the GS2 family of mechanisms defined in RFC
  5801, these protocols also define how Simple Authentication and
  Security Layer (SASL, RFC 4422) applications may use this mechanism.




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] New Version Notification for draft-howard-gss-sanon-00.txt

Luke Howard
A couple of things I’ll fix in the next draft:

3.  Discovery and Negotiation

   The selection of SAnon is subject to local policy.  If anonymity is
   not desired, mechanisms that provide authentication SHOULD be
   preferred.  Initiators use GSS_C_ANON_FLAG to indicate that anonymous
   authentication is desired; either parties can test this flag to check
   if it was performed.

and

4.1.2.  GSS_C_NT_HOSTBASED_SERVICE

   This name type is typically used by acceptors to identify a host-
   based service.  To allow existing applications to work unmodified
   with SAnon, it is useful to allow anonymous acceptor credentials to
   be acquired regardless of the service name.  (Because SAnon does not
   set GSS_C_MUTUAL_FLAG, the acceptor identity may be safely ignored.)
   When importing a name of this type the name string SHOULD be ignored.

Thoughts on how to support RFC 5801 without setting GSS_C_MUTUAL_FLAG are welcome.

— Luke
_______________________________________________
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-00.txt

Simon Josefsson-2
In reply to this post by Luke Howard
Luke Howard <lukeh=[hidden email]> 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

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

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Luke Howard

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

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.
_______________________________________________
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-00.txt

Luke Howard

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

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.
_______________________________________________
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-00.txt

Luke Howard
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 <[hidden email]> wrote:
>
>
>>> 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.
>>
>> 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.
>
> 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.

_______________________________________________
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-00.txt

Nico Williams
In reply to this post by Simon Josefsson-2
On Sat, Apr 04, 2020 at 01:18:44PM +0200, Simon Josefsson wrote:
> Luke Howard <lukeh=[hidden email]> writes:
> > 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.

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

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