Subject: createSaslClient by the Java LDAP API

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 04 Apr 2001 17:45:04 -0700

The Java LDAP API appears to be responsible for
calling createSaslClient() method of the Sasl class
which requires as a parameter:

      authorizationID The possibly null protocol-dependent 
                     identification to be used for authorization, e.g. 
                     user name or distinguished name. When the SASL 
                     authentication completes successfully, the entity 
                     named by authorizationId is granted access. If 
                     null, access is granted to a protocol-dependent 
                     default (for example, in LDAP this is the DN in 
                     the bind request)

How does an application using the Java LDAP API
specify the authorizationID it desires?

Also, it appears the SASL API property:
	Sasl.POLICY_NOPLAINTEXT

defaults to false.  There should be LDAP API requirement that
if the application provided properties do not include a
an explicit Sasl.POLICY_NOPLAINTEXT setting, the LDAP API
MUST set this property to true.   Also,
QOP ("javax.security.sasl.qop") defaults to 'auth'
and not 'auth-conf'.  And STRENGTH ("javax.security.sasl.strength")
defaults to "high,medium,low".  These and other properties
should be carefully examined to be sure the LDAP API defaults
them consistently with the LDAP SASL "profile" (RFC2251/2829).

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 04 Apr 2001 18:35:15 -0700

