Subject: gs2 hashed oids

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Jan 2009 08:18:22 -0500

Hi.  Nico, thanks for conveying my concern.  I'm really sorry that I
was so busy, but my consulting practice and the nomcom have taken up
all my time lately.

Like Jeff Hutzelman I believe that it is important to be able to use a
GSS-API mechanism in an application that has never heard of that
mechanism.  We have significant evidence from SAP R3 this can be made
to work and evidence from other applications that it is valuable in
those contexts.  I don't understand why people think this would be a
bad idea, and would be happy to discuss.  If I'm not sufficiently
responsive here please IM or send me personal mail.

I believe the same arguments apply to SASL and I definitely want to
use SASL mechanisms with applications that have not been intended to
use the mechanisms I've using.  I've done this with many applications
that use the Cyrus framework at least on the client and it has been
incredibly valuable in several deployments.

I think it is critical we avoid situations where a SASL mechanism has
multiple names.

I think the OS distributor arguments that Jeff brings up are quite
valid.

My strong preference is to keep hashed oid names.

If we cannot get a consensus to do that, we should fall back to
something.  I think it would be a very bad idea to give scram and
Kerberos names but not have a plan for how we can do the same in the
future.  If there are sufficient pressures that we cannot get
consensus behind hashed oid names, then we should get something that
will work long-term, not adopt a solution for scram and kerberos only
to have the fight again later with deployed code blocking our options.

So, my preference is to get consensus that hashed oid names are
acceptable.  If that fails, we should design a mechanism that will
allow us to assign names to mechanisms but that will handle the OS
distribution problems.

I think it is also important that we support dynamic stackable
pseudo-mechanisms, which means we need to have some solution for
mechanisms that cannot be registered.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 06 Jan 2009 23:45:47 +0100

Sam Hartman <[email-masked]> writes:

> bad idea, and would be happy to discuss.

I have two relatively mild concerns.

The first concern is that the quality of non-standard GSS-API mechanisms
are sometimes low, so it may open up for security problems in SASL if
such mechanisms become available automatically.  I believe GS2 would
need a security consideration that explains this.

Another concern is that the hashed OID makes the mechanism names harder
to read for humans.  Ordinary users do chose between CRAM-MD5 and
DIGEST-MD5 in mail applications today.  I would fear a usability review
of a user interface that asks the users to chose between
GS2-DT4PIK22T6EPV2PY and GS2-QLJHGJLWNPLNQRNK.

There is a relatively easy solution to both these concerns: require that
a name is registered with IANA for every GSS-API mechanism that is
intended for use in SASL.  This is not too onerous IMHO, since the
registration approach is First-Come-First-Serve.  There are X-*
mechanism names for those who only wants to experiment.

However, this is merely my preference, and I don't feel strongly about
it.  I can live with hashed OIDs too, and will propose text for the
security considerations about this point.

> mechanisms that cannot be registered.

This seems like a separate issue, and potentially a problematic one: how
do we avoid interop problems if mechanism X is negotiated under
pseudo-mechanism Y or pseudo-mechanism Z or directly as X?  GS2 contains
text about GSS-API mechanisms that negotiates other mechanisms now, but
it seems the same concern also applies to pseudo-mechanisms.

/Simon

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 7 Jan 2009 12:06:36 +0100

Simon Josefsson writes:
> There is a relatively easy solution to both these concerns: require 
> that a name is registered with IANA for every GSS-API mechanism that 
> is intended for use in SASL. This is not too onerous IMHO, since the 

Side note: Would it be permissible at all to use GSS-API 
experimenta/non-standard mechanisms in SASL without an X- prefix?

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 7 Jan 2009 12:04:53 +0100

Sam Hartman:
>>  Like Jeff Hutzelman I believe that it is important to be able to use 
>>  a GSS-API mechanism in an application that has never heard of that 
>>  mechanism.

(Why is this important?)

>>  We have significant evidence from SAP R3 this can be made to work 
>>  and evidence from other applications that it is valuable in those 
>>  contexts.

(Do tell?)

>>  I don't understand why people think this would be a bad idea, and 
>>  would be happy to discuss.

1. Some application developers (quite a few in my experience — I was a 
library person in a past life) really don't want customers to use 
something they haven't tested, and do not want to have unknown plugins 
loaded at the customer or unknown mechanisms used there. Do you know 
the old saying "fly what you test and test what you fly"?

2. Some application developers (mostly the same set as above, but not 
quite) want the ability to reproduce what the customers are seeing. 
Using something unknown to the application is problematic. (There are 
also other problems, of course.)

Arnt

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 07 Jan 2009 12:19:11 +0100

> experimenta/non-standard mechanisms in SASL without an X- prefix?

The registration model described in RFC 4422 -- first come first serve,
with no technical review -- appears to permit almost any mechanism in
SASL, not just standardized mechanisms.  I don't see a difference
between a GSS-API mechanism and a SASL mechanism in this context.

/Simon

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 7 Jan 2009 12:45:46 +0100

