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

From: [email-masked]
Date: Fri, 01 Jun 2001 06:47:10 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Authentication Technology Working Group of the IETF.

	Title		: SASL GSSAPI mechanisms
	Author(s)	: J. Myers
	Filename	: draft-ietf-cat-sasl-gssapi-05.txt
	Pages		: 14
	Date		: 31-May-01
	
The Simple Authentication and Security Layer [SASL] is a method for
adding authentication support to connection-based protocols.  This
document describes the method for using the Generic Security Service
Application Program Interface [GSSAPI] in the Simple Authentication
and Security Layer [SASL].
This document amends section 7.2 of RFC 2222 [SASL], the definition
of the 'GSSAPI' SASL mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-cat-sasl-gssapi-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-cat-sasl-gssapi-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-cat-sasl-gssapi-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Martin Rex <[email-masked]>
Date: Tue, 5 Jun 2001 15:00:30 +0200 (METDST)

This I-D missed April 1st by over two months!

What nonsense is this with an MD5 hash over an DER-encoded OID to
indicate the gssapi mechanism?  An ASN.1 OID is meant as a unique
identifier and it is supposed to be short.  It's plain stupid to
use a truncated hash of an ASN.1 OID instead of the OID itself.

Quoting from draft-ietf-cat-sasl-gssapi-05.txt:

   For backwards compatibility with existing implementations of Kerberos
   V5 and SPNEGO under SASL, the SASL mechanism name for the Kerberos V5
   GSSAPI mechanism [GSSAPI-KERBEROS] is "GSSAPI" and the SASL mechanism
   for the SPNEGO GSSAPI mechanism [SPNEGO] is "GSS-SPNEGO".  The SASL
   mechanism name for any other GSSAPI mechanism is the concatenation of
   "GSS-" and the Base32 encoding of the first ten bytes of the MD5 hash
   [MD5] of the ASN.1 DER encoding [ASN1] of the GSSAPI mechanism's OID.
   Base32 encoding is described later in this document.  The Base32
   rules on padding characters and characters outside of the base32
   alphabet are not relevant to this use of Base32.

 ...

   The OID for the SPKM-1 mechanism [SPKM] is 1.3.6.1.5.5.1.  The ASN.1
   DER encoding of this OID is 06 06 2b 06 01 05 05 01.  The MD5 hash of
   the ASN.1 DER encoding is 57 ee 81 82 4e ac 4d b0 e6 50 9f 60 1f 46
   8a 30.  The Base32 encoding of the first ten bytes of this is
   "K7XIDASOVRG3BZSQ".  Thus the SASL mechanism name for the SPKM-1
   GSSAPI mechanism is "GSS-K7XIDASOVRG3BZSQ".

The proposed algorithm to come up with a unique identifier is
bloated and complex (requires MD5 and base32-encoding, neither
of which is part of ANSI-C).

Just use the printable HEX-encoding of the DER-encoded OID element,
i.e. for SPKM1:   GSS-2B0601050501
Hex-encoding is trivial (even sprintf(3) can be used, and the
DER-encoded OID elements are directly available from gss_indicate_mechs().

When converted in printables, a leading length field should be omitted
(it is implicit from the printable length).  Because of the structure
of the OID space, the hex encoding ususally start with "2A" or "2B".

-Martin
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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: Derek Atkins <[email-masked]>
Date: 05 Jun 2001 11:15:09 -0400

Martin,

Without reading the rest of the sasl draft to understand the
requirements, I can think of a couple of reasons why they might want
to do this.

One example is if there is a length limit on the size of the SASL
mechanism name (20 characters).  In that case, you may not be able to
use the raw OID, because the 'relevant' bits may fall off the end of
the SASL mech name if you just use HEX encoding.  By using MD5 (or any
other hash) you have a much better spreading of the bits.

To put this into perspective, let's say you had two OIDs that looked like
1.3.6.1.5.5.1.1 and 1.3.6.1.5.5.1.2.  Let's presume (please don't yell
at me if this is wrong -- this is only an example), that the DER encoding
of these two OIDs are
	06 07 2b 06 01 05 05 01 01
 and	06 07 2b 06 01 05 05 01 02

If there truly was a length-limit on the sasl name, then using the raw
hex on these encodings wouldn't work, because the difference between
the two would 'fall off the end' of the SASL mech string.

