[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PKIX vs draft-ietf-ipsec-pki-req-02.txt
Mark,
<snip>
>I believe that IPSEC to the desktop will become widespread. In that
>environment it makes sense to differentiate between the certificates you
>are issuing to people for desktop and remote-access authentication, and
>certs that you recognize for router authentication. If you don't make
>this distinction it is possible for someone to get a personal cert and
>use it to fake a router that wants to talk to your network. There are
>several ways you could differentiate:
>
> - different X.509 policy info
> - separate root or intermediate ca's
> - different EKUsages
> - different subjectAltNames
>
>I'm strongly in favour of the EKU approach, since EKU is widely used in
>other Internet apps. And you can have multiple EKUsages for a single
>cert if it makes business sense. I think X.509 policy info is largely
>wasted since very few implementations can use it. And it is cumbersome
>to force an organization to maintain separate CA's (MUCH easier to use
>separate EKU's). The subjectAltName method is promising. For example, a
>"server" could be defined as an object with a cert containing EKU:iKEEnd
>and a subjectAltName with a domain name that resolves to its IP address.
I don't think policy info is an appropriate way to distinguish among certs
issued to these different classes of entities, nor is there a need for
separate roots or CAs. I agree that EKU and names (primary or alternative)
are the most appropriate choices. Yes, EKU is being used elsewhere, e.g.,
in S/MIME, but that doesn't help an IPsec implementation. One can use
names to identify different classes of entities, and base access control
decisions on that.
>Does all of this make sense, or am I missing the whole point entirely?
>
>> id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 }
>> id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 }
>> id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 }
>
>You're right - I had an old version that had ipsecServer instead of
>EndSystem. Actually having Tunnel in there makes sense to me, since you
>definitely want to control certs that are ostensibly allowed to claim
>tunneling capability VERY tightly. I think ;-).
Why do I care about tunnel use? Gateways must use tunnels, but end
systems may use tunnels as well.
Steve
Follow-Ups:
References: