Subject: [sasl] WLGC summary for SCRAM and GS2

From: Tom Yu <[email-masked]>
Date: Fri, 21 Aug 2009 01:05:12 -0400

SCRAM:

Looks ready to me.  The WGLC issues were mostly editorial in nature,
all of which are resolved as far as I can tell.  I will forward it on
to the IESG, probably in the next few days.

In the IANA considerations, it's not clear whether the consensus was
for "IETF Consensus" or "Standards Action", but the current revision
of the document says "IETF Consensus" and I have heard no objections.

GS2:

Looks ready except for IANA considerations.

After noticing the IANA situation with SCRAM, I looked at the GS2
document and determined:

* It doesn't clearly indicate that it is registering a SASL mechanism
  family.

* There is no stated IANA registration policy for GS2 mechanisms.  I
  would guess that Expert Review is desired (e.g., who gets to decide
  that a proposed mechanism registration conforms to the GS2
  specification?) but would like to hear some confirmation of whether
  this is the consensus.

-- 
Tom Yu
IETF SASL WG co-chair

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Aug 2009 00:24:17 -0500

> of the document says "IETF Consensus" and I have heard no objections.

For SCRAM with different hash functions?  IETF consensus, even expert
review[*], should do if the only thing that differs w.r.t. the original is
the hash function and the mechanism name, else Standards Action. 

> * It doesn't clearly indicate that it is registering a SASL mechanism

Well, it's almost clear enough.  On page 19, in the registration for the
GS2- prefix we could add the word "family" after "mechanism" in the
Subject line.

>   specification?) but would like to hear some confirmation of whether

Mechanism names with prefix GS2- are either registed by this I-D or else
they are OID-derived, in which case no registration is needed.  The
registration of the GS2- prefix stops at disallowing registration of
GS2-* mechanism names:

   The IANA is advised that SASL mechanism names starting with "GS2-"
   are reserved for SASL mechanisms which conform to this document.  The
       ^^^^^^^^

I don't recall which one of us wrote that, but I think we meant that
"registrations of mechanism names that start with GS2- are disallowed".
Perhaps we should make that more explicit?

Any GSS-API mechanism that provides channel binding support and which is
not one of the mechanisms listed in this I-D[**] may be used as a GS2
mechanism without registration unless one wishes to use a mechanism name
that does not begin with GS2-.

[*]  Well, as we learned in the case of the channel binding registry,
     it's useful to have RFCs to reference.  Therefore expert review for
     SCRAM variants is probably not a good idea.

[**] The krb5 GSS mech and SPNEGO, the latter being disallowed.

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 21 Aug 2009 14:32:36 +0100

>the hash function and the mechanism name, else Standards Action. 
Agreed. So no change needed.

>Well, it's almost clear enough.
>
I think it is. I think we've used "*" in a SASL mechanism registration 
before.

>On page 19, in the registration for the
That would be fine as well.

>Perhaps we should make that more explicit?
I don't have a problem with registering a mechanism name starting with 
GS2-, as long as it conforms to the GS2 spec.
I think this is what "reserved" means here.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 21 Aug 2009 11:41:31 -0400

> Perhaps we should make that more explicit?

Yes, I agree that's what we meant, mostly.  IANA should not ever register 
mechanism names which could confilict with OID-derived names.  However, I 
thought we wanted to allow for the possibility of registering friendly GS2 
mechanism names for future GSSAPI mechanisms, provided the registration 
happens when the mechanism is defined.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 21 Aug 2009 12:21:58 -0400

> I think this is what "reserved" means here.

It's important that we not do that for already-existing GSSAPI mechanisms, 
in order to avoid the interoperability problems that arise from having two 
names for the same mechanism.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Aug 2009 11:14:12 -0500

> happens when the mechanism is defined.

We do allow for friendly GS2 mechanism names for future GSSAPI
mechanisms.  But there's nothing much for the GS2 RFC to say about that,
unless...

... we want to make sure that the registry says whether any SASL
mechanism that doesn't start with GS2- is a GS2 mechanism nonetheless.
How would we actually achieve this?  Wouldn't that make the GS2 document
update the base SASL spec by changing the SASL mechanism name
registration rules?

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 21 Aug 2009 12:32:52 -0400

--On Friday, August 21, 2009 11:14:12 AM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> Yes, I agree that's what we meant, mostly.  IANA should not ever
>> register  mechanism names which could confilict with OID-derived names.
>> However, I  thought we wanted to allow for the possibility of
>> registering friendly GS2  mechanism names for future GSSAPI mechanisms,
>> provided the registration  happens when the mechanism is defined.
>

Nevermind; I was confused.  Friendly names wouldn't start with "GS2-"; that 
prefix is reserved for OID-derived names.  In which case IANA shouldn't 
ever assign names with that prefix; this document reserves them all to 
avoid conflicts with the algorithmic names.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 21 Aug 2009 13:44:18 -0400

--On Friday, August 21, 2009 12:26:29 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

