[Date Prev][Date Next] [Chronological] [Thread] [Top]


At 11:58 AM 3/12/2004, Hallvard B Furuseth wrote:
>Is the following something we ought to care about?

I think, if someone really cares about this, we could
say that the general applicability statement regarding
security services applies to the TCP-mapping of LDAP and
that applicability of security services to mappings
of LDAP onto other transport protocols is beyond the
scope of this specification.

However, I think it is a bit of rat hole to try to make
the LDAP TS generally neutral of transport (and to call
out those portions specific to the TCP mapping).  And,
I think we have to be very careful not to confuse
implementors of LDAP over TCP with too much talk of other

An alternative would be to state (in section 5 of [Protocol])
that the TS is generally written with the TCP-mapping in
mind and that specification detailing other mappings will
likely have to stand the TS on its ear.


>[Protocol] section 5 (Protocol Element Encodings and Transfer) says:
>   One underlying service, LDAP over TCP, is defined here.
>(It is defined in Section 5.2.1 - which, BTW, I think that section ought
>to mention explicitly.)
>I assume this means that one may define other underlying services too.
>If such a service has the necessary security built in, the IETF
>requirements for security services will be satisfied - by the service
>definition itself, unlike if one deploys LDAP with IPsec.
>Anyway, in this situation TLS might be both unnecessary and
>inappropriate.  So circumstances where we currently require TLS ought to
>only apply to services like LDAP over TCP which do not include security,
>not to all services.
>The same goes for DIGEST-MD5, unless we want
>- to ensure that it is possible to maintain interoperability between
>  this service and LDAP over TCP by setting up a gateway between them
>  (assuming DIGEST-MD5 can always work through such a gateway, which I
>  do not want to try to figure out),
>- or to mandate an authentication mechanism which does not disclose the
>  user's password to the server.
>BTW, could one cheat and make "LDAP over IPsec" such a service
>definition?  In particular, I wonder what "the implementation" would
>consist of.  Maybe it would be just a normal LDAP implementation
>which refused to run if not deployed with IPsec?