Subject: Re: draft-ietf-pkix-ldap-*: security considerations

From: David Chadwick <[email-masked]>
Date: Thu, 02 Dec 2004 16:05:26 +0000

Kurt

data inconsistency could arise because of
a)bad implementations and
b) an attack.
I dont believe RFCs address concerns of bad implementations. In the case 
of attack, the attributes may not match the stored certificate, so the 
"wrong" certificate or no certificate could be returned. But since only 
the stored certificate is being requested (the attributes are only used 
to aid fitering), and this is digitally signed, then it cannot be 
tampered with without detection. Providing the client checks that 
certificate that is returned is the correct one, then all we have is a 
denial of service attack.  And this can happen if an attacker modifies 
any LDAP server, including a component matching one. So the security 
concerns apply equally well to the component matching implementations, 
and to LDAP servers that dont support any certificate matching.

But since this RFC does not address protocol issues, then I dont believe 
any additional security concerns need be added to it. The concerns 
should be applied to the base LDAP protocol spec "warning, if the LDAP 
server is tampered with, the information that is returned in the LDAP 
protocol may not be that which is required".

regards

David

Kurt D. Zeilenga wrote:
> The security considerations sections of these documents
> are inadequate and seem to nothing more than echo
> general security concerns.  Given the nature of the
> information being stored, I would suspect there would
> be some significant other considerations.  In particular,
> I am surprised not to see any discussion (in the security
> consideration section or elsewhere) on the impact of
> data inconsistencies between user and certificate objects.
> 
> Kurt
> 
> 
> 

-- 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 1484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 03 Dec 2004 08:48:16 -0800

Note that draft-ietf-pkix-ldap-pkc says:
>   If certificates are stored redundantly in person entries and in
>   certificate entries below the person entries, maintainers of     
>   repositories MUST make sure that the same certificates are stored in
>   the person entry and the respective certificate entries and keep this
>   consistency. 

I assume "maintainers" here refers to humans maintaining the
repository.  But even if this referred to automated "maintainers",
I would argue that inconsistencies are inherit in the approach.

>I dont believe RFCs address concerns of bad implementations.

Actually, RFCs often do need to concern themselves about bad
implementations.

>In the case of attack, the attributes may not match the stored certificate, so the "wrong" certificate or no certificate could be returned.

You are assuming the client is requesting the return of the
certificate.  The client may merely be matching components
of the certificate, but requesting the return of non-certificate
information.   The existing text does not appear to consider
this case.

>But since only the stored certificate is being requested (the attributes are only used to aid fitering), and this is digitally signed, then it cannot be tampered with without detection.  Providing the client checks that certificate that is returned is the correct one, then all we have is a denial of service attack.

I see no mention of this attack in the documents.

>And this can happen if an attacker modifies any LDAP server, including a component matching one. So the security concerns apply equally well to the component matching implementations, and to LDAP servers that dont support any certificate matching.

Maybe so, but regardless, this document needs to discuss security
issues that are applicable to it.  And, as I noted previously,
because of certain aspects of this particular approach (including
duplication of information), the manner in which these issues
might need to be addressed is not necessarily the same how those
issues are more generally addressed.

>But since this RFC does not address protocol issues,

The document cannot escape discussing relevant protocol issues.
And, I note, some of the issues have more to do with the
model aspects used in this approach than protocol.

>then I dont believe any additional security concerns need be added to it. The concerns should be applied to the base LDAP protocol spec "warning, if the LDAP server is tampered with, the information that is returned in the LDAP protocol may not be that which is required".
>
>regards
>
>David
>
>
>Kurt D. Zeilenga wrote: