[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SOI: identity protection and DOS

The very reason to certify a public key is that
 if the key is not 'public' enough than it is subject to MIM attack.

Self-signed cert is subject to MIM attack unless...
then why we need public/private key.

--- David

----- Original Message -----
From: "Steven M. Bellovin" <smb@research.att.com>
To: "Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>
Cc: <ipsec@lists.tislabs.com>
Sent: Monday, November 26, 2001 3:09 PM
Subject: Re: SOI: identity protection and DOS


> In message <p0510100cb8283edaf5fa@[165.227.249.20]>, Paul Hoffman / VPNC
writes
> :
> >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).
>
> Or even IKEv1 -- and that's precisely the point.  Using certificates
> does *not* require existence of a PKI, or even a pki.  (That's the
> great lesson of ssh, btw -- it's very easy to deploy something based on
> exchanging public keys, without dragging any central authority into the
> picture.)  You do have the exponentiations; what that buys you (apart
> from simplicity of the protocol) is protection of authentication
> material in event of peer compromise.  That is, I can hand Alice and
> Bob the same public key for me.  If Bob is compromised, that does not
> allow the attacker to impersonate me when talking to Alice.  To do that
> with pre-shared symmetric keys, I'd have to have a separate key for
> each correspondent, and (depending on just how those keys were
> employed) I might have to worry about MITM attacks.
>
> --Steve Bellovin, http://www.research.att.com/~smb
> Full text of "Firewalls" book now at http://www.wilyhacker.com
>
>
>
References: