Re: Registering AuthN Identifiers with IANA

[Jeff Hodges <jhodges@oblix.com>]

Hal Lockhart wrote:
> 
> > JeffH noted that there IS an existing registry of what are effectively
> > "authentication types". This is the IANA-based registry of
> > SASL mechanisms
> > located here..
> >
> >   http://www.iana.org/assignments/sasl-mechanisms
> 
> [...]
> the SASL registry, as it stands, is not suitable for our needs [...] 
> we will have to do more than wave at the SASL list.

Thanks for the investigation -- I nominally agree with the conclusion. 

I pointed at sasl-mechanisms for two reasons..

1. in an admittedly off-the-cuff hope that perhaps we could "just use it",
rather than having to invent something similar. 

2. as an extant, real-world, example of what such a registry, and it's listed
identifiers, looks like. 

My apologies that these motivations weren't explicitly made clear in the excerpt
cited above. 


> 1. In order to use this registry, a SASL profile must be defined for each
> [mechanism] to be registered. 

Not exactly. A careful read of section 6 of rfc2222 reveals that one perhaps can
register SASL mechanism names without a coresponding document specifying a
profile of SASL in the context of some other protocol (e.g. BEEP, LDAP, ICAP,
etc). It appears that NTLM, NMAS_LOGIN, and NMAS_AUTHEN are examples of such. 

However, the semantic connotations of such a registration are that the
registered 
mechanism is being used in conjunction with SASL-based implementations
somewhere, plus there's no definite guarantee that IANA will indeed add
essentially
any requested mechanism names (aka AuthnType names) to the sasl-mechanisms
registry. 


> 2. The list leaves a lot to be desired. HTTP basic auth is not defined.
> (PLAIN is conceptually similar, but not the same.) Kerberos 5 is missing
> along with its cousins DCE and MS-Kerberos. In fact, there is only one
> mechanism defined (NTLM) for the 4 or 5 Microsoft AuthN protocols in common
> use. There is no kind of PKI, nor biometrics.

Perhaps another way to put it is that we see a need to define a superset of the
set listed in sasl-mechanisms.


> All we want to do is a register some identifiers.

Here's a suggestion for how to proceed in the near term..

A. use the syntax of SASL mechanism identifiers as the syntax of SAML AuthnType; 
   namely: 

     strings, from 1 to 20 characters in length, consisting of upper-case 
     letters, digits, hyphens, and/or underscores.

B. create a simple list of AuthnTypes, materialized in a text file stored
   in some well-known (altho likely temporary-in-the-longer-term) location (e.g. 
   http://www.oasis-open.org/committees/security-services/docs/). Initialize the
   list by subsumming the list of identifiers from sasl-mechanisms. Add to the
list
   those identifiers we feel we need in the near term. E.g..

     HTTP-BASIC
     HTTP-DIGEST
     KERBEROS-V5
     KERBEROS-DCE
     KERBEROS-MS
     PKI-X.509
     PKI-PGP
     ..etc.. 

   ..see a prototype "SAML-AuthnTypes.txt" below.



..and in the longer term (tho this can and likely should actually be occuring in
parallel to the above) ..


C. Write an Internet-Draft (I-D) defining a "SAML Authentication Type
Identifiers Registry" and specifying that IANA manage it. Incorporate the list
from (B) into the new list. Specify in the I-D how the list is to be maintained
-- e.g. how updates to it are submitted & vetted (e.g.
http://www.ietf.org/rfc/rfc2434.txt details the stuff that needs to be
considered here). Work in the IETF context to refine the I-D and have it issued
as an RFC (as Informational?) and thus have IANA create & maintain the registry.
Then migrate usage of the list created in (B) to the list created in (C). 


It's worthwhile to note that if we (SSTC), and OASIS overall, don't make use of
IANA for such purposes, we'll have to spend time re-inventing arguably quite
similar processes and documents (e.g. rfc2434). 


JeffH
-----
> (As a final note, I noticed that the URL given in RFC2222 is no longer
> valid. The one given above is correct.)

Sigh. The URL in rfc2222 is..

  ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-mechanisms/
                                                             ^
                                                             |
Note the trailing slash -------------------------------------+

Some IANA person likely made a mistake when they migrated the IANA repository to
being http-based. The above URL *without the trailing slash* resolves to a file
that indeed specifies the new, currently correct http-based URL for
sasl-mechanisms. I've pointed this out to the IANA folk, fwiw. 

-----
SAML-AuthnTypes.txt:

SAML Authentication Type (AuthnType) Identifiers
------------------------------------------------

<introductory text here>

SAML AuthnTypes are identified by strings, from 1 to 20 characters in
length, consisting of upper-case letters, digits, hyphens, and/or
underscores. 

NOTE: This list of AuthnTypes is a superset of those listed in..

  http://www.iana.org/assignments/sasl-mechanisms

At the time of last updating of this file, the sasl-mechanisms list consisted of
these identifiers: 

  KERBEROS_V4, GSSAPI, SKEY (OBSOLETE), EXTERNAL, CRAM-MD5, ANONYMOUS, OTP,
  GSS-SPNEGO, PLAIN, SECURID, NTLM, NMAS_LOGIN, NMAS_AUTHEN, DIGEST-MD5


  SAML
AuthnTypes      OWNER                                          REFERENCE
----------      -----                                          ---------

[sasl-mechanisms]						[sasl-mechanisms]
HTTP-BASIC							[SAML SPEC]
HTTP-DIGEST							[SAML SPEC]
KERBEROS-V5							[SAML SPEC]
KERBEROS-DCE							[SAML SPEC]
KERBEROS-MS							[SAML SPEC]
PKI-X.509							[SAML SPEC]
PKI-PGP								[SAML SPEC]


References
----------

[SAML SPEC]  <URL pointing to SAML spec>

[sasl-mechanisms]  http://www.iana.org/assignments/sasl-mechanisms


(last updated 13-Jul-2001) 




-----
end