Subject: Re: ldap scheme comment

From: Jonathan Wood <[email-masked]>
Date: Tue, 5 Jan 1999 12:18:09 -0800 (PST)

Leif,

Thanks for your comment.

In order to agree on a particular authentication mechanism, a client and
server might need to go through a number of iterations and levels of
negotiation. The idea with the security attribute was to allow this
process to be optimized by enabling the client to discover in one shot
a server which satisfies its security mechanism requirements. Initially,
we wanted to enumerate just the most common mechanisms.

Your question prompted further consideration of the matter, and it
looks like we should make the template more robust and closer to the
LDAP specs in this regard. I suggest an approach which expands out into
separate attributes different levels of negotiation which may be possible.
The following template excerpt shows how this would work:

security=string M
  # Security mechanisms supported by this server. Permitted values
  # are drawn from RFC 2251 (LDAP v3), and
  # draft-ietf-ldapext-ldapv3-tls-04.txt (TLS extension).
  # If SASL is supported, clients may further differentiate servers
  # with the sasl-mechs attribute.
none,simple,tls,sasl

sasl-mechs=string M
  # SASL mechanisms supported by this server. If the GSSAPI or GSS-SPNEGO
  # mechanisms are supported, clients may further differentiate servers
  # with the gss-mechs attribute. SASL mechanisms are registered with
  # IANA; legal values of this attribute are the mechanism keywords
  # registered with IANA. SASL is defined in RFC 2222.

gss-mechs=string M
  # GSSAPI mechanisms supported by this server. The mechanisms are
  # named by their object identifiers (OIDs). GSSAPI is defined
  # in RFC 2078, and GSS-SPNEGO is defined in RFC 2478.

So if a client has been configured to use the KerberosV5 GSSAPI mechanism,
it would use this SLP query:

  (&(security=sasl)(sasl-mechs=GSSAPI)(gss=mechs=1.3.5.1.5.2))

The other SASL mechanism with potentially multiple sub-mechanisms is
EXTERNAL, but rather than make this an attribute as well, it seems
best to let implementations handle this independently.

Thoughts? Comments?

Jon

>X-Address: Department of Mathematics, Stockholm University  S-106 91  Stockholm 
SWEDEN
>X-Phone: int+46 8 162000
>X-Fax: int+46 8 6126717
>X-Url: http://www.matematik.su.se
>To: [email-masked]
>Subject: ldap scheme comment
>Mime-Version: 1.0
>Date: Sun, 27 Dec 1998 15:47:09 +0100
>From: Leif Johansson <[email-masked]>
>
>
>Forgive me if this is an FAQ/stupid question. I am not on the list
>but the following caught my eye in the recent ldap scheme draft:
>Why is there a separate authentication method for kerberos5 when 
>there is no kerberos5 authentication method specified in rfc2251? 
>The BindRequest looks like this:
>
>	BindRequest ::= [APPLICATION 0] SEQUENCE {
>                version                 INTEGER (1 .. 127),
>                name                    LDAPDN,
>                authentication          AuthenticationChoice }
>
>        AuthenticationChoice ::= CHOICE {
>                simple                  [0] OCTET STRING,
>                                         -- 1 and 2 reserved
>                sasl                    [3] SaslCredentials }
>
>        SaslCredentials ::= SEQUENCE {
>                mechanism               LDAPString,
>                credentials             OCTET STRING OPTIONAL } 
>
>Kerberos5 is done as a GSSAPI mechanism as (part of) a SASL bind.
>The only thing which is not obtainable from protocol calls is
>what GSSAPI mechanisms are supported. It might be apropriate to
>specify those (a set of OIDS then) in the scheme, but not (imho)
>kerberos5 as such.
>
>
>	Best Regards
>	Leif Johansson
>
>Leif Johansson				Phone: +46 8 164541		
>Department of Mathematics		Fax  : +46 8 6126717		
>Stockholm University 			email: [email-masked] 	
>
>    <This space is left blank for quotational and disclamatory purposes.>
>