Empty sasl credentials question on RFCs 2829/2830

[Jeff.Hodges@kingsmountain.com]

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

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