Re: Authlevel in LDAP ACI

["Jim Sermersheim" <JIMSE@novell.com>]

I think of two things - one is that I don't mind if it's called "other" instead of strong, the other is that it's only a matter of time before someone wants to grant/deny based on the privacy of the pipe. In fact, Novell already does this but at a really gross level (per DSA, applies to everyone). It would be good if it were part of ACI. I suggest confidentialityLevel (could be "none", TLS:cipherSuite, <some future scheme:level>)

Okay, I lied, I have four thoughts.  Why is it OK that we're adding authLevel - which is a whole new concept - but we shot down the request to allow a more granular ipAddress (grant/deny based on a subnet) - which is just a minor tweak to something that's already there? (I think we were chanting the mantra of reduced complexity).

Finally a nit. I'd rather place these additional items at the end of the BNF and make them optional so that people don't have to be bothered with "none"'s all over the place if they don't care about levels of security.

Jim 


>>> Ellen Stokes <stokes@austin.ibm.com> 4/19/00 2:36:01 AM >>>
Kurt,

I see your point.  But, then "strong'' is in the eye of the beholder.
The point of digest-md5 was to limit some security holes in
authentication.

What do others think?

Ellen

At 07:36 AM 4/19/00 +0200, Kurt D. Zeilenga wrote:
>At 08:45 PM 4/18/00 -0500, Ellen Stokes wrote:
> >Here's a sketchy BNF for incorporating authentication strength
> >and mechanism per today's discussion.
> >
> >< ldapACI > ::= < acl entry syntax >
> >
> >< acl entry syntax > ::= <familyOID> + '#' + <scope > + '#'
> >                              + < rights >  + '#' + < dnType >
> >                              + < authLevel > + '#' + < subjectDn >
> >
> >< authLevel > ::= "none" | "simple" | <strong>
> >
> >< strong > ::= "strong" | < SASLauth >
> >
> >< SASLauth > ::= "SASL" + ':' + < SASLmech >
> >
> >< SASLmech > ::= "EXTERNAL" | "DIGEST-MD5" | "KERBEROS-ID" |< 
> printableString
>
>KERBEROS-ID is not a SASL mechanism, it's a form of authorization
>(access) identity.
>
> >
> >Assumption here is that anything other than none or simple is strong and
> >strong can
> >be specified as strong (any other mechanism) or an explicit mechanism.
>
>This use of "strong" is misleading.  Simple authentication when
>solid privacy and integrity are in place (ala TLS, IPSEC) is
>actually stronger than DIGEST-MD5 without such protections.