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