Simon Josefsson writes:
> The registration model described in RFC 4422 -- first come first 
> serve, with no technical review -- appears to permit almost any 
> mechanism in SASL, not just standardized mechanisms. I don't see a 
> difference between a GSS-API mechanism and a SASL mechanism in this 
> context.

OK

Arnt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 07 Jan 2009 18:16:25 -0500

--On Tuesday, January 06, 2009 11:45:47 PM +0100 Simon Josefsson 
<[email-masked]> wrote:

> such mechanisms become available automatically.

This is a classic conceit.  Our concern that a particular non-standard 
mechanism might be insecure and make "our protocol" insecure is really 
completely irrelevant to the operator who uses that mechanism as his 
enterprise authentication mechanism.  Choice of mechanisms is a policy 
decision, and our role as protocol designers and implementors is not to set 
policy(*).

> I believe GS2 would

I certainly think we need to say that the security of GS2 depends on the 
security properties of the particular underlying GSS-API mechanism used, 
and in what ways.  I don't think we need to or should say "WARNING: don't 
use non-standard mechanisms, because they are low quality" or similar FUD.

> GS2-DT4PIK22T6EPV2PY and GS2-QLJHGJLWNPLNQRNK.

I would, too, if I had designed that user interface.  But given the choice 
between an implementation which showed a user-friendly mechanism name like 
"GSS-API with Kerberos" or "GSS-API with public keys" for mechanisms it 
knows about  and a hashed named for others, and one which showed names like 
"GS2-KERBEROS" or "GS2-SPKM" for mechanisms it knows about and doesn't let 
me use other mechanisms at all, I'd pick the former every time.

> registration approach is First-Come-First-Serve.

It is, because random enterprises don't know or care about the IETF or IANA 
or want to have to register their private mechanisms with someone before 
they can use them.  It's also unnecessary to impose such a requirement.

\>> I think it is also important that we support dynamic stackable
> it seems the same concern also applies to pseudo-mechanisms.

Stackable pseudo-mechanisms are not the same as multi-level negotiation.
Multi-level negotiation is a problem because you end up having to agree on 
one level before knowing if there's a mutually-acceptable mechanism at the 
next.  But stackable mechanisms don't work that way; every possible stack 
has an OID, composed from the OID's of the stacked mechanisms (see section 
4.1 of draft-ietf-kitten-stackable-pseudo-mechs-02.txt).  Then the entire 
_stack_ is negotiated at once, as if it were a single mechanism.  This 
leads to an explosion of possible mechanism OID's, where it's not entirely 
possible to predict what they all are, but is entirely unreasonable to 
expect every combination to be named and registered.

-- Jeff

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 8 Jan 2009 14:39:34 +0100

Jeffrey Hutzelman writes:
> Multi-level negotiation is a problem because you end up having to 
> agree on one level before knowing if there's a mutually-acceptable 
> mechanism at the next.  But stackable mechanisms don't work that way; 
> every possible stack has an OID, composed from the OID's of the 
> stacked mechanisms (see section 4.1 of 
> draft-ietf-kitten-stackable-pseudo-mechs-02.txt).  Then the entire 
> _stack_ is negotiated at once, as if it were a single mechanism.  
> This leads to an explosion of possible mechanism OID's, where it's 
> not entirely possible to predict what they all are, but is entirely 
> unreasonable to expect every combination to be named and registered.

It sounds as though a server asked to use GS2-GQGFDSAGDSAF would have to 
recurse through all possible mechanism stack, encoding its OID as 
described in the kitten draft, hashing the resulting OID and comparing 
it against the desired name. Have I understood it correctly? (If not, 
then maybe it's nonobvious and should be explained in the GS2 
document.) If I have, then is that practical to recurse through the 
tree to find the mechanism?

Arnt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 08 Jan 2009 09:43:30 -0500

--On Thursday, January 08, 2009 02:39:34 PM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

> recurse through all possible mechanism stack

Yes, but the SASL and GS2 implementation need not worry about this; all 
they should need to do is call GSS_Indicate_mechs(), whose result will 
include any composite mechanisms which are part of the default set.  Or, it 
may use GSS_Indicate_mechs_by_mech_attrs() to list mechanisms (including 
composite mechanisms) which have the attributes GS2 requires.

-- Jeff

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 22 Jan 2009 22:46:36 -0800

The WG previously made a design choice to use "hashed" GS2- mechanism  
names instead of individually "registered" SASL names.  This design  
choice was reviewed as part of the previous WG Last Call(s) and  
believed to be supported by WG consensus.

In reviewing the recent discussions, I find that while there is a camp  
who prefers "registered" SASL names, most in this came can live with  
"hashed" names.  However, those in the "hashed" camp cannot live with  
"registered" SASL names because with "registered" SASL names GSS-API  
mechanisms could not automatically be SASL mechanisms within an  
implementation.  It seems the latter camp has a stronger technical  
argument.

Hence, I find that there is insufficient consensus to change to  
"registered" SASL names.

-- Kurt, as SASL co-chair

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 23 Jan 2009 13:02:04 +0100

> I have review this thread and the history.
>

Thanks for making this call.  Once the SCRAM wire syntax question is
decided, I can resume work on GS2 and will then keep the current hash
approach to mech names.

/Simon