Network Working Group R. Atkinson, Extreme Networks
INTERNET-DRAFT M. Fanto, NIST
29 September 2005
draft-rja-ripv2-auth-02.txt
Expires: 29 March 2006
RIPv2 Cryptographic Authentication
draft-rja-ripv2-auth-02.txt
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
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
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
and may be updated, replaced, or obsoleted by other documents at any
Atkinson & Fanto [Page 1]
INTERNET-DRAFT 29 Sep 2005
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html
This memo is a contribution to the IETF and is intended for future
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.
ABSTRACT
This note describes a revision to the RIPv2 Cryptographic
Authentication mechanism originally specified in RFC-2082. This
document includes specific details of how HMAC SHA-1 is used with
RIPv2 Cryptographic Authentication, whereas the original document
only specified the use of Keyed-MD5. Also, this document clarifies
a potential issue with an active attack on this mechanism and adds
significant text to the Security Considerations section.
1. INTRODUCTION
Growth in the Internet has made us aware of the need for improved
authentication of routing information. RIPv2 provides for
unauthenticated service (as in classical RIP), or password
authentication. Both are vulnerable to passive attacks currently
widespread in the Internet. Well-understood security issues exist in
routing protocols [Bell89]. Clear text passwords, originally
specified for use with RIPv2, are widely understood to be vulnerable
to easily deployed passive attacks [HA94].
The original RIPv2 cryptographic authentication specification [AB97]
used the Keyed-MD5 cryptographic mechanism. While there are no openly
published attacks on that mechanism, some reports [Dobb96a, Dobb96b]
create concern about the ultimate strength of the MD5 cryptographic
hash function. Further, some end users, particularly several
different governments, require the use of the SHA-1 hash function
rather than any other such function for policy reasons. Finally,
the original specification uses a hashing construction widely believed
to be weaker than the HMAC construction used with the algorithms added
Atkinson & Fanto [Page 2]
INTERNET-DRAFT 29 Sep 2005
in this revision of the specification.
Hence, this document replaces [AB97] and adds support for the
HMAC-SHA1 cryptographic mechanism, while retaining the original
Keyed-MD5 mechanism as a deployment option. As the original RIPv2
Cryptographic Authentication mechanism was algorithm-independent,
backwards compatibility is retained.
The authors do NOT believe that this specification is the final
answer to RIPv2 authentication and encourage the reader to consult
the SECURITY CONSIDERATIONS section of this document for more
details.
If RIPv2 authentication is disabled, then only simple
misconfigurations are detected. The original RIPv2 authentication
mechanism relied upon reused cleartext passwords. Use of cleartext
password authentication can protect against accidential
misconfigurations if that were the only concern, but is not helpful
from a security perspective. By simply capturing information on the
wire - straightforward even in a remote environment - a hostile
entity can read the cleartext RIPv2 password and use that knowledge
to inject false information into the routing system via the RIPv2
routing protocol.
This mechanism is intended to reduce the risk of a successful passive
attack upon RIPv2 deployments. That is, deployment of this mechanism
greatly reduces the vulnerability of the RIPv2-based routing system
from a passive attack. When cryptographic authentication is enabled,
we transmit the output of a keyed cryptographic one-way function in
the authentication field of the RIPv2 packet, instead of sending a
cleartext reusable password in the RIPv2 packet. The RIPv2
Authentication Key is known only to the authorised parties of the
RIPv2 session. The RIPv2 Authentication Key is never sent over the
network in the clear.
In this way, protection is afforded against forgery or message
modification. While it is possible to replay a message until the
sequence number changes, a sequence number can be used to reduce
replay risks. The mechanism does not provide confidentiality,
since messages stay in the clear. Since the objective of a
routing protocol is to advertise the routing topology,
confidentiality is not normally required for routing protocols.
Other relevant rationales for the approach are that MD5 and SHA-1
are both being used for other purposes and are therefore generally
already present in IP routers, as is some form of password
management. A similar approach, the IP Authentication Header,
has been standardised for IP-layer authentication. [Atk95b]
Atkinson & Fanto [Page 3]
INTERNET-DRAFT 29 Sep 2005
We don't use AH with RIPv2 only for the historical reason that
this mechanism predates the IETF's standardisation of AH.
1.1 Terminology
In this document, the words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described
in [BCP14] [RFC-2119] and indicate requirement levels for compliant
or conformant implementations.
2. Implementation Approach
Implementation requires use of a special packet format, special
authentication procedures, and also management controls. Implementers
need to remember that the SECURITY CONSIDERATIONS section is an
integral part of this specification and contains important parts of
this specification.
2.1. RIPv2 PDU Format
The basic RIPv2 message format provides for an 8 byte header with an
array of 20 byte records as its data content. When RIPv2
Cryptographic Authentication is enabled, the same header and content
are used as with the original RIPv2 specification, but the 16 byte
"Authentication" field is reused to describe a "Cryptographic
Authentication" trailer. This trailer contains five fields as
follows:
AUTHENTICATION TYPE
The "Authentication Type" is Cryptographic Hash Function,
which is indicated by the value 3.
RIPv2 PACKET LENGTH
An unsigned 16 bit offset from the RIPv2 header to the output
of the cryptographic hash function in use (if no other trailer
fields are ever defined, this value equals the RIPv2 Data Length).
KEY IDENTIFIER
An unsigned 8-bit field that contains the Key Identifier or
Key-ID. This identifies the RIPv2 Security Association in use for
this packet. The RIPv2 Security association, which is defined in
Section 2.2 below, includes the Authentication Key that was used
to create the Authentication Data for this RIPv2 message and other
parameters. In implementations supporting more than one
Atkinson & Fanto [Page 4]
INTERNET-DRAFT 29 Sep 2005
authentication algorithm, the RIPv2 Security Association also
includes information about which authentication algorithm in use
for this message. A key is always associated with an interface,
rather than with a router.
AUTHENTICATION DATA LENGTH
An unsigned 8-bit field that contains the length in octets
(bytes) of the trailing Authentication Data field. The presence
of this field helps provide cryptographic algorithm independence.
AUTHENTICATION DATA
This field contains the cryptographic Authentication Data
used to validate this packet. The length of this field is stored
in the AUTHENTICATION DATA LENGTH field above.
SEQUENCE NUMBER
An unsigned 32 bit sequence number. The sequence number MUST
be non-decreasing for all messages sent with a given Key ID value.
The authentication trailer consists of the Authentication Data, which
is the output of the keyed cryptographic hash function. See later
subsections of this section for details on computing this field.
2.2 RIPv2 Security Association
Understanding the RIPv2 Security Association concept is central to
understanding this specification. A RIPv2 Security Association
contains the set of shared authentication configuration parameters
needed by the legitimate sender or any legitimate receiver.
An implementation MUST be able to support at least 2 concurrent RIPv2
Security Associations on each RIP interface. This is a functional
requirement for supporting key rollover. Support for key rollover is
mandatory.
The RIPv2 Security Association, defined below, is selected by the
sender based on the outgoing router interface. Each RIPv2 Security
Association has a lifetime and other configuration parameters
associated with it. In normal operation, a RIPv2 Security Association
is never used outside its lifetime.
The minimum data items in a RIPv2 Security Association are as follows:
KEY-IDENTIFIER (KEY-ID)
The unsigned 8-bit KEY-ID value is used to identify the RIPv2
Security Association in use for this packet. The receiver uses
Atkinson & Fanto [Page 5]
INTERNET-DRAFT 29 Sep 2005
the combination of the interface the packet was receive upon and
this value to uniquely identify the appropriate Security
Association. The sender selects which RIPv2 Security Association
to use based on the outbound interface for this RIPv2 packet and
then places the correct KEY-ID value into that packet.
AUTHENTICATION ALGORITHM
This specifies the cryptographic algorithm and algorithm
mode used with the RIPv2 Security Association. This information
doesn't need to be sent in each packet, so it is never sent in
clear-text over the wire. Because this information is not sent
on the wire, the implementer chooses an implementation-specific
representation for this information. At present, the following
values are possible:
KEYED-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384,
and HMAC-SHA-512.
AUTHENTICATION KEY
This is the value of the cryptographic authentication key
used with the associated Authentication Algorithm. It MUST NOT
ever be sent over the network in clear-text via any protocol.
The length of this key will depend on the Authentication Algorithm
in use. Operators should take care to select unpredictable and
strong keys, avoiding any keys known to be weak for the algorithm
in use. [ECS94] contains helpful information both on key
generation techniques and on cryptographic randomness.
SEQUENCE NUMBER
This is an unsigned 32-bit number. For a given KEY-ID value,
this number MUST NOT decrease. In normal operation, the operator
should rekey the RIPv2 session prior to reaching the maximum
value. The initial value used in the sequence number is
arbitrary.
START TIME
This is a local representation of the day and time that
this Security Association first becomes valid.
STOP TIME
This is a local representation of the day and time that
this Security Association becomes invalid (i.e. when it expires).
It is permitted, but not recommended, for an operator to configure
this to be "never expire". The "never expire" value is not
recommended operational practice because it reduces security
as compared with periodic rekeying.
Atkinson & Fanto [Page 6]
INTERNET-DRAFT 29 Sep 2005
2.3 Basic Authentication Processing
When the authentication type is "Cryptographic Hash Function", message
processing is changed in message creation and reception as compared
with the original RIPv2 specification in [Mal94].
This section describes the message processing generically. Additional
algorithm-dependent processing that is required is described in
separate, subsequent sections of this document. As of this writing,
there are 2 kinds of algorithm-dependent processing. One covers the
"Keyed-MD5" algorithm. The other covers the "HMAC-SHA1" family of
algorithms.
2.3.1. Message Generation
The RIPv2 Packet is created as usual, with these exceptions:
(1) The UDP checksum SHOULD be calculated, but MAY be set
to zero because any of the cryptographic authentication
mechanisms in this specification will provider stronger
integrity protection than the standard UDP checksum.
(2) The authentication type field indicates Cryptographic
Authentication (3).
(3) The authentication "password" field is reused to store a
packet offset to the Authentication Data, a Key Identifier,
the Authentication Data Length, and a non-decreasing
sequence number.
See also Section 2.2 above on RIPv2 Security Association for
other important background information.
When creating the RIPv2 Packet, the follow process is followed:
(1) The packet length field of the RIPv2 header indicates the
size of the main body of the RIPv2 packet.
(2) An appropriate RIPv2 Security Association is selected for
use with this packet. The Authentication Data Offset,
Key Identifier, and Authentication Data size fields are
filled in appropriately.
(3) Algorithm-dependent processing occurs now, either for the
"Keyed-MD5" algorithm xor the "HMAC-SHA1" algorithm family.
See the respective sub-sections (below) for details of this
Atkinson & Fanto [Page 7]
INTERNET-DRAFT 29 Sep 2005
algorithm-dependent processing.
(4) The resulting Authentication Data value is written into the
Authentication Data field. The trailing pad (if any) is not
actually transmitted, as it is entirely predictable from the
message length and Authentication Algorithm in use.
2.3.2. Message Reception
When the message is received, the process is reversed:
(1) The received Authentication Data is set aside and stored
for later use,
(2) The appropriate RIPv2 Security Association is determined
from the value of the Key Identifier field and the interface
the packet was received on.
(3) Algorithm-dependent processing is performed, using the
algorithm specified by the appropriate RIPv2 Security
Association for this packet. This results in calculation
of the Authentication Data based on the information in the
received RIPv2 packet and information from the appropriate
RIPv2 Security Association for that packet.
(4) The calculated Authentication Data result is compared with
the received Authentication Data.
(5) If the calculated authentication data result does not match the
received Authentication Data field, then:
(a) the message MUST be discarded without being processed,
and
(b) a security event SHOULD be logged by the RIPv2 subsystem
of the receiving system. That security event SHOULD indicate
at least the day/time that the bad packet was received, the
Source IP Address of the received RIPv2 packet, the Key-ID
field value, and the fact that RIPv2 Authentication failed
upon receipt of the packet.
(6) If the neighbor has been heard from recently enough to have viable
routes in the route table, and the received sequence number is
less than the last sequence number received, then the message
MUST be discarded unprocessed. If the received sequence number
is less than the last sequence number received, that fact SHOULD
be logged as a security event. This logged security event SHOULD
indicate at least the day/time that the bad packet was received,
the Source IP Address of the received RIPv2 packet, the Key-ID
Atkinson & Fanto [Page 8]
INTERNET-DRAFT 29 Sep 2005
field value, and the fact that an out of order RIPv2 Sequence
Number was received.
When connectivity to the neighbor has been lost, the receiver
SHOULD be ready to accept either:
- a message with a sequence number of zero.
- a message with a higher sequence number than
the last received sequence number.
(7) Acceptable messages are now truncated to the RIPv2 message itself,
minus the authentication trailer, and are processed normally
(i.e. in accordance with the RIPv2 base specification in RFC-2453
[Mal98]).
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, implementers SHOULD
provide non-volatile storage for all components of a RIPv2 Security
Association. See also the SECURITY CONSIDERATIONS section of this
document.
2.4 Keyed-MD5 Algorithm-dependent Processing
This section describes the algorithm-dependent processing
steps applicable when the "Keyed-MD5" authentication algorithm is
in use. The RIPv2 Authentication Key is always 16 octets when
"Keyed-MD5" is in use.
(1) The RIPv2 Authentication Key is appended to the RIPv2 packet
in memory.
(2) The Trailing Pad for MD5 and message length fields are added
in memory. The diagram below shows how these additions appear
when appended in memory:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Key |
/ (16 octets long) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more pad bytes (as defined by RFC-1321) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 bit message length MSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 bit message length LSW |
Atkinson & Fanto [Page 9]
INTERNET-DRAFT 29 Sep 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(3) The Authentication Data is then calculated according to the
MD5 algorithm defined by RFC-1321 [Rivest92].
2.5 HMAC-SHA1 Algorithm-dependent Processing
This section describes the processing steps for HMAC
Authentication. While HMAC was originally documented in [KMC97],
for this specification the terminology used in [FIPS-198] is used.
While the current specification only provides full details for HMAC
Authentication using the NIST SHA-1 algorithm (and its direct
derivatives), this same basic process could be used with other
cryptographic hash functions in future. Because the RIPv2 packet
is only hashed once, the overhead of double hashing is negligible.
The US NIST Secure Hash Standard (SHA-1), defined by
[FIPS-180-2], includes specifications for SHA-1, SHA-256, SHA-384,
and SHA-512. This specification defines processing for each of these.
The output of the cryptographic computations (e.g. HMAC-SHA1)
is NOT truncated for RIPv2 Cryptographic Authentication.
The Authentication Data length is equal to the Message Digest
Size for the hash algorithm in use.
Any key value known to be weak with SHA-1 MUST NOT be used with
this specification. US NIST is the authoritative source for public
information on weak keys for SHA-1.
In the algorithm description below, the following nomenclature,
which is consistent with [FIPS-198] is used:
H is the specific hashing algorithm,
for example SHA-1 or SHA-256.
Ko is the cryptographic key used with the hash algorithm.
B is the block-size of H, measured in bytes not bits.
Note that B is the internal block size,
not the hash size.
For SHA-1 and SHA-256: B == 64.
For SHA-384 and SHA-512: B == 128
L is the length of the hash, measured in bytes,
not bits. For example, with SHA-1, L == 20.
XOR is the exclusive-or operation.
Opad is the hexadecimal value 0x5c repeated B times.
Atkinson & Fanto [Page 10]
INTERNET-DRAFT 29 Sep 2005
Ipad is the hexadecimal value 0x36 repeated B times.
Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times.
(1) PREPARATION OF KEY
In this application, Ko is always L bytes long.
If the Authentication Key is L bytes long, then Ko is set equal
to the Authentication Key. If the Authentication Key is more
than L bytes long, then Ko is set to H(Authentication Key). If
the Authentication Key is less than L bytes long, then Ko is set
to the Authentication Key with zeros appended to the end of the
Authentication Key such that Ko is L bytes long.
(2) FIRST HASH
First, the RIPv2 packet's Authentication Data field is filled
with the value Apad.
Then, a first hash, also known as the inner hash, is computed
as follows:
First-Hash = H(Ko XOR Ipad, (RIPv2 Packet))
(3) SECOND HASH
Then a second hash, also known as the outer hash, is computed
as follows:
Second-Hash = H(Ko XOR Opad, First-Hash)
(4) RESULT
The result Second-Hash becomes the Authentication Data that is
sent in the Authentication Data field of the RIPv2 packet. The
length of the Authentication Data field is always identical to
the message digest size of the hash function H that is being used.
This also implies that use of hash functions with larger output
sizes will also increase the size of the packet as transmitted on
the wire.
3. Management Procedures
Key management is an important component of this mechanism and
proper implementation is central to providing the intended level
of risk reduction.
3.2. Key Management Requirements
It is strongly desirable that a hypothetical security breach in one
Internet protocol not automatically compromise other Internet
protocols. The Authentication Key of this specification SHOULD NOT
Atkinson & Fanto [Page 11]
INTERNET-DRAFT 29 Sep 2005
be stored using protocols or algorithms that have known flaws.
Implementations MUST support the storage of more than one key at the
same time, although it is recognized that only one key will normally
be active on an interface. Implementations MUST associate a specific
Security Association lifetime (i.e., date/time first valid and
date/time no longer valid) and a key identifier with each key.
Implementations also MUST support manual key distribution. An
example of manual key distribution is having the privileged user
typing in the key, key lifetime, and key identifier on the router
console. The configured Security Association lifetime MAY be
infinite; however, periodic rekeying is strongly encouraged. This
specification requires support for at least two authentication
algorithms, so the implementation MUST require that the authentication
algorithm be specified for each key when the other key information
is entered. Manual deletion of active Security Associations MUST
be supported.
It is likely that the IETF will define a standard key management
protocol for use with routing protocols. It is strongly desirable to
use an IETF standards-track key management protocol to distribute
RIPv2 Authentication Keys among communicating RIPv2 implementations.
Such a protocol would provide scalability and significantly reduce the
human administrative burden. The Key-ID field can be used as a hook
between RIPv2 and such a future protocol.
Key management protocols have a long history of subtle flaws that are
often discovered long after the protocol was first described in
public. To avoid having to change all RIPv2 implementations should
such a flaw be discovered, integrated key management protocol
techniques were deliberately omitted from this specification.
3.3. Key Management Procedures
As with all security methods using keys, it is necessary to change
the RIPv2 Authentication Key on a regular basis. To maintain
routing stability during such changes, implementations MUST be able
to store and use more than one RIPv2 Authentication Key on a
given interface at the same time.
Each key will have its own Key Identifier (KEY-ID), which is stored
locally. The combination of the Key Identifier and the interface
associated with the message uniquely identifies the Authentication
Algorithm and RIPv2 Authentication Key in use.
As noted above in Section 2.3.1, the party creating the RIPv2 message
will select a valid RIPv2 Security Association from the set of valid
RIPv2 Security Associations for that interface. The receiver MUST use
Atkinson & Fanto [Page 12]
INTERNET-DRAFT 29 Sep 2005
the Key Identifier and receiving interface to determine which RIPv2
Security Association to use for authentication of the received
message. More than one RIPv2 Security Association MAY be associated
with an interface at the same time. The receiver MUST NOT simply try
all RIPv2 Security Associations (i.e. keys) that might be configured
for RIPv2 on the receiving interface, as that creates an easily
exploited denial-of-service attack on the RIP subsystem of the
receiver. (At least one widely used implementation of the previous
version of this specification violates these requirements as of the
publication date of this document and has consequent security
vulnerabilities.)
Hence it is possible to have fairly smooth RIPv2 Security Association
(i.e. key) rollovers, without losing legitimate RIPv2 messages due to
an invalid shared key and without requiring people to change all the
keys at once. To ensure a smooth rollover, each communicating RIPv2
system must be updated with the new RIPv2 Security Association
(including the new key) several minutes before the current RIPv2
Security Association will expire and several minutes before the new
RIPv2 Security Association lifetime begins. Also, the new RIPv2
Security Association should have a lifetime that starts several
minutes before the old RIPv2 Security Association expires. This gives
time for each system to learn of the new security association before
that security association will be used. It also ensures that the new
security association will begin use and the current security
association will go out of use before the current security
association's lifetime expires. For the duration of the overlap in
security association lifetimes, a system may receive messages
corresponding to either security association and successfully
authenticate the message. The Key-ID in the received message is used
to select the appropriate security association (i.e. key) to be used
for authentication.
4. Conformance Requirements
For this specification, the term "conformance" has identical meaning
to the phrase "full compliance".
The Keyed MD5 authentication algorithm and the HMAC-SHA1 algorithm
MUST be implemented by all conforming implementations. In addition,
the HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 algorithms SHOULD be
implemented. MD5 is defined in [Rivest92]. SHA-1, SHA-256, SHA-384,
and SHA-512 have been defined by the (US) National Institute of
Standards & Technology (NIST) in [FIPS-180-2].
A conforming implementation MAY also support additional authentication
algorithms, provided those additional algorithms are publicly and
Atkinson & Fanto [Page 13]
INTERNET-DRAFT 29 Sep 2005
openly specified.
Manual key distribution as described above MUST be supported by all
conforming implementations. All implementations MUST support the
smooth key rollover described under "Key Management Procedures". This
also means that implementations MUST support at least 2 concurrent
RIPv2 Security Associations.
The user documentation provided with the implementation MUST contain
clear instructions on how to configure the implementation such that
smooth key rollover occurs successfully.
Implementations SHOULD support a standard key management protocol
for secure distribution of RIPv2 Authentication Keys once such a
key management protocol is standardized by the IETF.
The Security Considerations section of this document is an integral
part of the specification, not just a discussion of the protocol.
5. Security Considerations
This entire memo describes and specifies an authentication mechanism
for the RIPv2 routing protocol that is believed to be secure against
passive attacks. Passive attacks are clearly widespread in the
Internet at present.[HA94] Protection against active attacks is
incomplete in this current specification. The main issue relative to
active attacks lies in the need to support the case where another
router has recently rebooted and lacks the non-volatile storage needed
to remember the current RIPv2 sequence number across that reboot.
5.1 Known Pathological Cases
Two known pathological cases exist which MUST be handled by
implementations. Both of these are failures of the network manager.
Each of these should be exceedingly rare in normal operation.
(1) During key rollover, devices might exist which have not yet been
successfully configured with the new key. Therefore, routers SHOULD
implement an algorithm that detects the set of RIPv2 Security
Associations being used by its neighbors, and transmits its messages
using both the new and old RIPv2 Security Associations (i.e. keys)
until all of the neighbors are using the new security association or
the lifetime of the old security association expires. Under normal
circumstances, this elevated transmission rate will exist for a
single RIP update interval.
Atkinson & Fanto [Page 14]
INTERNET-DRAFT 29 Sep 2005
(2) In the event that the last RIPv2 Security Association of an
interface expires, it is unacceptable to revert to an
unauthenticated condition, and not advisable to disrupt routing.
Therefore, the router MUST send a "last RIPv2 Security Association
expiration" notification to the network manager (e.g. via SYSLOG,
SNMP, and/or other means) and SHOULD treat that last Security
Association as having an infinite lifetime until the lifetime
is extended, the Security Association is deleted by network
management, or a new security association is configured.
In some circumstances, the practice described in (2) can leave an
opening to an active attack on the RIPv2 routing subsystem.
Therefore, any actual occurance of a RIPv2 Security Association
expiration MUST cause a security event to be logged by the
implementation. This log item MUST include at least note that the
RIPv2 Authentication Key expired, the RIP routing protocol instance(s)
affected, the routing interfaces affected, the Key-ID that is
affected, and the current date/time. Operators are encouraged to
check such logs as an operational security practice to help detect
active attacks on the RIPv2 routing subsystem. Further,
implementations SHOULD provide a configuration knob ("fail secure") to
let a network operator prefer to have the RIPv2 routing fail when the
last key expires, rather than continue using RIPv2 in an insecure
manner.
5.2 Security Considerations for Network Management
Also, the use of SNMP, even SNMP with cryptographic
confidentiality enabled, to read or write RIPv2 Security Associations,
or any component of the security association (for example the
cryptographic key), is NOT RECOMMENDED. This practice would create a
potential for a cascading vulnerability, whereby a compromise in the
SNMP security implementation would necessarily lead to a compromise
not only of the local routing table (which could be accessed via SNMP)
but also of all other routers that receive RIPv2 packets (directly or
indirectly) from the compromised router.
Also, the use of SNMP to configure which form of RIPv2
authentication is in use is also NOT RECOMMENDED because of a similar
cascading failure issue. Any future revision of the RIPv2 Management
Information Base (MIB) should deprecate or omit any MIB objects that
would permit modification of the RIPv2 Authentication mode (e.g. none,
cleartext password, RIPv2 Cryptographic Authentication) in use.
Further, for similar reasons, any future revisions to the
RIPv2 Management Information Base (MIB) SHOULD deprecate or omit any
Atkinson & Fanto [Page 15]
INTERNET-DRAFT 29 Sep 2005
MIB objects that would permit reading or writing any RIPv2 Security
Association, or any RIPv2 Security Association component (for example
the cryptographic key).
Also, any future revisions to the RIPv2 Management Information
Base (MIB) SHOULD deprecate or omit any MIB objects that would permit
SNMP to be used to modify whether the RIPv2 instance uses
cryptographic authentication, cleartext password authentication, or no
authentication.
Also, it is RECOMMENDED that any future revisions to the RIPv2
Management Information Base (MIB) consider adding MIB objects to hold
information about any RIPv2 security events that might have occurred
and MIB objects that could be used to read the set of security events
that have been logged by the RIPv2 subsystem. Each security events
mentioned in this document is also RECOMMENDED for inclusion in future
versions of RIPv2 SNMP MIB as an INFORM object.
5.3 Assurance Considerations
Users need to understand that the quality of the security
provided by this mechanism depends completely on the strength of the
implemented authentication algorithms, the strength of the key being
used, and the correct implementation of the security mechanism in all
communicating RIPv2 implementations. This mechanism also depends on
the RIPv2 Authentication Key being kept confidential by all parties.
If any of these incorrect or insufficiently secure, then no real
security will be provided to the users of this mechanism.
Use of high assurance development methods is RECOMMENDED for
implementations of this specification, in order to reduce the risk of
subtle implementation flaws that might adversely impact the
operational risk reduction that this specification seeks to provide.
5.4 Confidentiality & Traffic Analysis Considerations
Confidentiality is not provided by this mechanism. Recent
work in the IETF [Atk95a] provides a standard mechanism for IP-layer
encryption [Atk95c] and for IP-layer authentication [Atk95b]. We do
not require use of either of those mechanisms in this specification,
in order to preserve backwards-compatibility with the installed base
of RIPv2 systems that only support cryptographic authentication.
Protection against traffic analysis is also not provided.
Mechanisms such as bulk link encryption SHOULD be used when protection
against traffic analysis is required. [CKHD89]
Atkinson & Fanto [Page 16]
INTERNET-DRAFT 29 Sep 2005
5.5 Other Security Considerations
Separately, the receipt of a RIPv2 packet using cryptographic
authentication but containing an invalid or unknown Key-ID value might
indicate an active attack on the RIP routing subsystem and is a
significant security event. Therefore, any actual receipt of a RIPv2
packet using cryptographic authentication and containing an unknown,
expired, or otherwise invalid KEY-ID value SHOULD cause a security
event to be logged by the implementation. This log item SHOULD
include at least the fact that the invalid KEY-ID was received, the
source IP address of the packet containing the invalid KEY-ID, the
interface(s) the packet was received on, the KEY-ID received, and the
current date/time.
A subtle user-interface consideration also should be noted.
If a user-interface only permits the entry of human-readable text
(e.g. a password in US-ASCII format) for use as a cryptographic key,
significant numbers of bits of the cryptographic key in use become
predictable, thereby reducing the strength of the key in this context.
For this reason, implementations of this specification SHOULD support
the entry of RIPv2 cryptographic authentication keys in hexadecimal
format.
5.6 Future Security Directions
Specification and deployment of a standards-track key
management protocol that supporting this RIPv2 cryptographic
authentication mechanism would be a significant next step in
operational risk reduction and might actually increase the ease of
deployment and operation of this mechanism. Such specification is
beyond the scope of this document.
Several large RIPv2 deployments happen to also have deployed
the Kerberos authentication system. One might consider enhancing
Kerberos to support RIPv2 key management functions for use in such
deployments.
Finally, we observe that this mechanism is not the final word
on RIPv2 authentication. Rather, it is believed that this particular
mechanism represents a significant risk reduction over previous
methods (e.g. plain-text passwords), while remaining straight-forward
to implement correctly and also straight-forward 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
Atkinson & Fanto [Page 17]
INTERNET-DRAFT 29 Sep 2005
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.
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
by this specification.
Acknowledgments
Fred Baker was co-author of the earlier RIPv2 MD5 Authentication
document. [AB97] This document is a direct derivative of that earlier
document, though it has been significantly reworked. Any errors are
the responsibility of the current authors. The current authors would
like to thank Bill Burr, Tim Polk, John Kelsey, and Morris Dworkin of
NIST for review of drafts of this document.
Informative References
[Atk95a] Atkinson, R., "Security Architecture for the Internet
Protocol", RFC-1825, August 1995.
[Atk95b] Atkinson, R., "IP Authentication Header", RFC-1826,
August 1995.
[Atk95c] Atkinson, R., "IP Encapsulating Security Payload",
RFC-1827, August 1995.
[AB97] Atkinson, R. & F. Baker, "RIPv2 MD5 Authentication",
RFC-2082, January 1997.
[Bell89] S. Bellovin, "Security Problems in the TCP/IP Protocol
Suite", ACM Computer Communications Review, Volume 19,
Number 2, pp. 32-48, April 1989.
[CKHD89] Cole Jr, Raymond, Donald Kallgren, Richard Hale, &
John R. Davis, "Multilevel Secure Mixed-Media
Communication Networks", Proceedings of the IEEE Military
Communications Conference (MILCOM '89), IEEE, 1989.
[Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", Technical
Report, 2 May 1996. (Presented at Rump Session of
Atkinson & Fanto [Page 18]
INTERNET-DRAFT 29 Sep 2005
EuroCrypt 1996.)
[Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack",
CryptoBytes, Vol. 2, No. 2, Summer 1996.
[ECS94] Eastlake 3rd, D, S. Crocker, & J. Schiller, "Randomness
Recommendations for Security", RFC-1750, December 1994.
[HA94] N. Haller & R. Atkinson, "On Internet Authentication",
RFC-1704, October 1994.
[KMC97] H. Krawczyk, M. Bellare, & R. Canetti, "Keyed-Hashing for
Message Authentication", RFC-2104, February 1997.
[Mal94] Malkin, G, "RIP version 2 - Carrying Additional
Information", RFC-1723, November 1994.
[MB94] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension",
RFC-1724, November 1994.
[MBW97] Murphy, S., M. Badger, and B. Wellington, "OSPF with
Digital Signatures", RFC-2154, June 1997.
[Rivest92] Rivest, R., "The MD5 Message-Digest Algorithm",
RFC-1321, April 1992.
Normative References
[Mal98] Malkin, G., "RIP Version 2", RFC-2453, November 1998.
[FIPS-180-2] US National Institute of Standards & Technology (NIST),
"Secure Hash Specification", US Federal Information Processing
Standard 180-2, NIST, Gaithersburg, MD, USA, 1 August 2002.
http://csrc.nist.gov/cryptval
[FIPS-198] US National Institute of Standards & Technology (NIST),
"The Keyed-Hash Message Authentication Code (HMAC)",
US Federal Information Processing Standard 198, NIST,
Gaithersburg, MD, USA, 6 March 2002.
http://csrc.nist.gov/cryptval
COPYRIGHT NOTICE
Copyright (C) The Internet Society (2005). 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.
Atkinson & Fanto [Page 19]
INTERNET-DRAFT 29 Sep 2005
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 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
R. Atkinson
Extreme Networks
3585 Monroe Street
Santa Clara, CA
USA 95051
Phone: +1 (408) 579-2800
EMail: rja@extremenetworks.com
M. Fanto
(US) National Institute of Standards and Technology
Gaithersburg, MD
USA 20878
Phone: +1 (301) 975-2000
Email: matthew.fanto@nist.gov
Web: http://csrc.nist.gov
Filename: draft-rja-ripv2-auth-02.txt
Expires: 29 March 2006
Atkinson & Fanto [Page 20]