> On Fri, Aug 21, 2009 at 12:21:58PM -0400, Jeffrey Hutzelman wrote:
>> It's important that we not do that for already-existing GSSAPI
>> mechanisms,  in order to avoid the interoperability problems that arise
>> from having two  names for the same mechanism.
>
> I think that Alexey meant that GS2 mechs without a friendly SASL mech
> name could be registered with their OID-derived GS2 mech names.
>
> That'd be fine, though not necessary, and would require careful review
> to make sure that there are no mistakes in the name derivation.

Ew.  IANA should just not accept registrations for those, period.

> Incidentally, we say nothing about what to do in the case of OID-derived
> name collisions...  We should!  And what can we say about that, short of
> allowing/recommending registration of GS2-* OID-derived names?

Assign your mech a new OID. :-)

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Aug 2009 12:26:29 -0500

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Aug 2009 12:31:29 -0500

> Nevermind; I was confused.  Friendly names wouldn't start with "GS2-"; that 

Right.

> avoid conflicts with the algorithmic names.

Yes.  But see my other note about hash collisions.

Also, what about GS2 SASL friendly names registration after the GSS-API
mechanism is specified?  I see two possible solutions:

 - don't do that; if a GSS mechanism has no friendly SASL mech name
   when the GSS mechanism specification is published, then that
   mechanism gets stuck with an OID-derived name

or

 - let gss_inquire_mech_for_saslname() return two names: the friendly
   one, if there is one, and the OID-derived name in any case.  Clients
   MUST use the friendly name, if there is one, servers MUST accept the
   friendly name if there is one, MUST/SHOULD accept the OID-derived
   name even if there is a friendly name.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Aug 2009 12:45:32 -0500

> Ew.  IANA should just not accept registrations for those, period.

That would be my preference as well.

> Assign your mech a new OID. :-)

I suppose that's possible, though it might be easier to register a
friendly SASL name for it instead.

I think we should change gss_inquire_mech_for_saslname() to output both,
the friendly name (if there is one) and the OID-derived name.  If
there's a collision amongst locally available mechs' OID-derived name,
then don't output the OID-derived names for the afflicted mechs.  And we
should say that clients MUST use the friendly name, if there is one, and
servers MUST accept friendly names, and MUST accept OID-derived names
(except in the case of collisions amongst locally available mechs).

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 21 Aug 2009 14:43:58 -0400

--On Friday, August 21, 2009 12:45:32 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> > Incidentally, we say nothing about what to do in the case of
>> > OID-derived name collisions...  We should!  And what can we say about
>> > that, short of allowing/recommending registration of GS2-* OID-derived
>> > names?
>>
> the friendly name (if there is one) and the OID-derived name.

I think we should not institutionalize the practice of using two distinct 
names for a single mechanism.  If a mechanism has a friendly name, that is 
the only name for that mechanism, period.

>  If

You're worrying too much about collisions.  They'll probably never happen, 
which is the assumption we've made in other cases where we used hashed 
OID's to identify mechanisms.  What is more likely to happen, IMHO, is the 
existence of two or more mechanisms with long OID's that differ only near 
the end; using a hash mitigates this problem.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Aug 2009 14:01:57 -0500

> the only name for that mechanism, period.

I'd like that to be so, but I'm not sure we can enforce this.  At the
very least this means that any GSS mech that did not have a friendly
SASL name when first specified and deployed may never have one.  We need
to state that clearly.

> You're worrying too much about collisions.  They'll probably never happen, 

True.  Right.  I'm happy to ignore this likely non-problem.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 21 Aug 2009 15:35:19 -0400

--On Friday, August 21, 2009 02:01:57 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> I think we should not institutionalize the practice of using two
>> distinct  names for a single mechanism.  If a mechanism has a friendly
>> name, that is  the only name for that mechanism, period.
>

Yes, we do.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Aug 2009 15:39:31 -0500

> >SASL name when first specified and deployed may never have one.  We need

OK, so I propose the following text:

 - at the end of section 3.1, right before section 3.2 add:

   A GS2 mechanism that has a non-OID-derived SASL mechanism name is
   said to have a "user friendly SASL mechanism name".

   OID-derived GS2 mechanism names may collide.  In the event of a
   collision, the first mechanism published will retain its OID-derived
   GS2 name and all others MUST NOT be used except via user friendly
   SASL mechanism names.

 - right after section 3.4 add:

3.5.  Assigning friendly SASL mechanism names

   Any GSS-API mechanism MAY have a user friendly, non-OID derived name
   assigned provided that: a) the names does not start with "GS2-", b)
   the name is registered for this purpose in the IANA SASL mechanism
   registry (see [RFC4422]), c) the assignment and registration happen
   before publication of the GSS-API mechanism specification, and before
   deployment of the mechanism.

 - in section 15

   /Subject:/s/mechanism/mechanism family/

 - in section 15

   /Note:/s/Note: /Note: No mechanism names may be registered with this
   prefix beyond the ones specified in this document; all other
   mechanism names beginning with the GS2- prefix are automatically
   generated mechanism names./

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 21 Aug 2009 22:08:24 +0100