>                     default (for example, in LDAP this is the DN in 

A little off-topic for this list, but I note parts of this
definition seem inconsistent with RFC 2222 and RFC 2829.  I
offer this alternative wording which I believe is more
consistent with RFC 2222 and RFC 2829.
   authorizationID
        The possible null identity which the client is
        requesting to have the authorization of.  If null
        or empty, the server (not the API) derives an
        authorization identity from the mechanism authentication
        identity used.  The form of the authorizationID
        is protocol dependent and defined in the protocol's
        SASL profile.  For example, for LDAP (RFC2829) the
        authorizationID may be empty (null) or of the form
        "u:userid" where userid is some arbitrary UTF-8
        string or "dn:distinguishedName" where distinguishedName
        is a string representation (RFC 2253) of a LDAP DN.

I would suggest further discussion of the SASL API be directed
to the [email-masked] mailing list or other suitable forum.

---

From: Rob Weltman <[email-masked]>
Date: Wed, 04 Apr 2001 20:11:14 -0700

> specify the authorizationID it desires?

  As the DN parameter of the bind() operation.

  The Java LDAP API draft predates RFC 2829 by quite a bit. Perhaps it should change the definition of the parameter to allow a username as alternative to DN.

> them consistently with the LDAP SASL "profile" (RFC2251/2829).

  OK

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 04 Apr 2001 20:36:46 -0700

>  The Java LDAP API draft predates RFC 2829 by quite a bit. Perhaps it should change the definition of the parameter to allow a username as alternative to DN.

I would suggest the addition of a separate argument to the
SASL bind() methods:
        authzId         If not null nor empty, an LDAP authzId (RFC2829).
                        This parameter SHOULD be passed to the SASL layer
                        unmodified.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 04 Apr 2001 20:56:47 -0700

>them consistently with the LDAP SASL "profile" (RFC2251/2829).

I note that this defaulting may be dependent on what level
of TLS protections that are in place.  For example, if TLS
was enabled with a reasonable cipher, then plain text (or
equivalent) mechanisms could be enabled.  If TLS was
established with mutual client/server authentication,
then EXTERNAL could be allowed.

Kurt

---

From: Rob Weltman <[email-masked]>
Date: Thu, 05 Apr 2001 08:06:47 -0700

>                         This parameter SHOULD be passed to the SASL layer

  That would cause ambiguity if both a DN and an authzId were supplied.

Rob

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 05 Apr 2001 08:17:28 -0700

>  That would cause ambiguity if both a DN and an authzId were supplied.

The dn parameter is the bind name, the authzId parameter is the
SASL authorization identity.   That's a one-to-one API parameter
to protocol element relationship, I see no ambiguity.

Kurt

---

From: Rob Weltman <[email-masked]>
Date: Thu, 05 Apr 2001 21:56:10 -0700

> to protocol element relationship, I see no ambiguity.

  OK, but if authzId IS null or empty, then the DN should be used as the SASL authorization identity? Or should the server derive the authorization identity from the authentication identity?

  For my own edification, not having experience with a directory that handles authzIds other than DNs:

  What are the respective influences of the authzId and the bind DN (which is not the authentication DN) on the authority of requests issued after successful authentication? Is it possible that one of the two could imply rights which would not be available to the other? Or does the bind DN no longer affect authorization if there is a separate authzId?

Rob

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 06 Apr 2001 00:56:13 -0700

>  OK, but if authzId IS null or empty, then the DN should be used as the SASL authorization identity?  Or should the server derive the authorization identity from the authentication identity?

no, yes.

A client should not assert an authorization identity unless it
wishes to assume an authorization identity different from that
implied by the authentication identity.

Also, I note that a client should not assume any authorization
identity it might derive from its authentication identity will
be treated by the server as being equivalent to the authorization
identity it would derived from the authentication identity.

>  What are the respective influences of the authzId and the bind DN (which is not the authentication DN) on the authority of requests issued after successful authentication?

In general, server implementations ignore the bind name when
provided in a SASL bind request.  However, as the language of
RFC 2251, 4.2 implies (in an odd way), the server might make
use of the bind name when the SASL credentials do not contain
an LDAP DN.

First, I'll elaborate on possible uses in absence of a
client asserted authorization identity.  The server could
just log the bind name.  Or the server could use it to
restrict the realms advertised (there was a thread
discussing this use some years ago).  Or, (as I think the
authors of 2251 had in mind), the server can use the bind
name to locate an entry associated with authentication
identity.  This entry might contain the mechanism specific
secret and/or other information the server needs for the
mechanism.  Upon completion of the authentication, the
DN of this entry (or other information in the entry) might
be used to establish the authorization identity associated
with the session.

Second, in the present of a client asserted authorization
identity, the server may (in addition to the above) rely on
this entry to support evaluation of the proxy authorization
policy.

>Is it possible that one of the two could imply rights which would not be available to the other? Or does the bind DN no longer affect authorization if there is a separate authzId?

It is possible that the server might not be able to establish
the authentication and/or authorization association without a
bind name.  However, the rights granted to the client are
those associated with the authorization identity regardless
of whether it was asserted by the client or derived from the
authentication identity.  The bind name, at most, would be
providing an association between the authentication identity
and an entry used to support the authentication/authorization
process.

Lastly, I note there are a number of security considerations
(namely the bind name is not protected by the mechanism) and
other practical matters (users should need to know their DNs)
which limit cases where a bind name should be provided and
used.  I generally recommend that clients not specify a bind
name and that servers ignore the bind name.

However, I do support the SASL bind() methods having both dn
and authzid parameters as I believe the API should be complete
(support all exchanges allowed by the protocol).

Kurt

---

From: Rob Weltman <[email-masked]>
Date: Fri, 06 Apr 2001 07:33:44 -0700

"Kurt D. Zeilenga" wrote:
> 
> I generally recommend that clients not specify a bind

  So now it is clear how to implement the Java LDAP SASL binding, but it is extremely unclear what the server behavior will be if both a DN and an authzid are provided. Certainly not what the authors of RFCs 2222 and 2831 had in mind for SASL and for DIGEST-MD5.

  Isn't that a big hole? If I was writing an LDAP client application, I would want to know if the DN I provided on a bind request contributes to the rights of the connection, and I would want the behavior to be the same for all LDAPv3 servers. There are major access control implications of indeterminate authorization.

Rob

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 06 Apr 2001 09:48:59 -0700

At 07:33 AM 4/6/01 -0700, Rob Weltman wrote:
>  So now it is clear how to implement the Java LDAP SASL binding, but it is extremely unclear what the server behavior will be if both a DN and an authzid are provided.

I would say it's very unclear how a server might use the bind DN
regardless of whether an authorization identity was provided or not.

>Certainly not what the authors of RFCs 2222 and 2831 had in mind for SASL and for DIGEST-MD5.

That might be true.  But it seems the authors of RFC 2251
saw the need to ensure clients can provide a bind name when the
authentication identity is not a DN.  I presume they did so
because they saw the need for the server to be able to locate
an entry associated with the authentication identity.

>  Isn't that a big hole?  If I was writing an LDAP client application, I would want to know if the DN I provided on a bind request contributes to the rights of the connection, and I would want the b…

Normally the rights of the authentication identity are
associated with the connection.  If the an authorization
identity is asserted and authentication identity has
rights to assume this identity, the rights of the
authorization identity are associated with the connection.

The hole is that some servers might need a bind name to locate
a directory entry to make the above happen.  Fortunately, servers
seem to have found ways not to need a bind name and just ignore
the bind name if provided.  I suspect one could make a good
argument (on the LDAPbis list) that the bind name should always
be empty when SASL is used.

But, for LDAPext, I suggest we do not get caught up in LDAPbis
issues.  That is, I suggest this API just support independent
setting of the bind name and authorization identity.  I would
recommend that the description of the bind name and authorization
identity parameters both say "generally null."

Kurt

---

From: Rob Weltman <[email-masked]>
Date: Fri, 06 Apr 2001 10:19:47 -0700

> this entry to support evaluation of the proxy authorization

  What if the entry (pointed to by the DN supplied on bind) implies wide-ranging access rights that should not be granted based on the authzid or the authentication ID? When you say "may", do you mean "MAY" as in RFC 2119? That seems to me to lend itself to an indeterminate and insecure server implementation. Shouldn't there be mandatory behavior in evaluating the authorization policy?

Rob

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 06 Apr 2001 11:05:39 -0700

At 10:19 AM 4/6/01 -0700, Rob Weltman wrote:
>  What if the entry (pointed to by the DN supplied on bind) implies wide-ranging access rights that should not be granted based on the authzid or the authentication ID? 

What I meant to imply is that the server might rely on
information held in the entry located by the bind DN
in the authentication/authorization process.  For example,
this entry might contain a list of authzIds which the
authentication identity is allowed to assume the
authorization identity of.

>When you say "may", do you mean "MAY" as in RFC 2119?

No, I meant "may" as in "might", that is, to express a
possibility.  Whether or not the specification allows this
possibility is another matter.

>That seems to me to lend itself to an indeterminate and insecure server implementation.

I do believe there are some security considerations which do
need to be noted when the specification is revised.  Feel free
to raise any you might have to LDAPbis anytime.

>Shouldn't there be mandatory behavior in evaluating the authorization policy?

That might be an area in which the IETF might want to consider
doing some work in.   Right now, RFC 2222, 2251, 2829, and 2830
leave authorization policy implementation up to servers.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 06 Apr 2001 17:50:20 -0700

Rob,

Regarding the security issues previously discussed in
this thread, I note RFC 2251 says:
   When used with SASL, it should be noted that the name field of the
   BindRequest is not protected against modification.  Thus if the
   distinguished name of the client (an LDAPDN) is agreed through the  
   negotiation of the credentials, it takes precedence over any value in
   the unprotected name field.

and RFC 2829 says:
   The method by which a server composes and validates an  
   authorization identity from the authentication credentials
   supplied by a client is implementation-specific.

Though some clarification might be added as part of the LDAPbis
effort, I suspect "implementation-specific" issue would be left
to future standardization.

Kurt

---

From: Rob Weltman <[email-masked]>
Date: Fri, 06 Apr 2001 18:08:11 -0700

>    the unprotected name field.

  That implies that the authorization ID (from the credentials) is used for the bind DN, even if a bind DN is supplied. That means that there IS contamination between the DN parameter and the authzid parameter in the bind() call. If the authzid parameter is null, the DN parameter may be used as the bind DN. If it is not null, and if the server and the client derive a DN from authzid or some other information in the credentials, then the DN parameter will be ignored.

  Or does "credentials" here not refer to the authorization ID?

Rob

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 06 Apr 2001 18:32:03 -0700

>  Or does "credentials" here not refer to the authorization ID?

The credentials are used establish the authentication identity.
That is, in SASL/PLAIN (for simplicity), the username/password
pair form the credential.  The authentication identity is the
username.  The authorization identity can be asserted a long
side of a credential but is generally not part of the credential.

Kurt