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

["Greg Carter" <greg@carter-engineering.com>]

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.

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.

4.2.3.5. IssuingDistributionPoint
I think you are confusing Delta CRLs with CRLDistributionPoints.
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.

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

Greg