Subject: RE: I-D ACTION:draft-ietf-cat-sasl-gssapi-05.txt

From: "John Brezak" <[email-masked]>
Date: Mon, 11 Jun 2001 09:20:10 -0700

What about GSS mechanisms with OID that were typo'ed in the
implementation? The mechtype code knows how to deal with it, but the OID
based registration mechanism will not deal with this very well.

I'd prefer to use the IANA registered names as Doug suggests instead of
an algorithmic OID based encoding scheme.

If it is to be an OID, it should be a straight forward encoding - either
in printable dotted notation, or asn.1 encoded. You could get around the
byte limit for names by adding an extension field after the
authorization ID carrying the full (encoded) OID.

-----Original Message-----
From: John Gardiner Myers [mailto:[email-masked]] 
Sent: Saturday, June 09, 2001 1:24 PM
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-cat-sasl-gssapi-05.txt

"Douglas E. Engert" wrote:
> I am assuming that the above realy says you do not need to register 
> these names with IANA.

Correct.

> Then says:
>    SASL mechanism names starting with "GSS-" are reserved for SASL
>    mechanisms which conform to this document.

The intent is to carve out a portion of the SASL mechanism namespace so
that GSSAPI SASL mechanism name registration is done through the OID
registration process instead of the IANA registration process.  Once a
GSSAPI mechanism has been registered through GSSAPI's process (assigning
an OID), no additional registration work need be necessary to get a
legal SASL mechanism name.  An implementation, knowing nothing about a
GSSAPI mechanism other than its OID, can determine its SASL mechanism
name.

> They would imply that I could still have a GSS SASL name of 
> GSSMECH-MYOWN and register it with IANA.

You can register any SASL mechanism name you like, as long as the name
is not already taken and as long as the name is not in a reserved
portion of the namespace (such as the portion of the namespace starting
with "GSS-").  Such a mechanism will not conform to the SASL-GSSAPI
specification and will not interoperate with implementations conforming
to the SASL-GSSAPI specification.

> Is there any restriction on having two SASL names for the same GSS 
> mechanism?

No, just as there is no restricition on having two OIDs for the same GSS
mechanism.  Having multiple names will, however, lead to
noninteroprability.

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list server.
If you wish to unsubscribe from this mailing list, send the message body
of "unsubscribe ietf-cat-wg" to [email-masked]
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 18 Jun 2001 14:34:07 -0700

> based registration mechanism will not deal with this very well.

I'm sorry, I don't understand what you're describing.  Could you give an
example?
 
> an algorithmic OID based encoding scheme.

Which IANA registered names?  As far as I was aware, there are is no
IANA registry of GSS mechanisms and the only names that a caller to the
GSS API can get for available mechanisms are the OIDs.
 
> authorization ID carrying the full (encoded) OID.

The list of mechanisms available on the server has to be communicated
before the client calls GSS_Init_sec_context.  The part of the
negotiation where the authorization ID is sent is far too late.