>name could be registered with their OID-derived GS2 mech names.
Yes.

>to make sure that there are no mistakes in the name derivation.
Yes.

>name collisions...  We should!
>
Sure.

>And what can we say about that, short of

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 21 Aug 2009 22:16:12 +0100

>   deployment of the mechanism.
I am not sure about c).
Firstly, in order to register a SASL mechanism name, one need to have a 
spec defining it in full, which means that the GSS-API mechanism should 
already be described.

So maybe "the assignment and registration happen before *or 
simultaneously with the* publication of the GSS-API mechanism 
specification"?
And possibly add a note suggesting that requesting publication of a 
GSS-API mechanism is a good time for registering its human friendly SASL 
name?

And regarding "before deployment of the mechanism" - I am not sure we 
can really enforce it. And in many cases we want people try to deploy 
before the spec is final.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 21 Aug 2009 17:30:27 -0400

>    GS2 name and all others MUST NOT be used except via user friendly

Ick ick ick.  "first to publish" is not necessarily the right rule. 
Particularly, we want the right thing to happen if a well-known mechanism 
happens to collide with an obscure mechanism never used with SASL that 
happens to have been "published" first (but possibly not by the IETF).

If there's a collision, the one already in common use should win, and we 
should achieve that by addressing it explicitly if it ever comes up.

>    deployment of the mechanism.

(c) s/before/before or concurrent with/

==alexey on deployment, but we should maybe say it anyway.

Otherwise good.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Aug 2009 16:28:35 -0500

On Fri, Aug 21, 2009 at 10:16:12PM +0100, Alexey Melnikov wrote:
> >  assigned provided that: ...
> >                       ..., c) the assignment and registration happen

I assume that publication and SASL mechanism registration can happen in
one go, as usual.

> simultaneously with the* publication of the GSS-API mechanism 

IANA handles registrations before AUTH48, before final publication.
But, yes, sure.

Sure.

> before the spec is final.

True.  In such cases there'd be a flag day if a friendly name is
desired.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Aug 2009 16:39:51 -0500

> should achieve that by addressing it explicitly if it ever comes up.

Why not the one with the most users, or some other rule?

Maybe we don't need a rule.

"One, some or all affected mechanisms must get user friendly SASL
mechanism names assigned and MUST NOT be used except via user friendly
SASL mechanism names."

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 24 Aug 2009 15:49:37 +0200

> That would be fine as well.

I've made this more clear in my local copy:

http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt
http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--16.diff.html

I don't see any concrete proposal (i.e., a patch to the document) for
the other IANA issue that has support, so I'll wait with making any
other change until someone tells me to.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 Aug 2009 16:55:30 -0500

> http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--16.diff.html

Should we further clarify that no more GS2-* mechanism names will be
allowed to be registered without protocol action?

> other change until someone tells me to.

Agreed.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 25 Aug 2009 00:59:27 +0200

> allowed to be registered without protocol action?

I think requiring protocol action is pointless, as it may lead people to
allocate a new SASL mechanism name FOO and define it to be "use GSS-API
mechanism X under GS2 but call it FOO", which further complicate
mechanism negotiation.

Thinking about this, isn't that what SCRAM does?  SCRAM will be
available under both the SCRAM-* name and the OID-based GS2-* name
derived from the SCRAM OID.  Interestingly, there is only one OID
registered for SCRAM, presumably it is for SCRAM-SHA1?  Is there
something that prevents interop failures when one implementation use the
SCRAM-* names and another uses the GS2-* name?  I may have paged out
this piece of information, but I can't find it searching for SCRAM in
the GS2 document.

I'm not certain this is a problem, but I'm equally not certain that we
have thought about this naming aspect.

/Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 25 Aug 2009 12:42:45 -0400

--On Tuesday, August 25, 2009 12:59:27 AM +0200 Simon Josefsson 
<[email-masked]> wrote:

> Thinking about this, isn't that what SCRAM does?

No.  SCRAM registers a SASL friendly mechanism name, so that is the _only_ 
name that should be used for SCRAM in SASL.  Mechanisms that do this should 
not ever be referred to by OID-derived names.

> Interestingly, there is only one OID
> registered for SCRAM, presumably it is for SCRAM-SHA1?

It is for the only GSS-API mechanism that the document actually defines.

> Is there
> SCRAM-* names and another uses the GS2-* name?

No.  There is something that prevents correct implementations from using 
the GS2-* name.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Aug 2009 13:02:51 -0500

> No.  There is something that prevents correct implementations from using 

Specifically: GSS_Inquire_SASLname_for_mech().

A SASL/GS2 implementation must use GSS_Inquire_SASLname_for_mech() to
decide what SASL mech name a GSS-API mechanism shall have.

Of course, one could also have non-GSS-API based implementations of GS2
mechanisms that have friendly mech names, so there's no need to say that
an implementation of GS2 MUST use GSS_Inquire_SASLname_for_mech()