So, without knowing the requirements for doing things this way, I
cannot condemn using MD5 and base32.  Kerberos uses MD5, and 3DES, and
a lot of other functions which "aren't part of ANSI-C", so how/why is
that any different?  Besides, you could even use the MD5 code from
your Kerberos implementation to implement this.  And implementing
base32 is REALLY EASY in ANSI-C.  It's not like ASN.1; with base32 you
at least know your output length exactly based on your input length.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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: Martin Rex <[email-masked]>
Date: Tue, 5 Jun 2001 18:14:23 +0200 (METDST)

>  and	06 07 2b 06 01 05 05 01 02

Btw. I suggested not to include the OID-tag (06) and the length field (07).

The reason why using a hash is bad is that you can't reverse it.
The OID in GSS-API is meant to identify the GSS-API mechanism.
If the peer is presented only with the truncated hash, it has no
possibility to figure out what mechanism is meant if there is no
match with the mechanism known at the moment.  The OIDs give you
at least a starting point to look for the mechanism (spec or vendor).

> the two would 'fall off the end' of the SASL mech string.

Using the shorter prefix "G-" plus the hex encoded octets of the
OID elements should give enough space for all *reasonable* GSS-API
mechanism OIDs.

If they really have a size problem, maybe they should be using
base64 instead of hex (or base32) since it generates smaller
output and is more commonly used -- or is there an even
worse restriction on the length *and* value?

> at least know your output length exactly based on your input length.

MD5 has been published as sample C-Code in RFC 1321, the Base32 sample
C-Code is listed in the appendix of this draft.

Getting the code is not the problem I was referring to.
It is the excessive code and complexity that I'm objecting to.

---

From: Martin Rex <[email-masked]>
Date: Tue, 5 Jun 2001 18:42:47 +0200 (METDST)

> other hash) you have a much better spreading of the bits.

OUCH!  You're right, I didn't know about that size limit for
SASL mechanisms.  It's plain stupid to define such a seriously
limited namespace in the first place.  The SASL spec (rfc2222)
apparently didn't receive any serious peer review before it
was put onto standards track.

Quoting from rfc2222.txt:
   The command has a required argument identifying a SASL mechanism.^M
   SASL mechanisms are named by strings, from 1 to 20 characters in^M
   length, consisting of upper-case letters, digits, hyphens, and/or^M
   underscores.  SASL mechanism names must be registered with the IANA.^M
   Procedures for registering new SASL mechanisms are given in the^M
   section "Registration procedures"^M

Limiting the available namespace in size and valid characters
in such a fashion is about as reasonalbe as claiming that
640KByte of RAM is enough for applications ...

-Martin

---

From: Derek Atkins <[email-masked]>
Date: 05 Jun 2001 12:58:48 -0400

> at least a starting point to look for the mechanism (spec or vendor).

Yes, this is a problem.  I think there is a trade-off between the
assurance of unique mech-ids (for long OIDs) and the convenience of
being able to convert a SASL-mech into an unknown GSSAPI OID.  I think
they decided they'd rather have guaranteed uniqueness for all OIDs.

> OID elements should give enough space for all *reasonable* GSS-API

Who are we to decide what is a "reasonable" OID length?

Also, as you noticed, there _IS_ a constraint on both length and
value.

Sigh.

-derek

---

From: Martin Rex <[email-masked]>
Date: Tue, 5 Jun 2001 20:00:25 +0200 (METDST)

> Who are we to decide what is a "reasonable" OID length?

When I wrote that I didn't know about the 20 char limit,
which when using hex encoding and "G-" prefix would result in
at most 9-byte OIDs -- which is really too tight.
My own GSS-API mechanism OID (from the IANA-managed SNMP-enterprise arc)
is 10 bytes.

With reasonable I meant less than 15 bytes for the elements part.
This should be achievable with OIDs from the SNMP-enterprise arc.
Officially assigned OID arcs from any of the ISO-member bodies
result in even shorter OIDs, however the ISO-folks are trying
to "lease out" OID arcs for $$$$/year.

It's a MPIA when protocol specs are written with just enough space
for the first version and no air for backward compatible future
extensions.  Maybe the IESG can catch such flaws in future specs
(especially when the document is not the product of a working group).

-Martin

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 05 Jun 2001 13:27:25 -0500

>    section "Registration procedures"^M

Since the RFC 2222 says SASL mechanisms MUST be registered, why do they 
have to be base32 names in the first place? If the intent of the draft
was to provide well known unique names to both sides, this is already
implicitly required by registering with IANA.

The draft says:

   Each and every GSSAPI mechanism used within SASL is implicitly
   registered by this specification.

I am assuming that the above realy says you do not need to register 
these names with IANA. 

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

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

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

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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: Sat, 09 Jun 2001 13:24:02 -0700

> I am assuming that the above realy says you do not need to register

Correct.

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

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