Re: Empty sasl credentials question on RFCs 2829/2830

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 02:49 PM 6/1/2001, Jeff.Hodges@kingsmountain.com wrote:
>Ariel'd sent me these questions/commments privately an embarrassingly long 
>time ago, and I'd mentioned them at IETF meetings also an embarrassingly long 
>time ago. Anyway, there they are for the record. the first item might be 
>considered a material change to the doc(s) (i.e. whatever the successor(s) of 
>RFCs 2829/2830 turn out to be) -- and thus should perhaps be queued for any 
>successor to the successor(s) of RFCs 2829/2830 (got that? ;)
>
>The items following that first one seem to me to be asking for clarifications, 
>and as such are perhaps viable for consideration for inclusion in the 
>successor(s) of RFCs 2829/2830.

I think these issues, including the first, can be handled
though clarification of the existing specification, see below.


>JeffH
>-----
>ariel@columbia.edu wrote...
>
>Empty sasl credentials question:
>
>I spent some more time looking microscopically at 
>ldap-auth-methods and ldap-ext-tls drafts.
>the drafts say that the credential must have the form 
>dn:xxx or u:xxx or be absent,
>and although they don't say what to do in the case of an empty
>octet string I would say that we could send protocolError (claim
>it is a bad PDU).

The server should treat this as if authorization identity
was absent.

When the client wishes to server to derive an authorization
identity from the authentication identity, the client asserts
either an absent or empty authorization identity (depending on
the mechanism).  Some mechanisms, such as EXTERNAL, support
transfer of both absent and empty authorization identities.
However, regardless of which is used, they should be interpreted
in the same way.

The clarification would be to state that when a non-empty
authorization identity is present it is shall be in the form
of an authzId.  Otherwise, the server should imply an
appropriate authorization identity from the authentication
identity.

I note that SASL (RFC 2222) is being updated to clarify that
an absent authorization identity is equivalent to an empty
authorization identity. 
 
>There is still the question of what to do if the credential
>is 'dn:' (or 'u:') followed by the empty string. *sigh* 

The document should just clarify that these should be
treated as invalid authorization identities (as the server
would treat "dn:foo" (invalid DN).  The document like should
recommend a particular resultCode be returned.  I don't
recommend protocolError as this has a specific meaning when
returned in response to a bind request.

>One more comment, on section...
>
>I am uneasy about the hostname check. My experience from 
>PKI with HTTP probably is a contributing factor; we have people
>using the short hostname to get to a server which naturally
>has the FQDN in the certificate, no end of problems. I have
>a certificate on my laptop which has the FQDN for the casse when the
>system is on our Columbia network with a fixed IP; when I dial in
>however, I have some horrible dialup name, and using the local https server
>becomes annoying. Issuing a certificate in the name 'localhost' is
>not a solution! Wildcard match does not solve this problem.
>For these reasons I am inclined to argue for 'SHOULD' instead of
>'MUST' in paragraph...

I might concur with as there are likely other approaches which
offer reasonable security for the environments they are used in.

>Also,
>The hostname check against the name in the certificate is a very weak 
>means of preventing man-in-the-middle attacks; the proper solution is
>not here yet (SecureDNS or some equivalent).  Faking out DNS is not so
>hard, and we see this sort of thing in the press on a pretty regular 
>basis, where site A hijacks the DNS server for site B and gets all their
>requests.  Some mention of this should be made in the draft.



>One final question:
>
>If the 'dn:' form of sasl creds is used, is it the intention
>of the draft(ers) that this DN must exist in the directory
>and the client will have the privileges associated with
>that entry, or can the server map the sasl DN
>to perhaps some other DN in the directory, 
>in an implementation-dependent fashion?

(I recall discussions regarding this on LDAPext... the
archives here might be useful.)

The DN need not refer to an entry in the directory.
The server is free to map it.  The server may even
map it to an uAuthzId.   This is clearly implementation
dependent as there is no standard track specification
in this area.

>We already know that if *no* sasl credentials are presented, the
>DN or altname in the client certificate may be mapped to a DN
>in an implementation-dependent fashion, or indeed to something not
>in the directory at all. (Right?)

Yes.