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

Re: [IPSECKEY] Security Considerations



-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Jean-Jacques" == Jean-Jacques Puig <Jean-Jacques.Puig@int-evry.fr> writes:
    Jean-Jacques> On Tue, May 20, 2003 at 05:51:22PM -0400, Michael Richardson wrote:
    >> >> If the attacker was not able to subsequently mount a second man-in-
    >> >> the-middle attack on the IKE negotiation, then this would result in a
    >> >> denial of service, as the authentication used by IKE would fail.
    >> >> 
    >> >> If the attacker was also in a position to perform a man-in-the-middle
    >> >> attack on IKE and IPsec negotiations as well, then it would be a
    >> >> position to compromise the resulting IPsec channel.  Note that an
    >> >> attack must be able to perform active DNS attacks on both sides of
    >> >> the IKE negotiation in order for this to succeed.
    >> 
    Jean-Jacques> I see your point, but is it expected that IKE initiator and responder
    Jean-Jacques> will both use IPSECKEY RR ? I think asymetric scenarios may happen
    Jean-Jacques> (initiator using IPSECKEY and responder an other scheme).
    >> 
    >> That's true. I have certainly done this in the past!
    >> Both ends *do* need to have their public key's spoofed to get in the middle.
    >> 

    Jean-Jacques> Sorry, I don't know if I was clear about why I was talking about that.
    Jean-Jacques> In the (latests) SC sentence: 

    >> Note that an attacker must
    >> be able to perform active DNS attacks on both sides of the IKE
    >> negotiation in order for this to succeed.

    Jean-Jacques> I think we should only state:

    >> Note that an attacker must
    >> be able to perform active attacks on both sides of the IKE
    >> negotiation in order for this to succeed.

    Jean-Jacques> An active DNS attack against at least one side is what this
    Jean-Jacques> security consideration deals with. The active attack on the other side
    Jean-Jacques> depends on the other channel elected to get public key. This may be

  Okay, let me setup my classic nomenclature to explain:

                             [Q]    [R]
                              .      .              AS2
     [A]---------[SG-A].......+.[M]..+.......[SG-B]-------[B]
            |                 ........
                              ..PI....
                              ..wild..
                             .+.......+......[SG-C] AS3


  Assume that we have:

	 A.in-addr.arpa.	IN IPSECKEY ( 10 1 5 SG-A SG-A's-KEY )
	 B.in-addr.arpa.	IN IPSECKEY ( 10 1 5 SG-B SG-B's-KEY )


  Now, assume that SG-A's doesn't get this record, but instead gets:

	 B.in-addr.arpa.	IN IPSECKEY ( 10 1 5 SG-B SG-M's-KEY )

  that's is, just the KEY is changed.
  We then see:
	  [SG-A] <===IKE========>[M]<===IKE==>[SG-B]

  That is, M pretends to be SG-B to SG-A, and vica-versa.
  Since SG-A has M's key instead of SG-B's key, SG-A is easily fooled into
thinking it is speaking to SG-B.

  However, if as you postulate, SG-B has SG-A's key in a secure fashion, 
then the second IKE transaction, where M pretends to be SG-A, fails. SG-B 
doesn't believe M, since it has SG-A's proper key.
  As such, it won't negotiate, and while SG-A may send traffic to M, M
will be unable to forward it to SG-B.

    Jean-Jacques> Note also that in the present case, the attacker is in position to
    Jean-Jacques> modify phase 1 payloads to force choice of identities, kind of
    Jean-Jacques> authentication, etc. All of this may affect the choice of channels
    Jean-Jacques> elected to get the public keys.

  Yes/no.
  It certainly can do that. The phase 1 info is authenticated after the
privacy is established, so the authentication will fail. 

    Jean-Jacques> Please, if I'm wrong, may someone explain why active DNS attacks MUST
    Jean-Jacques> be performed against BOTH sides in this case.
  
  I hope that the above explains it.

>>>>> "Jean-Jacques" == Jean-Jacques Puig <Jean-Jacques.Puig@int-evry.fr> writes:
    >> packets to the original destination.  While the destination may be
    >> willing to speak in the clear, replying to the original sender, the
    >> sender would have already created a policy expecting ciphertext.
    >> Thus, the need for attacker to intercept traffic from both sides.

    Jean-Jacques> Though it is not usefull to mention it in the draft, I think
    Jean-Jacques> the attacker may achieve easily this interception:
    Jean-Jacques> 1) Attacker provides a wrong IPSECKEY RR with it's own gateway through
    Jean-Jacques> DNS cache poisonning.

    Jean-Jacques> 2) Initiator establishes tunnel with attacker's gateway.

  Yes. Let's call initiator "A".

    Jean-Jacques> 3) Initiator sends packets to Destination through tunnel.

  Yes. Let's call destination "B", and attacker "M"

    Jean-Jacques> 4) Attacker masquerades source address of packets coming through the
    Jean-Jacques> tunnel, and forwards them to Destination.

  Do you mean performs NAPT or NAT?

    Jean-Jacques> 5) Destination answers to the masqueraded address (the attacker)

    Jean-Jacques> 6) Attacker masquerades destination address of packets coming from
    Jean-Jacques> Destination, and forwards them through the tunnel, etc.
    Jean-Jacques> Attackers main difficulty is then to deal with transport checksums and
    Jean-Jacques> application datas containing endpoint addresses or names.

  Trivial, I think, since NAT technology is widely available, and there are few
protocols which are in widespread use that do not have NAPT support.

  Note that the destination (B) logs a connection from the attacker (M).
  It also has no security, and knows it has none. 
  Since it was willing to speak in the clear in this case, I would expect
that it already thinks life is fine with being spoofed. 

  M could also initiate to B, at which point B knows that it has a tunnel
to M, not to A. It could even be the case that B knows M is M securely (DNSSEC).

  The concern is naturally that "A" thinks that it is speaking securely to
"B".  It  may reveal passwords, etc. to M.  It has been spoof'ed by M. Is
this a new attack? Not really to me.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPs0EfYqHRg3pndX9AQFlVAP9EuNwVbZmDmYFSZuh5/DUIhEGfDUQ+6bx
fABQkhNHQHwGr2Sha+DS16wuEVl+NQ9g54lfrKm1LbOmFX8xZ8rZd6s1PT6zgnHR
PdbxXZEG/Fc2vksfSxiH1uUq/1FG+TaxZsQpwvB9v7OgPN3XgbC1xKdOVzDsJ/Lw
ruSTSKiR18A=
=Ybtm
-----END PGP SIGNATURE-----
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.