Difference between revisions of "RFC2521"
imported>Admin (Created page with " Network Working Group P. Karn Request for Comments: 2521 Qualcomm Category: Experimental ...") |
|||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Network Working Group P. Karn | Network Working Group P. Karn | ||
Request for Comments: 2521 Qualcomm | Request for Comments: 2521 Qualcomm | ||
Line 10: | Line 4: | ||
DayDreamer | DayDreamer | ||
March 1999 | March 1999 | ||
− | |||
ICMP Security Failures Messages | ICMP Security Failures Messages | ||
− | + | '''Status of this Memo''' | |
− | Status of this Memo | ||
This document defines an Experimental Protocol for the Internet | This document defines an Experimental Protocol for the Internet | ||
Line 22: | Line 14: | ||
Distribution of this memo is unlimited. | Distribution of this memo is unlimited. | ||
− | Copyright Notice | + | '''Copyright Notice''' |
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn | Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn | ||
and William Allen Simpson (1994-1999). All Rights Reserved. | and William Allen Simpson (1994-1999). All Rights Reserved. | ||
− | Abstract | + | '''Abstract''' |
This document specifies ICMP messages for indicating failures when | This document specifies ICMP messages for indicating failures when | ||
using IP Security Protocols (AH and ESP). | using IP Security Protocols (AH and ESP). | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Karn & Simpson Experimental [Page i] | Karn & Simpson Experimental [Page i] | ||
+ | Karn & Simpson Experimental [Page ii] | ||
== Introduction == | == Introduction == | ||
Line 76: | Line 45: | ||
40 Security Failures | 40 Security Failures | ||
− | |||
− | |||
== Message Formats == | == Message Formats == | ||
Line 90: | Line 57: | ||
| | | | | | ||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||
− | |||
Type 40 | Type 40 | ||
Line 102: | Line 68: | ||
4 = Need Authentication | 4 = Need Authentication | ||
5 = Need Authorization | 5 = Need Authorization | ||
− | |||
Checksum Two octets. The ICMP Checksum. | Checksum Two octets. The ICMP Checksum. | ||
Reserved Two octets. For future use; MUST be set to zero | Reserved Two octets. For future use; MUST be set to zero | ||
− | |||
− | |||
− | |||
− | |||
when transmitted, and MUST be ignored when received. | when transmitted, and MUST be ignored when received. | ||
Line 131: | Line 92: | ||
Usage of this message is elaborated in the following sections. | Usage of this message is elaborated in the following sections. | ||
− | |||
=== Bad SPI === | === Bad SPI === | ||
Line 137: | Line 97: | ||
Indicates that a received datagram includes a Security Parameters | Indicates that a received datagram includes a Security Parameters | ||
Index (SPI) that is invalid or has expired. | Index (SPI) that is invalid or has expired. | ||
− | |||
=== Authentication Failed === | === Authentication Failed === | ||
Line 146: | Line 105: | ||
Note that the SPI may indicate an outer Encapsulating Security | Note that the SPI may indicate an outer Encapsulating Security | ||
Protocol when a separate Authentication Header SPI is hidden inside. | Protocol when a separate Authentication Header SPI is hidden inside. | ||
− | |||
=== Decompression Failed === | === Decompression Failed === | ||
Line 152: | Line 110: | ||
Indicates that a received datagram failed a decompression check for a | Indicates that a received datagram failed a decompression check for a | ||
given SPI. | given SPI. | ||
− | |||
=== Decryption Failed === | === Decryption Failed === | ||
Line 158: | Line 115: | ||
Indicates that a received datagram failed a decryption check for a | Indicates that a received datagram failed a decryption check for a | ||
given SPI. | given SPI. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
=== Need Authentication === | === Need Authentication === | ||
Line 173: | Line 124: | ||
present. For example, an encryption SPI without integrity arrives | present. For example, an encryption SPI without integrity arrives | ||
from a secure operating system with mutually suspicious users. | from a secure operating system with mutually suspicious users. | ||
− | |||
=== Need Authorization === | === Need Authorization === | ||
Line 185: | Line 135: | ||
by the datagram. For example, the party is authorized for Telnet | by the datagram. For example, the party is authorized for Telnet | ||
access, but not for FTP access. | access, but not for FTP access. | ||
− | |||
== Error Procedures == | == Error Procedures == | ||
Line 206: | Line 155: | ||
configurable. How the limits are applied (such as, by destination or | configurable. How the limits are applied (such as, by destination or | ||
per interface) is left to the implementor's discretion. | per interface) is left to the implementor's discretion. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Security Considerations | Security Considerations | ||
Line 264: | Line 202: | ||
messages will not result in an error indication. At the very least, | messages will not result in an error indication. At the very least, | ||
this will lengthen the time factor for verifying such information. | this will lengthen the time factor for verifying such information. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
History | History | ||
Line 278: | Line 210: | ||
authors for IETF Last Call as a Proposed Standard in March 1996. | authors for IETF Last Call as a Proposed Standard in March 1996. | ||
There have been several implementations. | There have been several implementations. | ||
− | |||
Acknowledgements | Acknowledgements | ||
Line 293: | Line 224: | ||
Special thanks to the Center for Information Technology Integration | Special thanks to the Center for Information Technology Integration | ||
(CITI) for providing computing resources. | (CITI) for providing computing resources. | ||
− | |||
References | References | ||
− | [RFC-792] Postel, J., "Internet Control Message Protocol", STD 5, | + | [RFC-792] Postel, J., "Internet Control Message Protocol", [[STD5|STD 5]], |
September 1981. | September 1981. | ||
[RFC-1122] Braden, R., Editor, "Requirements for Internet Hosts -- | [RFC-1122] Braden, R., Editor, "Requirements for Internet Hosts -- | ||
− | Communication Layers", STD 3, USC/Information Sciences | + | Communication Layers", [[STD3|STD 3]], USC/Information Sciences |
Institute, October 1989. | Institute, October 1989. | ||
− | [RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, | + | [RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", [[STD2|STD 2]], |
USC/Information Sciences Institute, October 1994. | USC/Information Sciences Institute, October 1994. | ||
Line 312: | Line 242: | ||
[RFC-1825] Atkinson, R., "Security Architecture for the Internet | [RFC-1825] Atkinson, R., "Security Architecture for the Internet | ||
Protocol", Naval Research Laboratory, July 1995. | Protocol", Naval Research Laboratory, July 1995. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Contacts | Contacts | ||
Line 338: | Line 257: | ||
[email protected] (preferred) | [email protected] (preferred) | ||
− | |||
William Allen Simpson | William Allen Simpson | ||
Line 348: | Line 266: | ||
[email protected] (preferred) | [email protected] (preferred) | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Full Copyright Statement | Full Copyright Statement | ||
Line 405: | Line 295: | ||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | ||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
[[Category:Experimental]] | [[Category:Experimental]] |
Latest revision as of 23:11, 19 October 2020
Network Working Group P. Karn Request for Comments: 2521 Qualcomm Category: Experimental W. Simpson
DayDreamer March 1999
ICMP Security Failures Messages
Status of this Memo
This document defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn and William Allen Simpson (1994-1999). All Rights Reserved.
Abstract
This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH and ESP).
Karn & Simpson Experimental [Page i]
Karn & Simpson Experimental [Page ii]
Contents
Introduction
This mechanism is intended for use with the Internet Security Protocols [RFC-1825 et sequitur] for authentication and privacy. For statically configured Security Associations, these messages indicate that the operator needs to manually reconfigure, or is attempting an unauthorized operation. These messages may also be used to trigger automated session-key management.
The datagram format and basic facilities are already defined for ICMP [RFC-792].
Up-to-date values of the ICMP Type field are specified in the most recent "Assigned Numbers" [RFC-1700]. This document concerns the following values:
40 Security Failures
Message Formats
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Original Internet Headers + 64 bits of Payload ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 40
Code Indicates the kind of failure:
0 = Bad SPI 1 = Authentication Failed 2 = Decompression Failed 3 = Decryption Failed 4 = Need Authentication 5 = Need Authorization
Checksum Two octets. The ICMP Checksum.
Reserved Two octets. For future use; MUST be set to zero
when transmitted, and MUST be ignored when received.
Pointer Two octets. An offset into the Original Internet
Headers that locates the most significant octet of the offending SPI. Will be zero when no SPI is present.
Original Internet Headers ...
The original Internet Protocol header, any intervening headers up to and including the offending SPI (if any), plus the first 64 bits (8 octets) of the remaining payload data.
This data is used by the host to match the message to the appropriate process. If a payload protocol uses port numbers, they are assumed to be in the first 64-bits of the original datagram's payload.
Usage of this message is elaborated in the following sections.
Bad SPI
Indicates that a received datagram includes a Security Parameters Index (SPI) that is invalid or has expired.
Authentication Failed
Indicates that a received datagram failed the authenticity or integrity check for a given SPI.
Note that the SPI may indicate an outer Encapsulating Security Protocol when a separate Authentication Header SPI is hidden inside.
Decompression Failed
Indicates that a received datagram failed a decompression check for a given SPI.
Decryption Failed
Indicates that a received datagram failed a decryption check for a given SPI.
Need Authentication
Indicates that a received datagram will not be accepted without additional authentication.
In this case, either no SPI is present, or an unsuitable SPI is present. For example, an encryption SPI without integrity arrives from a secure operating system with mutually suspicious users.
Need Authorization
Indicates that a received datagram will not be accepted because it has insufficient authorization.
In this case, an authentication SPI is present that is inappropriate for the target transport or application. The principle party denoted by the SPI does not have proper authorization for the facilities used by the datagram. For example, the party is authorized for Telnet access, but not for FTP access.
Error Procedures
As is usual with ICMP messages, upon receipt of one of these error messages that is uninterpretable or otherwise contains an error, no ICMP error message is sent in response. Instead, the message is silently discarded. However, for diagnosis of problems, a node SHOULD provide the capability of logging the error, including the contents of the silently discarded datagram, and SHOULD record the event in a statistics counter.
On receipt, special care MUST be taken that the ICMP message actually includes information that matches a previously sent IP datagram. Otherwise, this might provide an opportunity for a denial of service attack.
The sending implementation MUST be able to limit the rate at which these messages are generated. The rate limit parameters SHOULD be configurable. How the limits are applied (such as, by destination or per interface) is left to the implementor's discretion.
Security Considerations
When a prior Security Association between the parties has not expired, these messages SHOULD be sent with authentication.
However, the node MUST NOT dynamically establish a new Security Association for the sole purpose of authenticating these messages. Automated key management is computationally intensive. This could be used for a very serious denial of service attack. It would be very easy to swamp a target with bogus SPIs from random IP Sources, and have it start up numerous useless key management sessions to authentically inform the putative sender.
In the event of loss of state (such as a system crash), the node will need to send failure messages to all parties that attempt subsequent communication. In this case, the node may have lost the key management technique that was used to establish the Security Association.
Much better to simply let the peers know that there was a failure, and let them request key management as needed (at their staggered timeouts). They'll remember the previous key management technique, and restart gracefully. This distributes the restart burden among systems, and helps allow the recently failed node to manage its computational resources.
In addition, these messages inform the recipient when the ICMP sender is under attack. Unlike other ICMP error messages, the messages provide sufficient data to determine that these messages are in response to previously sent messages.
Therefore, it is imperative that the recipient accept both authenticated and unauthenticated failure messages. The recipient's log SHOULD indicate when the ICMP messages are not validated, and when the ICMP messages are not in response to a valid previous message.
There is some concern that sending these messages may result in the leak of security information. For example, an attacker might use these messages to test or verify potential forged keys. However, this information is already available through the simple expedient of using Echo facilities, or waiting for a TCP 3-way handshake.
The rate limiting mechanism also limits this form of leak, as many messages will not result in an error indication. At the very least, this will lengthen the time factor for verifying such information.
History
The text has been extensively reviewed on the IP Security mailing list, in January and February of 1995 and again in December 1995. The specification is stable, and was forwarded to the IESG by the authors for IETF Last Call as a Proposed Standard in March 1996. There have been several implementations.
Acknowledgements
Some of the text of this specification was derived from "Requirements for Internet Hosts -- Communication Layers" [RFC-1122] and "Requirements for IP Version 4 Routers" [RFC-1812].
Naganand Doraswamy and Hilarie Orman provided useful critiques of earlier versions of this document.
Stimulating comments were also received from Jeffrey Schiller.
Special thanks to the Center for Information Technology Integration (CITI) for providing computing resources.
References
[RFC-792] Postel, J., "Internet Control Message Protocol", STD 5,
September 1981.
[RFC-1122] Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layers", STD 3, USC/Information Sciences Institute, October 1989.
[RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2,
USC/Information Sciences Institute, October 1994.
[RFC-1812] Baker, F., Editor, "Requirements for IP Version 4
Routers", Cisco Systems, June 1995.
[RFC-1825] Atkinson, R., "Security Architecture for the Internet
Protocol", Naval Research Laboratory, July 1995.
Contacts
Comments about this document should be discussed on the [email protected] mailing list.
Questions about this document can also be directed to:
Phil Karn Qualcomm, Inc. 6455 Lusk Blvd. San Diego, California 92121-2779
[email protected] [email protected] (preferred)
William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071
[email protected] [email protected] (preferred)
Full Copyright Statement
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn and William Allen Simpson (1994-1999). 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 DISCLAIM 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.