Re: I-D ACTION:draft-ietf-ipsec-pki-profile-01.txt

[Brian Korver <briank@xythos.com>]

On Thursday, November 7, 2002, at 02:05 PM, Greg Carter wrote:
> Hi Brian,
> Looks good, some comments on the latest draft:
>
> 4.1.2.2.2. FQDN Host Names
>
> Although clear to me, you may want to explicitly state that placing 
> the FQDN
> in the 'commonName' of the subject field does not mean that the 
> commonName
> field will or should be searched for a matching ID when binding an ID 
> to
> policy.  The subject field of a certificate is treated as a whole when 
> used
> for secure policy ID mapping.  You could reference section "3.2.9.2.
> Identification Data other than a Single Address."   Same for domain
> component.  You could add that 'commonName' and 'domainComponet' 
> should be
> treated as informational fields for an administrator, so that when the
> certificate is viewed at an administration console it can be 
> associated with
> a particular piece of hardware, but it servers no other purpose on its 
> own.

Agreed.  I'll add this to the draft.


>
> 4.1.3.14. CRLDistributionPoint
>
> I would add:
> However receiving CRLs in band via ISAKMP does not alleviate the 
> requirement
> to process the CRLDistributionPoint if the certificate being validated
> contains the extension and the CRL being used to validate the 
> certificate
> contains the IssuingDistributionPoint.  Failure to validate the
> CRLDistributionPoint/IssusingDistributionPoint pair can result in CRL
> substitution where an entity knowingly substitutes a known good CRL 
> for the
> CRL which is supposed to be used which would show the entity as 
> revoked.
> See below for more comments.

Ok.


>
> 4.2.3.5. IssuingDistributionPoint
> I think you are confusing Delta CRLs with CRLDistributionPoints.

I was thinking that CRLDistributionPoints was primarily a feature
of Delta CRLs, but there's no need for that to be the case.
Thanks for the clarification.


> IssuingDistributionPoints should be used to verify that the
> cRLDistributionPoint used to find the CRL (yes even those sent within 
> IKE)
> is the correct CRL to use to verify the certificate.
>
> To clarify CRLDistributionPoints I'll give an example:
>
> A CA that is using CRLDistributionPoints may do so to provide may 
> "small"
> CRLs; each only valid for a particular set of certificates issued by 
> that
> CA.  To associate a CRL with a certificate the CA places the
> CRLDistributionPoint extension in the certificate, and places the
> IssuingDistributionPoint in the CRL.  The
> CRLDistributionPoint::DistributionPointName and the
> IssuingDistributionPoint::DistributionPointName fields would be the 
> same.
> Lets assume that the CA has two CRLs, CRL1 and CRL2 which would be 
> found at
>
> cn=CRL1, ou=CA, o=SomeCompany, c=US
> and
> cn=CRL2, ou=CA, o=SomeCompany, c=US
>
> CRL1 has an IssuingDistributionPoint with a value of "cn=CRL1, ou=CA,
> o=SomeCompany, c=US" and CRL2 has an IssuingDistributionPoint of 
> "cn=CRL2,
> ou=CA, o=SomeCompany, c=US".
>
> The CA issues two certificates CERT1 and CERT2, it decides that CRL1 
> will be
> the place to find revocation information for CERT1.  When issuing 
> CERT1 the
> CRLDistributionPoint extension is placed in the certificate with a 
> value of
> cn=CRL1, ou=CA, o=SomeCompany, c=US.  CERT2 is issued but the
> IssuingDistributionPoint for CRL2 is placed in the CRLDistributionPoint
> extension.
>
> Assuming a non IPSec environment: when an entity attempts to validate 
> CERT1
> the entity would find the CRLDistributionPoint of cn=CRL1, ou=CA,
> o=SomeCompany, c=US in the certificate and fetch the CRL via LDAP from 
> this
> address.  Since LDAP is not trusted, when verifying the CRL the entity 
> must
> verify that the CRL fetched from cn=CRL1, ou=CA, o=SomeCompany, c=US 
> was in
> fact delegated to hold revocation information for the certificate being
> verified.  To do this the IssuingDistributionPoint in the CRL is 
> compared to
> CRLDistributionPoint in the certificate. Without this comparison it is
> possible to use the wrong CRL:
>
> Given that CERT1 is revoked, and that somehow the attacker has placed 
> CRL2
> at cn=CRL1, ou=CA, o=SomeCompany, c=US in the LDAP directory.  If when
> validating the CRL retrieved from cn=CRL1, ou=CA, o=SomeCompany, c=US 
> (which
> is actually CRL2) the IssuingDistributionPoint is not compared to the
> desired CRLDistributionPoint, the CRL will validate (signed by the 
> same CA),
> however CERT1 will not show up in the list of revoked certificates.  So
> CERT1 would appear valid.
>
> How does this relate to IPSec and IKE?  The only thing that is 
> different is
> the delivery mechanism for the CRL, replace LDAP with IKE.  The same 
> attack
> is even easier since the peer will provide the CRLs to use to validate 
> its
> certificate.  Without the CDP/IDP check it is easy to substitute one 
> CRL for
> another.
>
> CRLDistributionPoints are desirable for IPSec/IKE environments because 
> it
> allows a subset of the revocation information to be passed to the peer.
> Instead of 400k-1M+ CRLs you can have many small CRLs.  If it were up 
> to me
> I might change the wording to encourage support of 
> CRLDistributionPoints, at
> least on the validation end to prevent CRL substitution when the 
> issuing CA
> is using them.  I know of at least one CA that defaults to this type 
> of CRL
> use.  Of course see PKIX docs for CDP intellectual rights.

I'm starting to agree with you on this, especially on the validation 
end.


>
> Out of curiosity what CAs have you found that use Delta CRLs?

I've never seen one.  Has anyone on the list seen one in the context of
IPsec or otherwise?


-brian
briank@xythos.com