diff options
Diffstat (limited to 'doc/rfc/rfc4822.txt')
| -rw-r--r-- | doc/rfc/rfc4822.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc4822.txt b/doc/rfc/rfc4822.txt new file mode 100644 index 0000000..aa21607 --- /dev/null +++ b/doc/rfc/rfc4822.txt @@ -0,0 +1,1235 @@ + + + + + + +Network Working Group R. Atkinson +Request for Comments: 4822 Extreme Networks +Obsoletes: 2082 M. Fanto +Updates: 2453 NIST +Category: Standards Track February 2007 + + + RIPv2 Cryptographic Authentication + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +IESG Note + + In the interests of encouraging rapid migration away from Keyed-MD5 + and its known weakness, the IESG has approved this document even + though it does not meet the guidelines in BCP 107 (RFC 4107). + However, the IESG stresses that automated key management should be + used to establish session keys and urges that the future work on key + management described in Section 5.6 of this document should be + performed as soon as possible. + +Abstract + + This note describes a revision to the RIPv2 Cryptographic + Authentication mechanism originally specified in RFC 2082. This + document obsoletes RFC 2082 and updates RFC 2453. This document adds + details of how the SHA family of hash algorithms can be used with + RIPv2 Cryptographic Authentication, whereas the original document + only specified the use of Keyed-MD5. Also, this document clarifies a + potential issue with an active attack on this mechanism and adds + significant text to the Security Considerations section. + + + + + + + + + + +Atkinson & Fanto Standards Track [Page 1] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + +1. Introduction + + Growth in the Internet has made us aware of the need for improved + authentication of routing information. RIPv2 provides for + unauthenticated service (as in classical RIP), or password + authentication. Both are vulnerable to passive attacks currently + widespread in the Internet. Well-understood security issues exist in + routing protocols [Bell89]. Cleartext passwords, originally + specified for use with RIPv2, are widely understood to be vulnerable + to easily deployed passive attacks [HA94]. + + The original RIPv2 cryptographic authentication specification, RFC + 2082 [AB97], used the Keyed-MD5 cryptographic mechanism. While there + are no openly published attacks on that mechanism, some reports + [Dobb96a, Dobb96b] create concern about the ultimate strength of the + MD5 cryptographic hash function. Further, some end users, + particularly several different governments, require the use of the + SHA hash function family rather than any other such function for + policy reasons. Finally, the original specification uses a hashing + construction widely believed to be weaker than the HMAC construction + used with the algorithms added in this revision of the specification. + + This document obsoletes the original specification, RFC 2082 [AB97]. + This specification differs from RFC 2082 by adding support for the + SHA family of hash algorithms and the HMAC technique, while retaining + the original Keyed-MD5 algorithm and mode. As the original RIPv2 + Cryptographic Authentication mechanism was algorithm-independent, + backwards compatibility is retained. This requirement for backwards + compatibility precludes making significant protocol changes. So, + this document limits changes to the addition of support for an + additional family of cryptographic algorithms. The original + specification has been very widely implemented, is known to be widely + interoperable, and is also widely deployed. + + The authors do NOT believe that this specification is the final + answer to RIPv2 authentication and encourage the reader to consult + the Security Considerations section of this document for more + details. + + If RIPv2 authentication is disabled, then only simple + misconfigurations are detected. The original RIPv2 authentication + mechanism relied upon reused cleartext passwords. Use of cleartext + password authentication can protect against accidental + misconfigurations if that were the only concern, but is not helpful + from a security perspective. By simply capturing information on the + wire -- straightforward even in a remote environment -- a hostile + + + + + +Atkinson & Fanto Standards Track [Page 2] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + + entity can read the cleartext RIPv2 password and use that knowledge + to inject false information into the routing system via the RIPv2 + routing protocol. + + This mechanism is intended to reduce the risk of a successful passive + attack upon RIPv2 deployments. That is, deployment of this mechanism + greatly reduces the vulnerability of the RIPv2-based routing system + from a passive attack. When cryptographic authentication is enabled, + we transmit the output of a keyed cryptographic one-way function in + the authentication field of the RIPv2 packet, instead of sending a + cleartext reusable password in the RIPv2 packet. The RIPv2 + Authentication Key is known only to the authorized parties of the + RIPv2 session. The RIPv2 Authentication Key is never sent over the + network in the clear. + + In this way, protection is afforded against forgery or message + modification. While it is possible to replay a message until the + sequence number changes, a sequence number can be used to reduce + replay risks. The mechanism does not provide confidentiality, since + messages stay in the clear. Since the objective of a routing + protocol is to advertise the routing topology, confidentiality is not + normally required for routing protocols. + + Other relevant rationales for the approach are that MD5 and SHA-1 are + both being used for other purposes and are therefore generally + already present in IP routers, as is some form of password + management. + +1.1. Terminology + + In this document, the words "MUST", "MUST NOT", "REQUIRED", "SHALL", + "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT + RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as + described in [BCP14] and indicate requirement levels for compliant or + conformant implementations. + +2. Implementation Approach + + Implementation requires use of a special packet format, special + authentication procedures, and also management controls. + Implementers need to remember that the Security Considerations + section is an integral part of this specification and contains + important parts of this specification. + + + + + + + + +Atkinson & Fanto Standards Track [Page 3] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + +2.1. RIPv2 PDU Format + + The basic RIPv2 message format provides for an 8-octet header with an + array of 20-octet records as its data content. When RIPv2 + Cryptographic Authentication is enabled, the same header and content + are used as with the original RIPv2 specification, but the 16-octet + "Authentication" password field of the original RIPv2 specification + is reused to contain a packet offset to the Authentication Data, a + Key Identifier, the Authentication Data Length, and a non-decreasing + sequence number. + + AUTHENTICATION TYPE + The "Authentication Type" is Cryptographic Hash Function, which + is indicated by the value 3. + + RIPv2 PACKET LENGTH + An unsigned 16-bit offset from the start of the RIPv2 header to + the end of the regular RIPv2 packet (not including the + authentication trailer). + + KEY IDENTIFIER + An unsigned 8-bit field that contains the Key Identifier or + Key-ID. This, in combination with the network interface, + identifies the RIPv2 Security Association in use for this + packet. The RIPv2 Security Association, which is defined in + Section 2.2 below, includes the Authentication Key that was + used to create the Authentication Data for this RIPv2 message + and other parameters. In implementations supporting more than + one authentication algorithm, the RIPv2 Security Association + also includes information about which authentication algorithm + is in use for this message. A RIPv2 Security Association is + always associated with an interface, rather than with a router. + The actual cryptographic key is part of the RIPv2 Security + Association. + + AUTHENTICATION DATA LENGTH + An unsigned 8-bit field that contains the length in octets of + the trailing Authentication Data field. The presence of this + field helps provide cryptographic algorithm independence. + + AUTHENTICATION DATA + This field contains the cryptographic Authentication Data used + to validate this packet. The length of this field is stored in + the AUTHENTICATION DATA LENGTH field above. + + + + + + + +Atkinson & Fanto Standards Track [Page 4] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + + SEQUENCE NUMBER + An unsigned 32-bit sequence number. The sequence number MUST + be non-decreasing for all messages sent from a given source + router with a given Key ID value. + + The authentication trailer contains the Authentication Data, which is + the output of the keyed cryptographic hash function. See later + subsections of this section for details on computing this field. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +---------------+---------------+-------------------------------+ + | Command (1) | Version (1) | Routing Domain (2) | + +---------------+---------------+-------------------------------+ + | 0xFFFF | Authentication Type=0x0003 | + +---------------+---------------+---------------+---------------+ + | RIPv2 Packet Length | Key ID | Auth Data Len | + +---------------+---------------+---------------+---------------+ + | Sequence Number (non-decreasing) | + +---------------+---------------+---------------+---------------+ + | reserved must be zero | + +---------------+---------------+---------------+---------------+ + | reserved must be zero | + +---------------+---------------+---------------+---------------+ + | | + ~ (RIPv2 Packet Length - 24) bytes of Data ~ + | | + +---------------+---------------+---------------+---------------+ + | 0xFFFF | 0x0001 | + +---------------+---------------+---------------+---------------+ + | Authentication Data (variable length; 20 bytes with HMAC-SHA1)| + +---------------+---------------+---------------+---------------+ + +2.2. RIPv2 Security Association + + Understanding the RIPv2 Security Association concept is central to + understanding this specification. A RIPv2 Security Association + contains the set of shared authentication configuration parameters + needed by the legitimate sender or any legitimate receiver. + + An implementation MUST be able to support at least 2 concurrent RIPv2 + Security Associations on each RIP interface. This is a functional + requirement for supporting key rollover. Support for key rollover is + mandatory. + + The RIPv2 Security Association, defined below, is selected by the + sender based on the outgoing router interface. Each RIPv2 Security + Association has a lifetime and other configuration parameters + + + +Atkinson & Fanto Standards Track [Page 5] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + + associated with it. In normal operation, a RIPv2 Security + Association is never used outside its lifetime. Certain abnormal + cases are discussed later in this document. + + The minimum data items in a RIPv2 Security Association are as + follows: + + KEY-IDENTIFIER (KEY-ID) + The unsigned 8-bit KEY-ID value is used to identify the RIPv2 + Security Association in use for this packet. + + The receiver uses the combination of the interface the packet + was received upon and the KEY-ID value to uniquely identify the + appropriate Security Association. + + The sender selects which RIPv2 Security Association to use + based on the outbound interface for this RIPv2 packet and then + places the correct KEY-ID value into that packet. If multiple + valid and active RIPv2 Security Associations exist for a given + outbound interface at the time a RIPv2 packet is sent, the + sender may use any of those security associations to protect + the packet. + + AUTHENTICATION ALGORITHM + This specifies the cryptographic algorithm and algorithm mode + used with the RIPv2 Security Association. This information is + never sent in cleartext over the wire. Because this + information is not sent on the wire, the implementer chooses an + implementation specific representation for this information. + At present, the following values are possible: KEYED-MD5, + HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. + + AUTHENTICATION KEY + This is the value of the cryptographic authentication key used + with the associated Authentication Algorithm. It MUST NOT ever + be sent over the network in cleartext via any protocol. The + length of this key will depend on the Authentication Algorithm + in use. Operators should take care to select unpredictable and + strong keys, avoiding any keys known to be weak for the + algorithm in use. [ESC05] contains helpful information on both + key generation techniques and cryptographic randomness. + + + + + + + + + + +Atkinson & Fanto Standards Track [Page 6] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + + SEQUENCE NUMBER + This is an unsigned 32-bit number. For a given KEY-ID value + and sender, this number MUST NOT decrease. In normal + operation, the operator should rekey the RIPv2 session prior to + reaching the maximum value. The initial value used in the + sequence number is arbitrary. Receivers SHOULD keep track of + the most recent sequence number received from a given sender. + + START TIME + This is a local representation of the day and time that this + Security Association first becomes valid. + + STOP TIME + This is a local representation of the day and time that this + Security Association becomes invalid (i.e., when it expires). + It is permitted, but not recommended, for an operator to + configure this to "never expire". The "never expire" value is + not recommended operational practice because it reduces + security as compared with periodic rekeying. Normally, a RIPv2 + Security Association is deleted at its STOP TIME. However, + there are certain pathological cases, which are discussed in + Section 5.1. + + The authentication trailer consists of the Authentication Data, which + is the output of the keyed cryptographic hash function. See later + subsections of this section for details on computing this field. + +2.3. Basic Authentication Processing + + When the authentication type is "Cryptographic Hash Function", + message processing is changed in message creation and reception as + compared with the original RIPv2 specification in [Mal94]. + + This section describes the message processing generically. + Additional algorithm-dependent processing that is required is + described in separate, subsequent sections of this document. As of + this writing, there are 2 kinds of algorithm-dependent processing. + One covers the "Keyed-MD5" algorithm. The other covers the + "HMAC-SHA1" family of algorithms. + +2.3.1. Message Generation + + The RIPv2 Packet is created as usual, with these exceptions: + + (1) The UDP checksum SHOULD be calculated, but MAY be set to zero + because any of the cryptographic authentication mechanisms in + this specification will provide stronger integrity protection + than the standard UDP checksum. + + + +Atkinson & Fanto Standards Track [Page 7] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + + (2) The Authentication Type field indicates Cryptographic + Authentication (3). + + (3) The Authentication "password" field is reused to store a packet + offset to the Authentication Data, a Key Identifier, the + Authentication Data Length, and a non-decreasing sequence number. + + See also Section 2.2 above on RIPv2 Security Association for other + important background information. + + When creating the RIPv2 Packet, the following process is followed: + + (1) The Packet Length field of the RIPv2 header indicates the size of + the main body of the RIPv2 packet. + + (2) An appropriate RIPv2 Security Association is selected for use + with this packet, based on the outbound interface for the packet. + Any valid RIPv2 Security Association for that outbound interface + may be used. The Authentication Data Offset, Key Identifier, and + Authentication Data Length fields are filled in appropriately. + + (3) Algorithm-dependent processing occurs now, either for the + "Keyed-MD5" algorithm or for the "HMAC-SHA1" algorithm family. + See the respective sub-sections (below) for details of this + algorithm-dependent processing. + + (4) The resulting Authentication Data value is written into the + Authentication Data field. The trailing pad (if any) is not + actually transmitted, as it is entirely predictable from the + message length and Authentication Algorithm in use. + +2.3.2. Message Reception + + When the message is received, the process is reversed: + + (1) The received Authentication Data is set aside and stored for + later use, + + (2) The appropriate RIPv2 Security Association is determined from the + value of the Key Identifier field and the interface the packet + was received on. If there is no valid RIPv2 Security Association + for the received Key Identifier on the interface that the packet + was received on, then: + + (a) all processing of the incoming packet ceases, and + + (b) a security event SHOULD be logged by the RIPv2 subsystem of + the receiving system. That security event should indicate at + + + +Atkinson & Fanto Standards Track [Page 8] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + + least the day/time that the bad packet was received, the + Source IP Address of the received RIPv2 packet, the Key-ID + field value, the interface the bad packet arrived upon, and + the fact that no valid RIPv2 Security Association was found + for that interface and Key-ID combination. + + (3) Algorithm-dependent processing is performed, using the algorithm + specified by the appropriate RIPv2 Security Association for this + packet. This results in calculation of the Authentication Data + based on the information in the received RIPv2 packet and + information from the appropriate RIPv2 Security Association for + that packet. + + (4) The calculated Authentication Data result is compared with the + received Authentication Data. + + (5) If the calculated authentication data result does not match the + received Authentication Data field, then: + + (a) the message MUST be discarded without being processed, and + + (b) a security event SHOULD be logged by the RIPv2 subsystem of + the receiving system. That security event SHOULD indicate at + least the day/time that the bad packet was received, the + Source IP Address of the received RIPv2 packet, the Key-ID + field value, the interface the bad packet arrived upon, and + the fact that RIPv2 Authentication failed upon receipt of the + packet. + + (6) If the neighbor has been heard from recently enough to have + viable routes in the local routing table, and the received + sequence number is less than the last sequence number received, + then the message MUST be discarded unprocessed. If the received + sequence number is less than the last sequence number received, + that fact SHOULD be logged as a security event. This logged + security event SHOULD indicate at least the day/time that the bad + packet was received, the Source IP Address of the received RIPv2 + packet, the Key-ID field value, and the fact that an out-of-order + RIPv2 sequence number was received. + + When connectivity to the neighbor has been lost, the receiver + SHOULD be ready to accept either: + + - a message with a sequence number of zero. + + - a message with a higher sequence number than the last + received sequence number. + + + + +Atkinson & Fanto Standards Track [Page 9] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + + (7) Acceptable messages are now truncated to the RIPv2 message + itself, minus the authentication trailer, and are processed + normally (i.e., in accordance with the RIPv2 base specification + in RFC 2453 [Mal98]). The last received sequence number for this + RIPv2 Security Association and sender is also updated. + + NOTA BENE: A router that has forgotten its current sequence number + but remembers its Security Association MUST send its first packet + with a sequence number of zero. This leaves a small opening for a + replay attack. To reduce the risk of such attacks by precluding the + situation where a router has forgotten its current sequence number, + implementers SHOULD provide non-volatile storage for all components + of a RIPv2 Security Association, and receiving systems SHOULD provide + non-volatile storage for the last received sequence number from each + sender. See also the Security Considerations section of this + document. + +2.4. Keyed-MD5 Algorithm-Dependent Processing + + This section describes the algorithm-dependent processing steps + applicable when the "Keyed-MD5" authentication algorithm is in use. + The RIPv2 Authentication Key is always 16 octets when "Keyed-MD5" is + in use. + + (1) The RIPv2 Authentication Key is appended to the RIPv2 packet in + memory. + + (2) The Trailing Pad for MD5 and message length fields are added in + memory. The diagram below shows how these additions appear when + appended in memory: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Authentication Key | + / (16 octets long) / + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | zero or more pad octets (as defined by RFC 1321) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 64-bit message length MSW | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 64-bit message length LSW | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + (3) The Authentication Data is then calculated according to the MD5 + algorithm defined by RFC 1321 [Rivest92]. + + + + + + +Atkinson & Fanto Standards Track [Page 10] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + +2.5. HMAC-SHA1 Algorithm-Dependent Processing + + This section describes the processing steps for HMAC Authentication. + While HMAC was originally documented in [KMC97], for this + specification, the terminology used in [FIPS-198] is used. While the + current specification only provides full details for HMAC + Authentication using the National Institute of Standards and + Technology (NIST) SHA-1 algorithm (and its direct derivatives), this + same basic process could be used with other cryptographic hash + functions in the future. Because the RIPv2 packet is only hashed + once, the overhead of the double hashing in this process is + negligible. + + The US NIST Secure Hash Standard (SHS), defined by [FIPS-180-2], + includes specifications for SHA-1, SHA-256, SHA-384, and SHA-512. + This specification defines processing for each of these. + + The output of the cryptographic computations (e.g., HMAC-SHA1) is NOT + truncated for RIPv2 Cryptographic Authentication. + + The Authentication Data Length is equal to the Message Digest Size + for the hash algorithm in use. + + Any key value known to be weak with an algorithm defined by the NIST + Secure Hash Standard MUST NOT be used with such an algorithm in an + implementation of this specification. US NIST is the authoritative + source for public information on weak keys for those algorithms. + + In the algorithm description below, the following nomenclature, which + is consistent with [FIPS-198], is used: + + H is the specific hashing algorithm, + for example, SHA-1 or SHA-256. + Ko is the cryptographic key used with the hash algorithm. + B is the block-size of H, measured in octets, not bits. + Note that B is the internal block size, not the hash size. + For SHA-1 and SHA-256: B == 64. + For SHA-384 and SHA-512: B == 128 + L is the length of the hash, measured in octets, not bits. + For example, with SHA-1, L == 20. + XOR is the exclusive-or operation. + Opad is the hexadecimal value 0x5c repeated B times. + Ipad is the hexadecimal value 0x36 repeated B times. + Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times. + + + + + + + +Atkinson & Fanto Standards Track [Page 11] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + + (1) PREPARATION OF KEY + In this application, Ko is always L octets long. + + If the Authentication Key is L octets long, then Ko is set equal + to the Authentication Key. If the Authentication Key is more + than L octets long, then Ko is set to H(Authentication Key). If + the Authentication Key is less than L octets long, then Ko is set + to the Authentication Key with zeros appended to the end of the + Authentication Key such that Ko is L octets long. + + (2) FIRST HASH + First, the RIPv2 packet's Authentication Data field is filled + with the value Apad. + + Then, a first hash, also known as the inner hash, is computed as + follows: + First-Hash = H(Ko XOR Ipad || (RIPv2 Packet)) + + (3) SECOND HASH + Then a second hash, also known as the outer hash, is computed as + follows: + Second-Hash = H(Ko XOR Opad || First-Hash) + + (4) RESULT + The result Second-Hash becomes the authentication data that is + sent in the Authentication Data field of the RIPv2 packet. The + length of the Authentication Data field is always identical to + the message digest size of the hash function H that is being + used. + + This also implies that use of hash functions with larger output + sizes will also increase the size of the packet as transmitted on + the wire. + +3. Management Procedures + + Key management is an important component of this mechanism and proper + implementation is central to providing the intended level of risk + reduction. + +3.1. Key Management Requirements + + It is strongly desirable that a hypothetical security breach in one + Internet protocol not automatically compromise other Internet + protocols. The Authentication Key of this specification SHOULD NOT + be configured or stored using protocols (e.g., RADIUS) or + cryptographic algorithms that have known flaws. + + + + +Atkinson & Fanto Standards Track [Page 12] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + + Implementations MUST support the storage of more than one key at the + same time, although it is recognized that only one key will normally + be active on an interface. Implementations MUST associate a specific + Security Association lifetime (i.e., date/time first valid and + date/time no longer valid) and a key identifier with each key. + Implementations also MUST support manual key distribution. An + example of manual key distribution is having the privileged user + typing in the key, key lifetime, and key identifier on the router + console. An operator may configure the Security Association lifetime + to infinite, which means that the session is never rekeyed. However, + instead, it is strongly recommended that operators rekey regularly, + using a moderately short Security Association lifetime (e.g., 24 + hours). + + This specification requires support for at least two authentication + algorithms, so the implementation MUST require that the + authentication algorithm be specified for each key when the other key + information is entered. Manual deletion of active Security + Associations MUST be supported. + + It is likely that the IETF will define a standard key management + protocol for use with routing protocols. It is strongly desirable to + use an IETF standards-track key management protocol to distribute + RIPv2 Authentication Keys among communicating RIPv2 implementations. + Such a protocol would provide scalability and significantly reduce + the human administrative burden. The Key-ID field can be used as a + hook between RIPv2 and such a future protocol. + + Key management protocols have a long history of subtle flaws that are + often discovered long after the protocol was first described in + public. To avoid having to change all RIPv2 implementations should + such a flaw be discovered, integrated key management protocol + techniques were deliberately omitted from this specification. + +3.2. Key Management Procedures + + As with all security methods using keys, it is necessary to change + the RIPv2 Authentication Key on a regular basis. To maintain routing + stability during such changes, implementations MUST be able to store + and use more than one RIPv2 Authentication Key on a given interface + at the same time. + + Each key will have its own Key Identifier (KEY-ID), which is stored + locally. The combination of the Key Identifier and the interface + associated with the message uniquely identifies the Authentication + Algorithm and RIPv2 Authentication Key in use. + + + + + +Atkinson & Fanto Standards Track [Page 13] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + + As noted above in Section 2.3.1, the party creating the RIPv2 message + will select a valid RIPv2 Security Association from the set of valid + RIPv2 Security Associations for that interface. The receiver MUST + use the Key Identifier and receiving interface to determine which + RIPv2 Security Association to use for authentication of the received + message. More than one RIPv2 Security Association MAY be associated + with an interface at the same time. The receiver MUST NOT simply try + all RIPv2 Security Associations (i.e., keys) that might be configured + for RIPv2 on the receiving interface, as that creates an easily + exploited denial-of-service attack on the RIP subsystem of the + receiver. (At least one widely used implementation of the previous + version of this specification violates these requirements as of the + publication date of this document and has consequent security + vulnerabilities.) + + Hence, it is possible to have fairly smooth RIPv2 Security + Association (i.e., key) rollovers, without losing legitimate RIPv2 + messages due to an invalid shared key and without requiring people to + change all the keys at once. To ensure a smooth rollover, each + communicating RIPv2 system must be updated with the new RIPv2 + Security Association (including the new key) several minutes before + the current RIPv2 Security Association will expire and several + minutes before the new RIPv2 Security Association lifetime begins. + Also, the new RIPv2 Security Association should have a lifetime that + starts several minutes before the old RIPv2 Security Association + expires. This gives time for each system to learn of the new + security association before that security association will be used. + It also ensures that the new security association will begin use and + the current security association will go out of use before the + current security association's lifetime expires. For the duration of + the overlap in security association lifetimes, a system may receive + messages corresponding to either security association and + successfully authenticate the message. The Key-ID in the received + message is used to select the appropriate security association (i.e., + key) to be used for authentication. + +4. Conformance Requirements + + For this specification, the term "conformance" has identical meaning + to the phrase "full compliance". + + The Keyed MD5 authentication algorithm and the HMAC-SHA1 algorithm + MUST be implemented by all conforming implementations. In addition, + the HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 algorithms SHOULD be + implemented. MD5 is defined in [Rivest92]. SHA-1, SHA-256, SHA-384, + and SHA-512 have been defined by the US NIST in [FIPS-180-2]. + + + + + +Atkinson & Fanto Standards Track [Page 14] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + + A conforming implementation MAY also support additional + authentication algorithms, provided those additional algorithms are + publicly and openly specified. + + Manual key distribution as described above MUST be supported by all + conforming implementations. All implementations MUST support the + smooth key rollover described under "Key Management Procedures". + This also means that implementations MUST support at least 2 + concurrent RIPv2 Security Associations. + + The user documentation provided with the implementation ought to + contain clear instructions on how to configure the implementation + such that smooth key rollover occurs successfully. + + Implementations SHOULD support a standard key management protocol for + secure distribution of RIPv2 Authentication Keys once such a key + management protocol is standardized by the IETF. + + The Security Considerations section of this document is an integral + part of the specification, not just a discussion of the protocol. + +5. Security Considerations + + This entire memo describes and specifies an authentication mechanism + for the RIPv2 routing protocol that is believed to be secure against + passive attacks. The term "passive attack" is defined in RFC 1704 + [HA94]. The analysis contained in RFC 1704 motivated this work. + Passive attacks are clearly widespread in the Internet at present + [HA94]. + + Protection against active attacks is incomplete in this current + specification. The main issue relative to active attacks lies in the + need to support the case where another router has recently rebooted + and that router lacks the non-volatile storage needed to remember the + RIPv2 Security Association(s) and last received RIPv2 sequence + number(s) across that reboot. + +5.1. Known Pathological Cases + + Two known pathological cases exist that MUST be handled by + implementations. Both of these are failures of the network manager. + Each of these should be exceedingly rare in normal operation. + + (1) During key rollover, devices might exist that have not yet been + successfully configured with the new key. Therefore, routers + SHOULD implement an algorithm that detects the set of RIPv2 + Security Associations being used by its neighbors, and transmit + its messages using both the new and old RIPv2 Security + + + +Atkinson & Fanto Standards Track [Page 15] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + + Associations (i.e., keys) until all of the neighbors are using + the new security association or the lifetime of the old security + association expires. Under normal circumstances, this elevated + transmission rate will exist for a single RIP update interval. + + (2) In the event that the last RIPv2 Security Association of an + interface expires, it is unacceptable to revert to an + unauthenticated condition, and not advisable to disrupt routing. + Therefore, the router MUST send a "last RIPv2 Security + Association expiration" notification to the network manager + (e.g., via SYSLOG, SNMP, and/or other means) and SHOULD treat + that last Security Association as having an infinite lifetime + until the lifetime is extended, the Security Association is + deleted by network management, or a new security association is + configured. + + In some circumstances, the practice described in (2) can leave an + opening to an active attack on the RIPv2 routing subsystem. + Therefore, any actual occurrence of a RIPv2 Security Association + expiration MUST cause a security event to be logged by the + implementation. This log item MUST include at least a note that the + RIPv2 Authentication Key expired, the RIP routing protocol + instance(s) affected, the routing interfaces affected, the Key-ID + that is affected, and the current date/time. Operators are + encouraged to check such logs as an operational security practice to + help detect active attacks on the RIPv2 routing subsystem. Further, + implementations SHOULD provide a configuration knob ("fail secure") + to let a network operator prefer to have the RIPv2 routing fail when + the last key expires, rather than continue using RIPv2 in an insecure + manner. + +5.2 Network Management Considerations + + Also, the use of SNMP, even SNMPv3 with cryptographic authentication + and cryptographic confidentiality enabled, to modify or configure the + RIPv2 Security Associations, or any component of the security + association (for example, the cryptographic key), is NOT RECOMMENDED. + This practice would create a potential for a cascading vulnerability, + whereby a compromise in the SNMP security implementation would + necessarily lead to a compromise not only of the local routing table + (which could be accessed via SNMP) but also of all other routers that + receive RIPv2 packets (directly or indirectly) from the compromised + router. + + + + + + + + +Atkinson & Fanto Standards Track [Page 16] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + + Similarly, the use of protocols not designed and evaluated for use in + key management (e.g., RADIUS, Diameter) to configure the security + association is also NOT RECOMMENDED. Reading the Security + Associations via SNMP is allowed, but the information is to be + treated as security-sensitive and protected by using the priv mode. + + Also, the use of SNMP to configure which form of RIPv2 authentication + is in use is also NOT RECOMMENDED because of a similar cascading + failure issue. Any future revision of the RIPv2 Management + Information Base (MIB) [MB94] should consider making the + rip2IfConfAuthType object read-only. Further, this object would need + a new enum value to accommodate the RIPv2 cryptographic + authentication type. In addition, the compliance statement for this + MIB does not have a MIN-ACCESS for this object. At a minimum, if the + MIB is updated, a new compliance statement SHOULD be written for this + object that allows this object to be implemented as read-only. For + the rip2ifConfAuthKey object, since this object always returns ''H + when read, the object's MIN-ACCESS in any revised compliance + statement SHOULD be not-accessible if the MIB is updated. + + Further, for similar reasons, any future revisions to the RIPv2 + Management Information Base (MIB) SHOULD deprecate or omit any + objects that would permit the writing of any RIPv2 Security + Association or RIPv2 Security Association component (e.g., the + cryptographic key). + + Also, it is RECOMMENDED that any future revisions to the RIPv2 + Management Information Base (MIB) consider adding MIB objects to hold + information about any RIPv2 security events that might have occurred, + and MIB objects that could be used to read the set of security events + that have been logged by the RIPv2 subsystem. For each security + event mentioned in this document, it is also RECOMMENDED that + appropriate notifications be included, with a MAX-ACCESS of + Accessible-for-notify, in any future versions of the RIPv2 MIB + module. + +5.3. Key Management Considerations + + For the past several years, manual configuration (e.g., via a + console) has been commonly used to create and modify RIPv2 Security + Associations. There are a number of large-scale RIP deployments + today that successfully use manual configuration of RIPv2 Security + Associations. There are also sites that use scripts (e.g., combining + Tcl/Expect, PERL, and SSHv2) with a site-specific configuration + database and secure console connections to dynamically manage all + aspects of their router configurations, including their RIPv2 + Security Associations. This last approach is similar to the current + IETF approach to Network Configuration (NetConf) standards. + + + +Atkinson & Fanto Standards Track [Page 17] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + + Recent IETF Multicast Security (MSEC) working group efforts into + multicast key management appear promising. Several large RIPv2 + deployments happen to also have deployed the Kerberos authentication + system. Recent IETF work into the use of Kerberos for Internet Key + Negotiation (KINK) also seems relevant; one might use Kerberos to + support RIPv2 key management functions for use at sites that have + already deployed Kerberos. It is hoped that in the future the IETF + will standardize a key management protocol suitable for managing + RIPv2 Security Associations. + +5.4. Assurance Considerations + + Users need to understand that the quality of the security provided by + this mechanism depends completely on the strength of the implemented + authentication algorithms, the strength of the key being used, and + the correct implementation of the security mechanism in all + communicating RIPv2 implementations. This mechanism also depends on + the RIPv2 Authentication Key being kept confidential by all parties. + If any of these are incorrect or insufficiently secure, then no real + security will be provided to the users of this mechanism. + + Use of high-assurance development methods is RECOMMENDED for + implementations of this specification, in order to reduce the risk of + subtle implementation flaws that might adversely impact the + operational risk reduction that this specification seeks to provide. + +5.5. Confidentiality and Traffic Analysis Considerations + + Confidentiality is not provided by this mechanism. It is generally + considered that an IP routing protocol does not require + confidentiality, as the purpose of any routing protocols is to + disseminate information about the topology of the network. + + Protection against traffic analysis is also not provided. Mechanisms + such as bulk link encryption SHOULD be used when protection against + traffic analysis is required [CKHD89]. + +5.6. Other Security Considerations + + Separately, the receipt of a RIPv2 packet using cryptographic + authentication but containing an invalid or unknown Key-ID value + might indicate an active attack on the RIP routing subsystem and is a + significant security event. Therefore, any actual receipt of a RIPv2 + packet using cryptographic authentication and containing an unknown, + expired, or otherwise invalid KEY-ID value SHOULD cause a security + event to be logged by the implementation. This log item SHOULD + include at least the fact that the invalid KEY-ID was received, the + source IP address of the packet containing the invalid KEY-ID, the + + + +Atkinson & Fanto Standards Track [Page 18] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + + interface(s) the packet was received on, the KEY-ID received, and the + current date/time. + + A subtle user-interface consideration also should be noted. If a + user interface only permits the entry of human-readable text (e.g., a + password in US-ASCII format) for use as a cryptographic key, + significant numbers of bits of the cryptographic key in use become + predictable, thereby reducing the strength of the key in this + context. For this reason, implementations of this specification + SHOULD support the entry of RIPv2 cryptographic authentication keys + in hexadecimal format. + +5.7. Future Security Directions + + Specification and deployment of a standards-track key management + protocol that supports this RIPv2 cryptographic authentication + mechanism would be a significant next step in operational risk + reduction and might actually increase the ease of deployment and + operation of this mechanism. Such specification is beyond the scope + of this document. Recent IETF work in MSEC and KINK working groups + appears promising in this regard. Recent IETF work in the NETCONF + working group towards standardizing methods for secure configuration + management of routers is also relevant. + + Finally, we observe that this mechanism is not the final word on + RIPv2 authentication. Rather, it is believed that this particular + mechanism represents a significant risk reduction over previous + methods (e.g., plaintext passwords), while remaining straightforward + to implement correctly and also straightforward to deploy. + + User communities that believe this mechanism is not adequate to their + needs are encouraged to consider using digital signatures with RIPv2. + [MBW97] specifies the use of OSPF with Digital signatures; that + document might be a starting point for creating such a specification + for the RIPv2 protocol. Digital signatures are significantly more + expensive computationally and are also significantly more difficult + to deploy operationally, as compared with the mechanism specified + here. However, it appears likely that much of the mechanism in this + document could be reused with digital signatures. + +6. Acknowledgments + + Fred Baker was co-author of the earlier RIPv2 MD5 Authentication + document [AB97]. This document is a direct derivative of that + earlier document, though it has been significantly reworked. The + current authors would like to thank Bill Burr, Tim Polk, John Kelsey, + and Morris Dworkin of (US) NIST for review of versions of this + document. + + + +Atkinson & Fanto Standards Track [Page 19] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + +7. Normative References + + [BCP14] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [Mal98] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November + 1998. + + [FIPS-180-2] National Institute of Standards and Technology, "Secure + Hash Standard", FIPS PUB 180-2, August 2002, + <http://csrc.nist.gov/publications/fips/fips180-2/ + fips180-2.pdf>. + + [FIPS-198] National Institute of Standards and Technology, "The + Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB + 198, March 2002, <http://csrc.nist.gov/publications/ + fips/fips198/fips-198a.pdf>. + +8. Informative References + + [AB97] Baker, F. and R. Atkinson, "RIP-2 MD5 Authentication", + RFC 2082, January 1997. + + [Bell89] S. Bellovin, "Security Problems in the TCP/IP Protocol + Suite", ACM Computer Communications Review, Volume 19, + Number 2, pp. 32-48, April 1989. + + [CKHD89] Cole Jr, Raymond, Donald Kallgren, Richard Hale, and + John R. Davis, "Multilevel Secure Mixed-Media + Communication Networks", Proceedings of the IEEE + Military Communications Conference (MILCOM '89), IEEE, + 1989. + + [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", + Technical Report, 2 May 1996. (Presented at Rump + Session of EuroCrypt 1996.) + + [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent + Attack", CryptoBytes, Vol. 2, No. 2, Summer 1996. + + [ESC05] Eastlake, D., 3rd, Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC + 4086, June 2005. + + [HA94] Haller, N. and R. Atkinson, "On Internet + Authentication", RFC 1704, October 1994. + + + + + +Atkinson & Fanto Standards Track [Page 20] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + + [KMC97] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [Mal94] Malkin, G., "RIP Version 2 - Carrying Additional + Information", RFC 1723, November 1994. + + [MB94] Malkin, G. and F. Baker, "RIP Version 2 MIB Extension", + RFC 1724, November 1994. + + [MBW97] Murphy, S., Badger, M., and B. Wellington, "OSPF with + Digital Signatures", RFC 2154, June 1997. + + [Rivest92] Rivest, R., "The MD5 Message-Digest Algorithm", RFC + 1321, April 1992. + +Authors' Addresses + + R. Atkinson + Extreme Networks + 3585 Monroe Street + Santa Clara, CA 95051 + USA + + Phone: +1 (408) 579-2800 + EMail: rja@extremenetworks.com + + + M. Fanto + (US) National Institute of Standards and Technology + Gaithersburg, MD 20878 + USA + + Phone: +1 (301) 975-2000 + EMail: mattjf@umd.edu + Web: http://csrc.nist.gov + + + + + + + + + + + + + + + +Atkinson & Fanto Standards Track [Page 21] + +RFC 4822 RIPv2 Cryptographic Authentication February 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Atkinson & Fanto Standards Track [Page 22] + |