[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> Ok, I see where we failed to understand each others. The difference is I
    Jean-Jacques> assume the *general case* we consider is where IPSECKEY information is
    Jean-Jacques> available for one peer, while the other peer may use other unsecure ways
    Jean-Jacques> to get public keys (let's say a floppy with raw unauthenticated datas).

  I'm not sure I'd call a floppy unauthenticated, but I understand that you
are saying that M can not mount an online attack against B.

    Jean-Jacques> Because M provided wrong responder key to SG-A through un-(integrity
    Jean-Jacques> protected) ipseckey rr, M is able to recompute the kind of message from
    Jean-Jacques> IKE's phase1 with public key encryption:
    Jean-Jacques> HDR, KE, [ HASH(1), ] <IDii_b>PubKey_r,<Ni_b>PubKey_r (mesg 3)
    Jean-Jacques> Thus, M is able to annonce a different IDii. According to the type of
    Jean-Jacques> IDii, the responder may try to get public key of SG-A, and get fooled by
    Jean-Jacques> the false IDii provided by M.

  This depends a lot upon how you use IPSECKEY, I guess.
  Are you assuming that M is also impersonating B's IP?

  I agree that this is a man-in-the-middle attack. It is what happens when
you use unauthenticated data :-)
  
    >> 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.

    Jean-Jacques> No, of course it is not new, we all know that, and discussion about SC is
    Jean-Jacques> mostly about stating what we think we already know ;-)). But:

    >> 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> According to this sentence, one may think that M MUST be on 'the'
    Jean-Jacques> route a packet would 'naturally' follow to go from SG-A to SG-B.
    Jean-Jacques> This is not required: By providing it's own security gateway through the
    Jean-Jacques> RR to the initiator, M both get a way to be IKE's responder and to
    Jean-Jacques> intercept the packets, even if he was not on the classical route between
    Jean-Jacques> SG-A and SG-B initially. M must then make sure he will get answers
    Jean-Jacques> destined to A. He may proceed according one of the following ways:

  okay, you've sold me. Can you suggest text to detail this? Are you
suggesting that I simply remove the highlighted (upcase) sentence?
 
    Jean-Jacques> Well anyway, I was only questioning the accuracy of the above
    Jean-Jacques> consideration, but I agree I do hairs splitting here :), and that it
    Jean-Jacques> reaches the frontiers of the charter.

  So, tell me what you'd like to do here...

]       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

iQCVAwUBPs4p3oqHRg3pndX9AQGLAQP/U7VdJvIpAr9SqTS5ke/pPVc504PD0fP2
7+Zdth60LMKMezaSO2t9wJ7zr4yE5DL4E7pN0RCHBttiaPQkarfTz2zpz4M4deJr
xA58/6Ibx7bR6dc6iuwsURSdB25MYil33n0VTrojSsfWl9Syz3o/Xv197dxh4Oc5
H5FsbqAoZwY=
=gyFR
-----END PGP SIGNATURE-----
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.