Re: Authentication Methods for LDAP - last call (mandatory CRAM-MD5)

[Mark Wahl <M.Wahl@INNOSOFT.COM>]

>  Client and server mplementations MUST have provisions for end-user addition
>  of support for at least these security mechanisms: <list of SASL mechs here>.

I don't think this statement is suitable for this document.  The majority 
of IETF specifications describe the exchange of bits on the wire.  So long as 
two implementations can generate/parse the same bits, then they interoperate.
Currently the SASL API documents are an internet-draft for the client side,
and require much more spec'ing (IMHO) on the server side.  Requiring ALL LDAPv3
implementations, including an embedded LDAP client in a nonprogrammable device
to support pluggable modules with an API that is still being developed does
not seem successful.   

> [E.g. the fashion in which Netscape's client SDKs and Directory servers are 
>  extensible through plug-ins.]

As our ours and other clients and servers, but with a different API (and 
different language bindings?) since there is no one standard language.

I would suggest that IF and WHEN suitable APIs for SASL become Standards Track
(or at least informational), then LDAP implementations that support the 
reconfiguration of SASL mechanisms SHOULD do so with these APIs.

> So, I think the CRAM-MD5 thing is fine (for now), but I wonder if the doc 
> goes far enough in that it doesn't profile Kerberos v4 or GSSAPI (Kerberos 
> v5 et al)

Could you point me at any examples or papers describing the use of Kerberos 
SASL mechanisms on the wide-area Internet, especially where the client and 
server are located in different organizations?  There is specification work
going in PKIX and elsewhere on how to handle cross-certification for use by
Start TLS, but I am not familar with that kind of activity for Kerberos.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.