Re: gs2 hashed oids

[Jeffrey Hutzelman <[e-mail]>]

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

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

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
> need a security consideration that explains this.

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.


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

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.


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

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
>> pseudo-mechanisms, which means we need to have some solution for
>> 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.

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