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