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