[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IPSECKEY] Security Considerations (pass 2)



-----BEGIN PGP SIGNED MESSAGE-----


I've restructured it a bit. Comments welcome.

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 SHOULD 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.  The keying material 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.

   Any use 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.

4.1 Active attacks against unsecured IPSECKEY resource records

   This section deals with active attacks against the DNS.  These
   attacks require that DNS requests and responses be intercepted and
   changed.  DNSSEC is designed to defend against attacks of this kind.

   The first kind of active attack is when the attacker replaces the
   keying material with either a key under its control, or with garbage.

   If the attacker were not able to subsequently mount a second man-in-
   the-middle attack on the IKE negotiation after replacing the public
   key, then this would result in a denial of service, as the
   authenticator used by IKE would fail.

   If the attacker were able to mount both active attacks against DNS,
   and in a position to perform a man-in-the-middle attack on IKE and
   IPsec negotiations, then the attacker would be in a position to
   compromise the resulting IPsec channel.  Note that an attacker must
   be able to perform active DNS attacks on both sides of the IKE
   negotiation in order for this to succeed.

   The second kind of active attack is when the attacker replaces the
   the gateway address to point to a node under the attacker's control.
   The attacker can either replace the public key as well, or remove it
   - providing an IPSECKEY record of its own to match the gateway
   address.

   This later form creates a simple man-in-the-middle.  The attacker
   could create a second tunnel to the real destination.  Note that as
   before, this requires that the attacker also mount an active attack
   against the responder.

   Note that the man-in-the-middle can not only forward cleartext
   packets to the original destination.  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.

   A protocol which permits the gateway field to delegate to a different
   host MAY want to restrict this feature when end-to-end integrity is
   not available.


































Richardson             Expires September 30, 2003              [Page 10]

Internet-Draft                   ipsecrr                      April 2003


5. IANA Considerations

   IANA is asked to assign a resource record type number from the normal
   resource record number space.

   The algorithm field does not require any IANA action, as it is
   inherited from DNS KEY algorithm values.












































Richardson             Expires September 30, 2003              [Page 11]

Internet-Draft                   ipsecrr                      April 2003


6. Acknowledgments

   My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, and Olafur
   Gurmundsson who reviewed this document carefully.  Additional thanks
   to Olafur Gurmundsson for a reference implementation.














































Richardson             Expires September 30, 2003              [Page 12]

Internet-Draft                   ipsecrr                      April 2003


Normative references

   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
        13, RFC 1034, November 1987.

   [2]  Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, November 1987.

   [3]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.

   [4]  Eastlake, D. and C. Kaufman, "Domain Name System Security
        Extensions", RFC 2065, January 1997.






































Richardson             Expires September 30, 2003              [Page 13]

Internet-Draft                   ipsecrr                      April 2003


Non-normative references

   [5]   Thomson, S. and C. Huitema, "DNS Extensions to support IP
         version 6", RFC 1886, December 1995.

   [6]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [7]   Piper, D., "The Internet IP Security Domain of Interpretation
         for ISAKMP", RFC 2407, November 1998.

   [8]   Eastlake, D., "Domain Name System Security Extensions", RFC
         2535, March 1999.

   [9]   Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
         (DNS)", RFC 2536, March 1999.

   [10]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
         System (DNS)", RFC 3110, May 2001.

   [11]  Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
         Record (RR)", RFC 3445, December 2002.


Author's Address

   Michael C. Richardson
   Sandelman Software Works
   470 Dawson Avenue
   Ottawa, ON  K1Z 5V7
   CA

   EMail: mcr@sandelman.ottawa.on.ca
   URI:   http://www.sandelman.ottawa.on.ca/

















Richardson             Expires September 30, 2003              [Page 14]

Internet-Draft                   ipsecrr                      April 2003


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Richardson             Expires September 30, 2003              [Page 15]


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPsq7E4qHRg3pndX9AQF3rQQAoZvG5uu8sYunGmcok5tVGwd9lStEsOkM
rHWI1g5hlWyGz3YVshbdPWeAd7WIC2YyQaWT0n1spx8bImBUl5AJNRCS4mUPXIvs
j47bRM9i7sYl5R0SzZ6Bs204iLP8mgn0RPVSAKOYqt4NAnaJGEAGUC9sjM/C0nNq
LDz5d53/TJU=
=byPv
-----END PGP SIGNATURE-----
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.