[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[IPSECKEY] Security Considerations
4. Security Considerations
This entire memo pertains to the provision of public keying material
for use by key management protocols such as ISAKMP/IKE (RFC2407) [7].
The IPSECKEY resource record contains information that MUST be
communicated to the end client in an integral fashion - i.e. free
from modification. The form of this channel is up to the consumer of
the data - there must be a trust relationship between the end
consumer of this resource record and the server. This relationship
may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to
another secure source, a secure local channel on the host, or some
combination of the above.
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.
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.
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.
The semantics of when to use this record is outside of the scope of
this document. Any user of this resource record MUST carefully
document their trust model, and why the trust model of DNSSEC is
appropriate, if that is the secure channel used.
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.