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

[Jonathan Trostle <jtrostle@cisco.com>]

> X-SMAP-Received-From: outside
> Resent-Date: Mon, 3 Aug 1998 15:52:10 -0700 (PDT)
> Date: Mon, 03 Aug 1998 17:46:37 -0500
> From: Mark Wahl <M.Wahl@INNOSOFT.COM>
> Subject: Re: Authentication Methods for LDAP - last call (mandatory CRAM-MD5)
> To: Jeff.Hodges@stanford.edu
> Cc: ietf-ldapext@netscape.com
> MIME-version: 1.0
> Resent-Message-ID: <"jxJS7.0.303.MyZnr"@glacier>
> Resent-From: ietf-ldapext@netscape.com
> X-Mailing-List: <ietf-ldapext@netscape.com> archive/latest/591
> X-Loop: ietf-ldapext@netscape.com
> Resent-Sender: ietf-ldapext-request@netscape.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.

Public key certificates in Kerberos are specified in 
draft-ietf-cat-kerberos-pk-init-06.txt.

Jonathan