Hi Stephen
Stephen Kent wrote:
> IPsec, unlike SSL, has no client or server roles. It is a peer communication protocol. So, I am not so keen to put in distinctions of the sort you mentioned.
I hear you. I'm still learning about IPSEC, and I like what I see. I'm
not against peer to peer scenarios in any way, but I do think that the
distinction is important. First, corporate security policies tend to be
different for machines (web servers, routers) and for humans (s/mime,
client auth). They tend to issue certificates differently to these broad
groups. We see huge differences between S/MIME and SSL server certs.
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.
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 ;-).
What say you?
--
Mark Shuttleworth
Thawte
S/MIME Cryptographic Signature