Re: 2829 questions

["RL 'Bob' Morgan" <rlmorgan@washington.edu>]

On Fri, 22 Dec 2000, Rob Byrne wrote:

> I posted this on ldapext...hope it's in the right place now!

Well, I think your questions are really questions about RFC 2829, hence
legitimately in ldapext, but whatever.

> 1. reading 2829bis it sounds like DIGEST-MD5 is mandatory ONLY IF your
> server
> supports password based authentication because of Section 4 point 2:
>
> "(2) Implementations providing password-based authenticated access
>        MUST support authentication using the DIGEST-MD5 SASL mechanism
>        [4], as described in section 6.1."
>
> ...but the following makes it sound mandatory to provide BOTH password
> authentication AND DIGEST-MD5:
>
> "6.2. Digest authentication
>
>    LDAP implementations MUST support authentication with a password
>    using the DIGEST-MD5 SASL mechanism for password protection, as
>    defined in section 6.1."

I agree that the language in section 4 of 2829 (the (1)(2)(3) bullets that
specify conformance) is somewhat confusing, especially since the text in
section 6 is about the same thing but is slightly different.  I think the
section 4 text started life as "here are the logical conclusions you come
to based on the security requirements" but turned into conformance text
later.  This needs to be clarified as we revise this doc.

The intent, I think, is exactly what section 6 says:  conformant LDAPv3
implementations have to support DIGEST, end of story.  The doc also is
trying to say that DIGEST *is* "authentication with a password"; this
point may not be clear to you since you ask whether it has to support
both.  Support for passwords via simple-bind-over-TLS is a SHOULD, not a
MUST.

> The thing is for acl it would be nice (though not critical) to be able
> to default the required authentication level for a subject to a single
> "fairly secure" mechanism--if there is no such mandatory authentication
> scheme then you cannot do that.

Well, DIGEST is the mandatory authentication mechanism.  I'm not familiar
enough with the acl draft to know what the issue is there, but I'm
guessing that a default would want to be implementation-defined or
deployer-defined, not defined in the spec.

> 2. I think it would be good to have some comments or explicit
> reference to a place where the security properties of the particular
> mandatory authentication schemes are outlined.  When I say "security
> properties" I mean stuff like "This scheme is vulnerable to such and
> such attacks, is only safe if the key size is > 50, this hash is
> widely considered the best, etc...".  I think an LDAP implementor is
> likely to be interested in that information, without having to wade
> through the security RFCs.

Well ... security folks needing to work with LDAP would probably like LDAP
docs to tell them how to design a DIT, and the answer of course is "it
depends"; and it's the same with security levels.  There is only one
mandatory-to-implement scheme, DIGEST, and its security properties are
defined in excruciating detail in section 3 of RFC 2831.  It's considered
relatively easy to implement and deploy, and relatively secure compared to
other similar easy-to-deploy mechanisms (CRAM in particular), which is why
it's mandatory.  Comparing the properties of, say, TLS and DIGEST and
GSS/Kerberos would be a fascinating, complex, and controversial piece of
work; I can't see any way to fit useful material on this topic into an
LDAP standards document.  Recommendations on things like key sizes are
even more ephemeral and context-dependent.

> 3. This is a question rather than a suggestion for a change to
> 2829...again on the subject of authentication level, is it possible to
> define an ordering on authentication levels which defines their
> relative "strengths" ? This would be useful in acl as you could say
> things like "a given aci grants access to a given subject at this
> authentication level AND ABOVE".  David Chadwick raised this before in
> the context of denying access to a subject at a given authentication
> level, in which case he wanted to express "deny access to this subject
> at this authentication level AND TO ALL IDENTITIES AUTHENTICATED BELOW
> THAT LEVEL".

I have heard of deployments that did this kind of thing (eg a brokerage
website that says "you can't make trades over $1M unless you authenticated
with a client cert").  I don't see any way to do this in a standards doc,
since there are too many context-dependent elements that contribute to an
assessment of "strength".  We can agree that traditional
replayable-passwords-in-the-clear is "weak", and all the others are
"stronger".  We can agree that a mechanism that provides and
integrity-protected data stream is stronger than one that doesn't.  But is
Kerberos stronger than DIGEST?  Is S/Key?  Is Kerberos stronger than
passwords-over-TLS?  There's no way to answer these in general, IMHO.

 - RL "Bob"