Re: Authlevel in LDAP ACI

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 08:28 PM 4/19/00 -0600, Jim Sermersheim wrote:
>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>)

My nit is that the stated goal of LDAPaci is to promote interoperability.
If these "levels" are implementation specific, than why?

>
>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
                               ^^^^^^
                               clients

I do not presume that people will be generating ACI values
directly (though they may).  The syntax MUST be designed
such that it is readily MACHINE parsable.

>all over the place if they don't care about levels of security.

Syntax wise, it's wise to place the access-id on the end....  it
it easy (for a MACHINE) to determine where in the current string
the access-id starts.  If you add trailing stuff, it will be
very hard to determine where the access-id ends...

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