[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PKIX vs draft-ietf-ipsec-pki-req-02.txt
Mark,
>I'm certainly in agreement with you about overloading. But I think that
>organizations will want to build SIMPLE rules to differentiate between
>routers, gateways and end-users. They should be able to do this JUST by
>looking at the cert, and not by referring to a directory or other source
>(otherwise you add another fragile link in the chain).
>
>So, there needs to be some broad agreement about how this is done so
>that these policies can work in a heterogenous environment.
EKUs have an advantage over names in that name conventions would be less
likely to be uniforly enforced, and might otherwise impinge on local name
conventions.
>For example, in many of the current implementations I've seen you have
>to explicitly manually trust the certificates of each of the devices you
>want to talk to. This is a configuration nightmare in larger-scale
>deployments. Each device needs to be manually told about n other
>certificates (and updated each time one of them expires). You really
>want to be able to say "look at the iPAddress or dNSName in the cert and
>make sure it matches the iPAddress with which you are exchanging
>packets". This way there is no manual configuration of certificates -
>each router has a normal set of routing tables and expects the routers
>it talks to securely to be able to produce a valid cert signed by one of
>the trusted CA's with a subjectAltName that matches its dNSName or
>iPAddress.
I think you may be confusing two issues here. One needs to manually
configure a set of (CA) certs to use as reference points for validation of
certs received from other IPsec entities. The number of such "root" certs
needed wil depend on the extent of the communication envisioned and the
scope of the CAs in question. One creates individual SPD entries to
authorize communication with specified IPsec entities. In the worst case,
one might have a one-to-one correspondence betwee manually configured certs
and SPD entries, if one could specify no CAs that could be used to provide
validation bases for multiple IPsec entities. My limited experience
suggests that this is not the usual case. However, one must be careful to
ensure that each CA cannot issue certs for just any possible SPD entry. In
our environment, we employ the nameConstraints extension to enforce this.
This works pretty well because we deal with CAs that are per-organization
and thus the certs issued by these CAs are appropriately constrained to
issues certs for entities in that organization (either DNs or DNS
altnames). One can even do this for certs using ipaddresses as altNames.
>The preferred way for us would be subjectAltName. In other words, for
>machine, router and gateway certificates we put an IPaddress or dNSName
>in the cert, while for user certificates we put one or more email
>addresses. If this was the rule, then we could differentiate between
>"machine" certificates and "human" certificates on the basis of the
>subjectAltName. Then I would be happy with Rodney's proposal of iKEEnd
>and iKEIntermediate. Servers and point-to-point routers would have
>iKEEnd with a subjectAltName iPAddress or dNSName, while end-users would
>have iKEEnd with a subjectAltName rfc822Name. Firewalls would have
>iKEIntermediate with a dNSName or iPAddress.
I would not mnind this approach, but I wonder if anyone objects because it
does not allow for DNs to identify any of these entities?
Steve
References: