[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> A question regarding the charter ipsec-specific scope: obviously, the
    Jean-Jacques> IPSECKEY RR public key is for use with a key management protocol (KMP).

  Yes.

    Jean-Jacques> But I came to wonder about what means 'ipsec-specific' ? Does this means
    Jean-Jacques> that the KMP belongs to the ipsec protocols suite (this is how I
    Jean-Jacques> understand it) or does this means that it is for use for a

  Yes. It would be IKE, IKEv2, and perhaps Photoris (if you can find any).
  KINK/IKE would not use public keys directly (the KDC might), so this doesn't matter.

    >> The keying material provided by the IPSECKEY resource record is not
    >> sensitive to passive attacks - it may be freely disclosed to any
    >> party without any impact on the security properties of the resulting
    >> IPsec session: IPsec and IKE provide for defense against both active
    >> and passive attacks.
    >> 

    Jean-Jacques> Do we really need to speak about IPsec and IKE here ? The RR datas are
    Jean-Jacques> expected to be public and as such are implicitly unsensitive to passive
    Jean-Jacques> attacks.

  SC is mostly about stating what we think we already know :-)

    >> An active attack against this record, were it not provided with end-
    >> to-end integrity, would provide an opportunity for an attacker to
    >> replace the keying material.

    Jean-Jacques> What about the gateway ? By providing his own gateway (with a suitable
    Jean-Jacques> key or with an ipseckey rr for the gateway), wouldn't the attacker
    Jean-Jacques> manage to reroute destination packets to him thanks to the tunnel ?
    Jean-Jacques> Would this help to set up a MiM ?

  Yes, they could do that.
  Does this need to be stated.

    >> 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.
  
]       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

iQCVAwUBPsqjV4qHRg3pndX9AQHxfAQAqcc63afc+QFV6E773uYNMO3nwzL9kyFk
hEVrfI6LDsrDMgkvltO4JF2E7jT5M1/t7wFFZkt5KlrGETvmHZqp4oMCVxIqe++m
W8hcBnQPKp6kIlsTvrxzLLJty9DHhL7/fyfnC5EKmE9slocFaw594tDpHMSJtcQG
g4sq/buxsGE=
=ZGWF
-----END PGP SIGNATURE-----
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.