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