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

From: Luke Howard <[email-masked]>
Date: Tue, 31 Mar 2020 13:28:11 +1100

Hi everybody,

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

An implementation can be found at: https://github.com/PADL/heimdal/tree/lukeh/sanon/lib/gssapi/sanon <https://github.com/PADL/heimdal/tree/lukeh/sanon/lib/gssapi/sanon>

Cheers,
Luke

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-howard-gss-sanon-00.txt
> Date: 31 March 2020 at 1:24:50 pm AEDT
> To: "Luke Howard" <[email-masked]>
> 
> 
> 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
> 
>

---

From: Luke Howard <[email-masked]>
Date: Wed, 1 Apr 2020 10:36:32 +1100

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