Subject: Empty sasl credentials question on RFCs 2829/2830

From: [email-masked]
Date: Fri, 01 Jun 2001 14:49:24 -0700

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.

JeffH
-----
[email-masked] 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).

There is still the question of what to do if the credential
is 'dn:' (or 'u:') followed by the empty string. *sigh* 

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...

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?

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?)

-----
end

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 06 Jun 2001 19:22:20 -0700

>successor(s) of RFCs 2829/2830.

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

>octet string I would say that we could send protocolError (claim

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. 
 
>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.

>For these reasons I am inclined to argue for 'SHOULD' instead of

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

>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.

>in the directory at all. (Right?)

Yes.