Re: RE: Updated version of "X.509 Authentication SASL Mechanism

[Steve Kille <S.Kille@isode.com>]

Alan,

Like you,  I am a strong believer in use of X.500 to 
provide directory infrastructure.

However, I believe that security features such as the one I 
am proposing do not rely on X.500.   I think that this type 
of security is highly desirable for LDAP applications, and 
should be progressed.


Steve


On Fri, 3 Jul 1998 15:48:25 +1000 Alan Lloyd 
<Alan.Lloyd@OpenDirectory.com.au> wrote:

> Steve, the use of X.509 for authentication in the directory 
> system means that X.500 distributed operations and mutual 
> authentication as per X.500 systems will have to be 
> implemented . Simply because the certificate path chains 
> needed to verify the users/client certficate will live 
> in one or more CA directories which are generally attached 
> to the organisations directory that holds the users 
> certificate... OR in the case of LDAP server land , hand 
> configuration and tons of referrals will have to be used to 
> get to these independant CA directories for cert path 
> verification . ie X.509 cert paths are impossible to deal 
> with in LDAP only land.
> 
> In addition with single LDAP servers, where users need to 
> access more than one LDAP server (ie. a non X.500 
> environment), then their entries with their certficates and 
> the crypto engines (which may be hardware) that support 
> their signature algorithms will have to be replicated also.
> 
> And this as we all know,  lies in the realms of nearly 
> impossible to absolutely impossible and fundamentally 
> undesirable.
> 
> In addition the LDAP access control work (if it procedes) 
> and has to scale, has to be tied to distributed and mutual 
> authentication (inter server trust) - and if this is X.509 
> enabled, then LDAP servers will have to adopt domain based 
> access controls (like prescriptive ACI) and tie this to the 
> distributed authentication - as per X.500. 
> 
> What I am saying is very obvious, that increasing the 
> security features of a single LDAP server environment (like 
> with sasl and X.509) will mean that replication 
> requirements of the software/cert entries and crls , etc 
> and crypto hardware that supports becomes impossible. 
> 
> Or another perpsective is: that increasing directory 
> security features with X.509, when that requires (for it to 
> scale) a distributed directory model, WILL mean that the 
> directory service that uses it will end up as that as 
> defined by X.500.
> 
> I suppose the bottom line is LDAP only servers have hit the 
> wall which was obvious to many. So why bother with any 
> schema or security feature in LDAP which fundamentally 
> demands a distributed directory service such as per X.500 
> (which is already defined) to make it work.
> 
> For my view the LDAP standards are now just copying X.500 
> and LDAP single server mode of working has to be like 
> designing yourself into a very restrictive, manually 
> intensive information box.
> 
> X.509 is not very useful in a single client-server mode 
> (LDAP) system unless the people concerned are happy with 
> using their own CA for all their own EC transactions - ie. 
> the organisation is happy with putting in private telephone 
> system.
> 
> 
> 
> Comments are welcome. But it seems all the mechanisms going 
> into LDAP for security and access controls seem to killing 
> off the reason for LDAP servers and at the same time 
> directing their evolution to X.500. So why not use the 
> X.500 standards - FOR ALL DIRECTORY APPLICATIONS 
> and SECURITY.
> 
> Regards alan.
>  
> 
> > ----------
> > From: 	Steve Kille[SMTP:S.Kille@isode.com]
> > Sent: 	Wednesday, 1 July 1998 17:23
> > To: 	ietf-ldapext@netscape.com; 
> internet-drafts@cnri.reston.va.us > Subject: 	Updated 
> version of "X.509 Authentication SASL Mechanism > 
> > I have handled all of the comments recevied, and will 
> send an updated > draft in the next message.   Dependent on 
> comments received on this > version, I will be asking the 
> WG chairs to issue a WG last call on > this document.  
> > > Most of the input has led to straightforward updates.  
> I have changed > the mechanism definition to included the 
> algorithm.  I believe this is > a significant improvement, 
> and fits in with the spirit of SASL. > 
> > Sean Turner gave a number of useful inputs, and I have 
> basically taken > these to align the specification to X.509 
> (97). > 
> > Two comments. > 
> > 1) I have not changed the definition of Time as Sean 
> suggests.  I > prefer to retain X.509 compatibility (unless 
> there are some updates I > am not aware of).   Although 
> there is technically a Y2K issue here,  I > cannot see how 
> this extra complexity will help in any real > situations.   
> Certificates will not be given lifetimes of order 100 > 
> years, and the concept of a centenial replay attack seems 
> daft in any > event. (I'm probably going to get roasted 
> here). > 
> > 2) I added the "generation-time" field, and Sean 
> questioned its use. > This time information is allowed in 
> the general X.509 framework, > althoug X.500 does not use 
> it.  It seems to me that the party doing > the 
> authentication may have a policy on timeouts, and so this 
> field > may be useful in addition to the "time" field which 
> is set according > to the policy of the party being 
> authenticated.  I'd appreciate input > on this.
> > > 
> > Steve Kille > 
>