[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SOI: identity protection and DOS
At 9:20 AM -0800 11/26/01, Michael Thomas wrote:
> If you allow for pre-shared keys, then it clearly
> requires an extra message or two. Which is why we
> should determine what the actual requirement is
> re pre-shared keys. If it's a requirement, then
> we need to confront the time/protection tradeoff.
> If it's not a requirement, this mostly vanishes.
Positive traits of IKEv1 pre-shared keys:
a) easy for each party to set up
b) not susceptible to CRL time lag or CA key compromise
c) fewer exponentiations on each side for IPsec key setup
Negative traits of IKEv1 pre-shared keys:
d) hard to scale
e) unless identity protection is not needed, the initiator must be at
known IP address, and there must be only one pre-shared key at that
address
f) out-of-band swapping of the key must be done privately
If what is most important is (a) and (b), and the problem of (d) is
not important, both the JFK and IKEv2 implementations can be
trivially set up for this by allowing one or both sides to use
self-signed certificates, where the other side has trusted the public
key in the certificate using some out-of-band mechanism. In JFK and
IKEv2 using this method, you don't get advantage (c), but you don't
have disadvantage (e) or (f).
Thus, for the scenarios of "quick interop testing" and "a WAN made up
of a handful of gateways", JFK and IKEv2 already work just fine if
the implementations allow for trusting self-signed certs based on key
hashes.
--Paul Hoffman, Director
--VPN Consortium
Follow-Ups:
References: