draft-ietf-ripv2-md5-03.txt   rfc2082.txt 
DRAFT RIP-II MD5 Authentication February 1995 Network Working Group F. Baker
Request for Comments: 2082 R. Atkinson
RIP-II MD5 Authentication Category: Standards Track Cisco Systems
draft-ietf-ripv2-md5-03.txt January 1997
Fri Feb 23 16:23:57 PST 1996
Fred Baker
Cisco Systems
fred@cisco.com
Randall Atkinson
cisco Systems
rja@cisco.com
Status of this Memo RIP-2 MD5 Authentication
This document is an Internet Draft. Internet Drafts are working Status of this Memo
documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working
documents as Internet Drafts.
Internet Drafts are valid for a maximum of six months and may be This document specifies an Internet standards track protocol for the
updated, replaced, or obsoleted by other documents at any time. It is Internet community, and requests discussion and suggestions for
inappropriate to use Internet Drafts as reference material or to cite improvements. Please refer to the current edition of the "Internet
them other than as a "work in progress". Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
DRAFT RIP-II MD5 Authentication February 1995 Table of Contents
1. Introduction 1 Use of Imperatives ........................................... 1
2 Introduction ................................................. 2
3 Implementation Approach ...................................... 3
3.1 RIP-2 PDU Format ........................................... 3
3.2 Processing Algorithm ....................................... 5
3.2.1 Message Generation ....................................... 6
3.2.2 Message Reception ........................................ 7
4 Management Procedures ........................................ 7
4.1 Key Management Requirements ................................ 7
4.2 Key Management Procedures .................................. 8
4.3 Pathological Cases ......................................... 9
5 Conformance Requirements ..................................... 9
6 Acknowledgments .............................................. 10
7 References ................................................... 10
8 Security Considerations ...................................... 11
9 Chairman's Address ........................................... 11
10 Authors' Addresses .......................................... 12
Growth in the Internet has made us aware of the need for improved 1. Use of Imperatives
authentication of routing information. RIP-II provides for
unauthenticated service (as in classical RIP), or password
authentication. Both are vulnerable to passive attacks currently
widespread in the Internet. Well-understood security issues exist in
routing protocols [4]. Clear text passwords, currently specified for
use with RIP-II, are no longer considered sufficient [5].
If authentication is disabled, then only simple misconfigurations are Throughout this document, the words that are used to define the
detected. Simple passwords transmitted in the clear will further significance of particular requirements are capitalized. These words
protect against the honest neighbor, but are useless in the general are:
case. By simply capturing information on the wire - straightforward
even in a remote environment - a hostile process can learn the password
and overcome the network.
We propose that RIP-II use an authentication algorithm, as was MUST
originally proposed for SNMP Version 2, augmented by a sequence number.
Keyed MD5 is proposed as the standard authentication algorithm for RIP-
II, but the mechanism is intended to be algorithm-independent. While
this mechanism is not unbreakable (no known mechanism is), it provides a
greatly enhanced probability that a system being attacked will detect
and ignore hostile messages. This is because we transmit the output of
an authentication algorithm (e.g., Keyed MD5) rather than the secret
RIP-II Authentication Key. This output is a one-way function of a
message and a secret RIP-II Authentication Key. This RIP-II
Authentication Key is never sent over the network in the clear, thus
providing protection against the passive attacks now commonplace in the
Internet.
In this way, protection is afforded against forgery or message This word or the adjective "REQUIRED" means that the item is an
modification. It is possible to replay a message until the sequence absolute requirement of this specification.
number changes, but the sequence number makes replay in the long term
less of an issue. The mechanism does not afford confidentiality, since
messages stay in the clear; however, the mechanism is also exportable
from most countries, which test a privacy algorithm would fail.
Other relevant rationales for the approach are that Keyed MD5 is being MUST NOT
used for OSPF cryptographic authentication, and is therefore present in
routers already, as is some form of password management. A similar
approach has been standardised for use in IP-layer authentication. [7]
DRAFT RIP-II MD5 Authentication February 1995 This phrase means that the item is an absolute prohibition of this
specification.
2. Implementation Approach SHOULD
Implementation requires three issues to be addressed: This word or the adjective "RECOMMENDED" means that there may
exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and the case
carefully weighed before choosing a different course.
(1) A changed packet format, SHOULD NOT
(2) Authentication procedures, and This phrase means that there may exist valid reasons in particular
circumstances when the listed behavior is acceptable or even
useful, but the full implications should be understood and the
case carefully weighed before implementing any behavior described
with this label.
(3) Management controls. MAY
This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor may choose to include the item because
a particular marketplace requires it or because it enhances the
product, for example; another vendor may omit the same item.
2.1. RIP-II PDU Format 2. Introduction
The basic RIP-II message format provides for an 8 byte header with an Growth in the Internet has made us aware of the need for improved
array of 20 byte records as its data content. When Keyed MD5 is used, authentication of routing information. RIP-2 provides for
the same header and content are used, except that the 16 byte unauthenticated service (as in classical RIP), or password
"authentication key" field is reused to describe a "Keyed Message authentication. Both are vulnerable to passive attacks currently
Digest" trailer. This consists in five fields: widespread in the Internet. Well-understood security issues exist in
routing protocols [4]. Clear text passwords, currently specified for
use with RIP-2, are no longer considered sufficient [5].
(1) The "Authentication Type" is Keyed Message Digest Algorithm, If authentication is disabled, then only simple misconfigurations are
indicated by the value 3 (1 and 2 indicate "IP Route" and detected. Simple passwords transmitted in the clear will further
"Password", respectively). protect against the honest neighbor, but are useless in the general
case. By simply capturing information on the wire - straightforward
even in a remote environment - a hostile process can learn the
password and overcome the network.
(2) A 16 bit offset from the RIP-II header to the MD5 digest (if no We propose that RIP-2 use an authentication algorithm, as was
other trailer fields are ever defined, this value equals the RIP-II originally proposed for SNMP Version 2, augmented by a sequence
Data Length). number. Keyed MD5 is proposed as the standard authentication
algorithm for RIP-2, but the mechanism is intended to be algorithm-
independent. While this mechanism is not unbreakable (no known
mechanism is), it provides a greatly enhanced probability that a
system being attacked will detect and ignore hostile messages. This
is because we transmit the output of an authentication algorithm
(e.g., Keyed MD5) rather than the secret RIP-2 Authentication Key.
This output is a one-way function of a message and a secret RIP-2
Authentication Key. This RIP-2 Authentication Key is never sent over
the network in the clear, thus providing protection against the
passive attacks now commonplace in the Internet.
(3) An unsigned 8-bit field that contains the Key Identifier or Key-ID. In this way, protection is afforded against forgery or message
This identifies the key used to create the Authentication Data for modification. It is possible to replay a message until the sequence
this RIP-II message. In implementations supporting more than one number changes, but the sequence number makes replay in the long term
authentication algorithm, the Key-ID also indicates the less of an issue. The mechanism does not afford confidentiality,
authentication algorithm in use for this message. A key is since messages stay in the clear; however, the mechanism is also
associated with an interface. exportable from most countries, which test a privacy algorithm would
fail.
(4) An unsigned 8-bit field that contains the length in octets of the Other relevant rationales for the approach are that Keyed MD5 is
trailing Authentication Data field. The presence of this field being used for OSPF cryptographic authentication, and is therefore
permits other algorithms (e.g., Keyed SHA) to be substituted for present in routers already, as is some form of password management.
Keyed MD5 if desired. A similar approach has been standardized for use in IP-layer
authentication. [7]
(5) An unsigned 32 bit sequence number. The sequence number MUST be 3. Implementation Approach
non-decreasing for all messages sent with the same Key ID.
The trailer consists of the Authentication Data, which is the output of Implementation requires three issues to be addressed:
the Keyed Message Digest Algorithm. When the Authentication Algorithm
is Keyed MD5, the output data is 16 bytes; during digest calculation,
this is effectively followed by a pad field and a length field as
DRAFT RIP-II MD5 Authentication February 1995 (1) A changed packet format,
defined by RFC 1321. (2) Authentication procedures, and
DRAFT RIP-II MD5 Authentication February 1995 (3) Management controls.
2.2. Processing Algorithm 3.1. RIP-2 PDU Format
When the authentication type is "Keyed Message Digest", message The basic RIP-2 message format provides for an 8 byte header with an
processing is changed in message creation and reception. array of 20 byte records as its data content. When Keyed MD5 is
0 1 2 3 3 used, the same header and content are used, except that the 16 byte
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 "authentication key" field is reused to describe a "Keyed Message
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Digest" trailer. This consists in five fields:
| Command (1) | Version (1) | Routing Domain (2) |
+---------------+---------------+-------------------------------+
| 0xFFFF | AuType=Keyed Message Digest |
+-------------------------------+-------------------------------+
| RIP-II Packet Length | Key ID | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (non-decreasing) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved must be zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved must be zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ (RIP-II Packet Length - 24) bytes of Data /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xFFFF | 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Authentication Data (var. length; 16 bytes with Keyed MD5) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In memory, the following trailer is appended by the MD5 algorithm and (1) The "Authentication Type" is Keyed Message Digest Algorithm,
treated as though it were part of the message. indicated by the value 3 (1 and 2 indicate "IP Route" and
"Password", respectively).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (2) A 16 bit offset from the RIP-2 header to the MD5 digest (if no
| sixteen octets of MD5 "secret" | other trailer fields are ever defined, this value equals the
/ / RIP-2 Data Length).
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more pad bytes (defined by RFC 1321 when MD5 is used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 bit message length MSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 bit message length LSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DRAFT RIP-II MD5 Authentication February 1995 (3) An unsigned 8-bit field that contains the Key Identifier
or Key-ID. This identifies the key used to create the
Authentication Data for this RIP-2 message. In
implementations supporting more than one authentication
algorithm, the Key-ID also indicates the authentication
algorithm in use for this message. A key is associated with
an interface.
2.2.1. Message Generation (4) An unsigned 8-bit field that contains the length in octets of the
trailing Authentication Data field. The presence of this field
permits other algorithms (e.g., Keyed SHA) to be substituted for
Keyed MD5 if desired.
The RIP-II Packet is created as usual, with these exceptions: (5) An unsigned 32 bit sequence number. The sequence number MUST be
non-decreasing for all messages sent with the same Key ID.
(1) The UDP checksum need not be calculated, but MAY be set to zero. The trailer consists of the Authentication Data, which is the output
of the Keyed Message Digest Algorithm. When the Authentication
Algorithm is Keyed MD5, the output data is 16 bytes; during digest
calculation, this is effectively followed by a pad field and a length
field as defined by RFC 1321.
(2) The authentication type field indicates the Keyed Message Digest 3.2. Processing Algorithm
Algorithm (3).
(3) The authentication "password" field is reused to store a packet When the authentication type is "Keyed Message Digest", message
offset to the Authentication Data, a Key Identifier, the processing is changed in message creation and reception.
Authentication Data Length, and a non-decreasing sequence number.
The value used in the sequence number is arbitrary, but two suggestions 0 1 2 3 3
are the time of the message's creation or a simple message counter. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command (1) | Version (1) | Routing Domain (2) |
+---------------+---------------+-------------------------------+
| 0xFFFF | AuType=Keyed Message Digest |
+-------------------------------+-------------------------------+
| RIP-2 Packet Length | Key ID | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (non-decreasing) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved must be zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved must be zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ (RIP-2 Packet Length - 24) bytes of Data /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xFFFF | 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Authentication Data (var. length; 16 bytes with Keyed MD5) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RIP-II Authentication Key is selected by the sender based on the In memory, the following trailer is appended by the MD5 algorithm and
outgoing interface. Each key has a lifetime associated with it. No key treated as though it were part of the message.
is ever used outside its lifetime. Since the key's algorithm is related
to the key itself, stored in the sender and receiver along with it, the
Key ID effectively indicates which authentication algorithm is in use if
the implementation supports more than one authentication algorithm.
(1) The RIP-II header's packet length field indicates the standard +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RIP-II portion of the packet. | sixteen octets of MD5 "secret" |
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more pad bytes (defined by RFC 1321 when MD5 is used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 bit message length MSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 bit message length LSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(2) The Authentication Data Offset, Key Identifier, and Authentication 3.2.1. Message Generation
Data size fields are filled in appropriately.
(3) The RIP-II Authentication Key, which is 16 bytes long when the The RIP-2 Packet is created as usual, with these exceptions:
Keyed MD5 algorithm is used, is now appended to the data. For all
algorithms, the RIP-II Authentication Key is never longer than the
output of the algorithm in use.
(4) Trailing pad and length fields are added and the digest calculated (1) The UDP checksum need not be calculated, but MAY be set to
using the indicated algorithm. When Keyed MD5 is the algorithm in zero.
use, these are calculated per RFC 1321.
(5) The digest is written over the RIP-II Authentication Key. When MD5 (2) The authentication type field indicates the Keyed Message Digest
is used, this digest will be 16 bytes long. Algorithm (3).
The trailing pad is not actually transmitted, as it is entirely (3) The authentication "password" field is reused to store a packet
predictable from the message length and algorithm in use. offset to the Authentication Data, a Key Identifier, the
Authentication Data Length, and a non-decreasing sequence number.
DRAFT RIP-II MD5 Authentication February 1995 The value used in the sequence number is arbitrary, but two
suggestions are the time of the message's creation or a simple
message counter.
2.2.2. Message Reception The RIP-2 Authentication Key is selected by the sender based on the
outgoing interface. Each key has a lifetime associated with it. No
key is ever used outside its lifetime. Since the key's algorithm is
related to the key itself, stored in the sender and receiver along
with it, the Key ID effectively indicates which authentication
algorithm is in use if the implementation supports more than one
authentication algorithm.
When the message is received, the process is reversed: (1) The RIP-2 header's packet length field indicates the standard
RIP-2 portion of the packet.
(1) The digest is set aside, (2) The Authentication Data Offset, Key Identifier, and
Authentication Data size fields are filled in appropriately.
(2) The appropriate algorithm and key are determined from the value of (3) The RIP-2 Authentication Key, which is 16 bytes long when the
the Key Identifier field, Keyed MD5 algorithm is used, is now appended to the data. For
all algorithms, the RIP-2 Authentication Key is never longer than
the output of the algorithm in use.
(3) The RIP-II Authentication Key is written into the appropriate (4) Trailing pad and length fields are added and the digest
number (16 when Keyed MD5 is used) of bytes starting at the offset calculated using the indicated algorithm. When Keyed MD5 is the
indicated, algorithm in use, these are calculated per RFC 1321.
(4) Appropriate padding is added as needed, and (5) The digest is written over the RIP-2 Authentication Key. When
MD5 is used, this digest will be 16 bytes long.
(5) A new digest calculated using the indicated algorithm. The trailing pad is not actually transmitted, as it is entirely
predictable from the message length and algorithm in use.
If the calculated digest does not match the received digest, the message 3.2.2. Message Reception
is discarded unprocessed. If the neighbor has been heard from recently
enough to have viable routes in the route table and the received
sequence number is less than the last one received, the message likewise
is discarded unprocessed. When connectivity to the neighbor has been
lost, the receiver SHOULD be ready to accept either:
- a message with a sequence number of zero
- a message with a higher sequence number than the last received sequence
number.
A router that has forgotten its current sequence number but remembers When the message is received, the process is reversed:
its key and Key-ID MUST send its first packet with a sequence number of
zero. This leaves a small opening for a replay attack. Router vendors
are encouraged to provide stable storage for keys, key lifetimes, Key-
IDs, and the related sequence numbers.
Acceptable messages are now truncated to RIP-II message itself and (1) The digest is set aside,
treated normally.
3. Management Procedures (2) The appropriate algorithm and key are determined from the value
of the Key Identifier field,
3.1. Key Management Requirements (3) The RIP-2 Authentication Key is written into the appropriate
number (16 when Keyed MD5 is used) of bytes starting at the
offset indicated,
It is strongly desirable that a hypothetical security breach in one (4) Appropriate padding is added as needed, and
Internet protocol not automatically compromise other Internet protocols.
The Authentication Key of this specification SHOULD NOT be stored using
protocols or algorithms that have known flaws.
DRAFT RIP-II MD5 Authentication February 1995 (5) A new digest calculated using the indicated algorithm.
Implementations MUST support the storage of more than one key at the If the calculated digest does not match the received digest, the
same time, although it is recognized that only one key will normally be message is discarded unprocessed. If the neighbor has been heard
active on an interface. They MUST associate a specific lifetime (i.e., from recently enough to have viable routes in the route table and the
date/time first valid and date/time no longer valid) and a key received sequence number is less than the last one received, the
identifier with each key, and MUST support manual key distribution message likewise is discarded unprocessed. When connectivity to the
(e.g., the privileged user manually typing in the key, key lifetime, and neighbor has been lost, the receiver SHOULD be ready to accept
key identifier on the router console). The lifetime may be infinite. either:
If more than one algorithm is supported, then the implementation MUST - a message with a sequence number of zero
require that the algorithm be specified for each key at the time the - a message with a higher sequence number than the last received
other key information is entered. Keys that are out of date MAY be sequence number.
deleted at will by the implementation without requiring human
intervention. Manual deletion of active keys SHOULD also be supported.
It is likely that the IETF will define a standard key management A router that has forgotten its current sequence number but remembers
protocol. It is strongly desirable to use that key management protocol its key and Key-ID MUST send its first packet with a sequence number
to distribute RIP-II Authentication Keys among communicating RIP-II of zero. This leaves a small opening for a replay attack. Router
implementations. Such a protocol would provide scalability and vendors are encouraged to provide stable storage for keys, key
significantly reduce the human administrative burden. The Key ID can be lifetimes, Key-IDs, and the related sequence numbers.
used as a hook between RIP-II and such a future protocol. Key
management protocols have a long history of subtle flaws that are often
discovered long after the protocol was first described in public. To
avoid having to change all RIP-II implementations should such a flaw be
discovered, integrated key management protocol techniques were
deliberately omitted from this specification.
3.2. Key Management Procedures Acceptable messages are now truncated to RIP-2 message itself and
treated normally.
As with all security methods using keys, it is necessary to change the 4. Management Procedures
RIP-II Authentication Key on a regular basis. To maintain routing
stability during such changes, implementations MUST be able to store and
use more than one RIP-II Authentication Key on a given interface at the
same time.
Each key will have its own Key Identifier, which is stored locally. The 4.1. Key Management Requirements
combination of the Key Identifier and the interface associated with the
message uniquely identifies the Authentication Algorithm and RIP-II
Authentication Key in use.
As noted above in Section 2.2.1, the party creating the RIP-II message It is strongly desirable that a hypothetical security breach in one
will select a valid key from the set of valid keys for that interface. Internet protocol not automatically compromise other Internet
The receiver will use the Key Identifier and interface to determine protocols. The Authentication Key of this specification SHOULD NOT
which key to use for authentication of the received message. More than be stored using protocols or algorithms that have known flaws.
one key may be associated with an interface at the same time.
DRAFT RIP-II MD5 Authentication February 1995 Implementations MUST support the storage of more than one key at the
same time, although it is recognized that only one key will normally
be active on an interface. They MUST associate a specific lifetime
(i.e., date/time first valid and date/time no longer valid) and a key
identifier with each key, and MUST support manual key distribution
(e.g., the privileged user manually typing in the key, key lifetime,
and key identifier on the router console). The lifetime may be
infinite. If more than one algorithm is supported, then the
implementation MUST require that the algorithm be specified for each
key at the time the other key information is entered. Keys that are
out of date MAY be deleted at will by the implementation without
requiring human intervention. Manual deletion of active keys SHOULD
also be supported.
Hence it is possible to have fairly smooth RIP-II Authentication Key It is likely that the IETF will define a standard key management
rollovers without losing legitimate RIP-II messages because the stored protocol. It is strongly desirable to use that key management
key is incorrect and without requiring people to change all the keys at protocol to distribute RIP-2 Authentication Keys among communicating
once. To ensure a smooth rollover, each communicating RIP-II system RIP-2 implementations. Such a protocol would provide scalability and
must be updated with the new key several minutes before the current key significantly reduce the human administrative burden. The Key ID can
will expire and several minutes before the new key lifetime begins. The be used as a hook between RIP-2 and such a future protocol. Key
new key should have a lifetime that starts several minutes before the management protocols have a long history of subtle flaws that are
old key expires. This gives time for each system to learn of the new often discovered long after the protocol was first described in
RIP-II Authentication Key before that key will be used. It also ensures public. To avoid having to change all RIP-2 implementations should
that the new key will begin being used and the current key will go out such a flaw be discovered, integrated key management protocol
of use before the current key's lifetime expires. For the duration of techniques were deliberately omitted from this specification.
the overlap in key lifetimes, a system may receive messages using either
key and authenticate the message. The Key-ID in the received message is
used to select the appropriate key for authentication.
3.3. Pathological Cases 4.2. Key Management Procedures
Two pathological cases exist which must be handled, which are failures As with all security methods using keys, it is necessary to change
of the network manager. Both of these should be exceedingly rare. the RIP-2 Authentication Key on a regular basis. To maintain routing
stability during such changes, implementations MUST be able to store
and use more than one RIP-2 Authentication Key on a given interface
at the same time.
During key switchover, devices may exist which have not yet been Each key will have its own Key Identifier, which is stored locally.
successfully configured with the new key. Therefore, routers SHOULD The combination of the Key Identifier and the interface associated
implement (and would be well advised to implement) an algorithm that with the message uniquely identifies the Authentication Algorithm and
detects the set of keys being used by its neighbors, and transmits its RIP-2 Authentication Key in use.
messages using both the new and old keys until all of the neighbors are
using the new key or the lifetime of the old key expires. Under normal
circumstances, this elevated transmission rate will exist for a single
update interval.
In the event that the last key associated with an interface expires, it As noted above in Section 2.2.1, the party creating the RIP-2 message
is unacceptable to revert to an unauthenticated condition, and not will select a valid key from the set of valid keys for that
advisable to disrupt routing. Therefore, the router should send a "last interface. The receiver will use the Key Identifier and interface to
authentication key expiration" notification to the network manager and determine which key to use for authentication of the received
treat the key as having an infinite lifetime until the lifetime is message. More than one key may be associated with an interface at
extended, the key is deleted by network management, or a new key is the same time.
configured.
4. Conformance Requirements Hence it is possible to have fairly smooth RIP-2 Authentication Key
rollovers without losing legitimate RIP-2 messages because the stored
key is incorrect and without requiring people to change all the keys
at once. To ensure a smooth rollover, each communicating RIP-2
system must be updated with the new key several minutes before the
current key will expire and several minutes before the new key
lifetime begins. The new key should have a lifetime that starts
several minutes before the old key expires. This gives time for each
system to learn of the new RIP-2 Authentication Key before that key
will be used. It also ensures that the new key will begin being used
and the current key will go out of use before the current key's
lifetime expires. For the duration of the overlap in key lifetimes,
a system may receive messages using either key and authenticate the
message. The Key-ID in the received message is used to select the
appropriate key for authentication.
To conform to this specification, an implementation MUST support all of 4.3. Pathological Cases
its aspects. The Keyed MD5 authentication algorithm MUST be implemented
by all conforming implementations. MD5 is defined in RFC-1321. A
conforming implementation MAY also support other authentication
algorithms such as Keyed Secure Hash Algorithm (SHA). Manual key
distribution as described above MUST be supported by all conforming
DRAFT RIP-II MD5 Authentication February 1995 Two pathological cases exist which must be handled, which are
failures of the network manager. Both of these should be exceedingly
rare.
implementations. All implementations MUST support the smooth key During key switchover, devices may exist which have not yet been
rollover described under "Key Change Procedures." successfully configured with the new key. Therefore, routers SHOULD
implement (and would be well advised to implement) an algorithm that
detects the set of keys being used by its neighbors, and transmits
its messages using both the new and old keys until all of the
neighbors are using the new key or the lifetime of the old key
expires. Under normal circumstances, this elevated transmission rate
will exist for a single update interval.
The user documentation provided with the implementation MUST contain In the event that the last key associated with an interface expires,
clear instructions on how to ensure that smooth key rollover occurs. it is unacceptable to revert to an unauthenticated condition, and not
advisable to disrupt routing. Therefore, the router should send a
"last authentication key expiration" notification to the network
manager and treat the key as having an infinite lifetime until the
lifetime is extended, the key is deleted by network management, or a
new key is configured.
Implementations SHOULD support a standard key management protocol for 5. Conformance Requirements
secure distribution of RIP-II Authentication Keys once such a key
management protocol is standardized by the IETF.
5. Acknowledgments To conform to this specification, an implementation MUST support all
of its aspects. The Keyed MD5 authentication algorithm MUST be
implemented by all conforming implementations. MD5 is defined in
RFC-1321. A conforming implementation MAY also support other
authentication algorithms such as Keyed Secure Hash Algorithm (SHA).
Manual key distribution as described above MUST be supported by all
conforming implementations. All implementations MUST support the
smooth key rollover described under "Key Change Procedures."
This work was done by the RIP-II Working Group, of which Gary Malkin is The user documentation provided with the implementation MUST contain
the Chair. This suggestion was originally made by Christian Huitema on clear instructions on how to ensure that smooth key rollover occurs.
behalf of the IAB. Jeff Honig (Cornell) and Dennis Ferguson (ANS) built
the first operational prototype, proving out the algorithms. The
authors gladly acknowledge significant inputs from each of these
sources.
6. References Implementations SHOULD support a standard key management protocol for
secure distribution of RIP-2 Authentication Keys once such a key
management protocol is standardized by the IETF.
[1] Malkin, Gary, "RIP Version 2 Carrying Additional Information", RFC 6. Acknowledgments
1388, January 1993.
[2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April This work was done by the RIP-2 Working Group, of which Gary Malkin
1992. is the Chair. This suggestion was originally made by Christian
Huitema on behalf of the IAB. Jeff Honig (Cornell) and Dennis
Ferguson (ANS) built the first operational prototype, proving out the
algorithms. The authors gladly acknowledge significant inputs from
each of these sources.
[3] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC 1389, 7. References
Xylogics, Inc., Advanced Computer Communications, January 1993.
[4] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM [1] Malkin, G., "RIP Version 2 Carrying Additional Information",
Computer Communications Review, Volume 19, Number 2, pp.32-48, RFC 1388, January 1993.
April 1989.
[5] N. Haller, R. Atkinson, "Internet Authentication Guidelines", [2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
RFC-1704, October 1994. 1992.
[6] R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of IAB [3] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension",
Workshop on Security in the Internet Architecture", RFC-1636, June RFC 1389, Xylogics, Inc., Advanced Computer Communications,
1994. January 1993.
[7] R. Atkinson, "IP Authentication Header", RFC-1826, August 1995. [4] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite",
ACM Computer Communications Review, Volume 19, Number 2,
pp.32-48, April 1989.
DRAFT RIP-II MD5 Authentication February 1995 [5] Haller, N., and R. Atkinson, "Internet Authentication
Guidelines", RFC 1704, October 1994.
[8] R. Atkinson, "IP Encapsulating Security Payload", RFC-1827, August [6] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report
1995. of IAB Workshop on Security in the Internet Architecture",
RFC 1636, June 1994.
7. Security Considerations [7] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
This entire memo describes and specifies an authentication mechanism for [8] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
the RIP-II routing protocol that is believed to be secure against active August 1995.
and passive attacks. Passive attacks are clearly widespread in the
Internet at present. Protection against active attacks is also needed
because active attacks are becoming more common.
Users need to understand that the quality of the security provided by 8. Security Considerations
this mechanism depends completely on the strength of the implemented
authentication algorithms, the strength of the key being used, and the
correct implementation of the security mechanism in all communicating
RIP-II implementations. This mechanism also depends on the RIP-II
Authentication Key being kept confidential by all parties. If any of
these incorrect or insufficiently secure, then no real security will be
provided to the users of this mechanism.
Specifically with respect to the use of SNMP, compromise of SNMP This entire memo describes and specifies an authentication mechanism
security has the necessary result that the various RIP-II configuration for the RIP-2 routing protocol that is believed to be secure against
parameters (e.g. routing table, RIP-II Authentication Key) managable via active and passive attacks. Passive attacks are clearly widespread in
SNMP could be compromised as well. Changing Authentication Keys using the Internet at present. Protection against active attacks is also
non-encrypted SNMP is no more secure than sending passwords in the needed because active attacks are becoming more common.
clear.
Confidentiality is not provided by this mechanism. Recent work in the Users need to understand that the quality of the security provided by
IETf provides a standard mechanism for IP-layer encryption. [8] That this mechanism depends completely on the strength of the implemented
mechanism might be used to provide confidentiality for RIP-II in the authentication algorithms, the strength of the key being used, and
future. Protection against traffic analysis is also not provided. the correct implementation of the security mechanism in all
Mechanisms such as bulk link encryption might be used when protection communicating RIP-2 implementations. This mechanism also depends on
against traffic analysis is required. the RIP-2 Authentication Key being kept confidential by all parties.
If any of these incorrect or insufficiently secure, then no real
security will be provided to the users of this mechanism.
The memo is written to address a security consideration in RIP-II Specifically with respect to the use of SNMP, compromise of SNMP
Version 2 that was raised during the IAB's recent security review [6]. security has the necessary result that the various RIP-2
configuration parameters (e.g. routing table, RIP-2 Authentication
Key) manageable via SNMP could be compromised as well. Changing
Authentication Keys using non-encrypted SNMP is no more secure than
sending passwords in the clear.
8. Chairman's Address Confidentiality is not provided by this mechanism. Recent work in
the IETF provides a standard mechanism for IP-layer encryption. [8]
That mechanism might be used to provide confidentiality for RIP-2 in
the future. Protection against traffic analysis is also not
provided. Mechanisms such as bulk link encryption might be used when
protection against traffic analysis is required.
Gary Scott Malkin The memo is written to address a security consideration in RIP
Xylogics, Inc. Version 2 that was raised during the IAB's recent security review
53 Third Avenue [6].
Burlington, MA 01803
Phone: (617) 272-8140
DRAFT RIP-II MD5 Authentication February 1995 9. Chairman's Address
EMail: gmalkin@Xylogics.COM Gary Scott Malkin
Xylogics, Inc.
53 Third Avenue
Burlington, MA 01803
9. Authors' Addresses Phone: (617) 272-8140
EMail: gmalkin@Xylogics.COM
Fred Baker 10. Authors' Addresses
Cisco Systems
519 Lado Drive
Santa Barbara, California 93111
Phone: (805) 681 0115
Email: fred@cisco.com
Randall Atkinson Fred Baker
cisco Systems cisco Systems
170 West Tasman Drive 519 Lado Drive
San Jose, CA 95134-1706 Santa Barbara, California 93111
Voice: (408) 526-6566
Email: rja@cisco.com
DRAFT RIP-II MD5 Authentication February 1995 Phone: (805) 681 0115
Email: fred@cisco.com
Table of Contents Randall Atkinson
cisco Systems
170 West Tasman Drive
San Jose, CA 95134-1706
1 Introduction .................................................... 2 Phone: (408) 526-6566
2 Implementation Approach ......................................... 3 EMail: rja@cisco.com
2.1 RIP-II PDU Format ............................................. 3
2.2 Processing Algorithm .......................................... 5
2.2.1 Message Generation .......................................... 6
2.2.2 Message Reception ........................................... 7
3 Management Procedures ........................................... 7
3.1 Key Management Requirements ................................... 7
3.2 Key Management Procedures ..................................... 8
3.3 Pathological Cases ............................................ 9
4 Conformance Requirements ........................................ 9
5 Acknowledgments ................................................. 10
6 References ...................................................... 10
7 Security Considerations ......................................... 11
8 Chairman's Address .............................................. 11
9 Authors' Addresses .............................................. 12
 End of changes. 107 change blocks. 
366 lines changed or deleted 396 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/