draft-ietf-ripv2-md5-00.txt   draft-ietf-ripv2-md5-01.txt 
RIP-II Cryptographic Authentication |
draft-ietf-ripv2-md5-01.txt |
DRAFT RIP-II Cryptographic Authentication November 1994 Fri Mar 17 11:41:29 PST 1995
RIP-II Cryptographic Authentication
draft-ietf-ripv2-md5-00.txt
Thu Nov 10 08:50:59 PST 1994
Fred Baker Fred Baker
Cisco Systems Cisco Systems
fred@cisco.com fred@cisco.com
Randall Atkinson Randall Atkinson
Information Technology Division Information Technology Division
Naval Research Laboratory Naval Research Laboratory
atkinson@itd.nrl.navy.mil atkinson@itd.nrl.navy.mil
skipping to change at page 2, line 5 skipping to change at page 2, line 5
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working its Working Groups. Note that other groups may also distribute working
documents as Internet Drafts. documents as Internet Drafts.
Internet Drafts are valid for a maximum of six months and may be Internet Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It is updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet Drafts as reference material or to cite inappropriate to use Internet Drafts as reference material or to cite
them other than as a "work in progress". them other than as a "work in progress".
DRAFT RIP-II Cryptographic Authentication November 1994
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. RIP-II provides for authentication of routing information. RIP-II 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 [4]. Clear text passwords, currently specified for routing protocols [4]. Clear text passwords, currently specified for
use with RIP-II, are no longer considered sufficient [5]. use with RIP-II, are no longer considered sufficient [5].
skipping to change at page 3, line 5 skipping to change at page 3, line 5
number changes, but the sequence number makes replay in the long term number changes, but the sequence number makes replay in the long term
less of an issue. The mechanism does not afford confidentiality, since less of an issue. The mechanism does not afford confidentiality, since
messages stay in the clear; however, the mechanism is also exportable messages stay in the clear; however, the mechanism is also exportable
from most countries, which test a confidentiality algorithm would fail. from most countries, which test a confidentiality algorithm would fail.
Other relevant rationales for the approach are that MD5 is used in SNMP Other relevant rationales for the approach are that MD5 is used in SNMP
Version 2, and is therefore present in routers already, as is some form Version 2, and is therefore present in routers already, as is some form
of password management. A similar approach has been proposed for of password management. A similar approach has been proposed for
authentication in IP version 6 (IPv6). authentication in IP version 6 (IPv6).
DRAFT RIP-II Cryptographic Authentication November 1994
2. Implementation Approach 2. Implementation Approach
Implementation requires three issues to be addressed: Implementation requires three issues to be addressed:
(1) A changed packet format, (1) A changed packet format,
(2) Authentication procedures, and (2) Authentication procedures, and
(3) Management controls. (3) Management controls.
2.1. RIP-II PDU Format 2.1. RIP-II PDU Format
The basic RIP-II message format provides for a 4 byte header with an The basic RIP-II message format provides for an 8 byte header with an
array of 20 byte records as its data content. When MD5 is used, the array of 20 byte records as its data content. When MD5 is used, the
same header and content are used, except that the 16 byte same header and content are used, except that the 16 byte
"authentication key" field is reused to describe a "Keyed Message "authentication key" field is reused to describe a "Keyed Message
Digest" trailer. This consists in five fields: Digest" trailer. This consists in five fields:
(1) The "Authentication Type" is Keyed Message Digest Algorithm, (1) The "Authentication Type" is Keyed Message Digest Algorithm,
indicated by the value 3 (1 and 2 indicate "IP Route" and indicated by the value 3 (1 and 2 indicate "IP Route" and
"Password", respectively). "Password", respectively).
(2) A 16 bit offset from the RIP-II header to the record containing the (2) A 16 bit offset from the RIP-II header to the record containing the
skipping to change at page 4, line 5 skipping to change at page 4, line 5
(5) An unsigned 32 bit non-decreasing sequence number. (5) An unsigned 32 bit non-decreasing sequence number.
The trailer consists of the Authentication Data, which is the output of The trailer consists of the Authentication Data, which is the output of
the Keyed Message Digest Algorithm. When the Authentication Algorithm the Keyed Message Digest Algorithm. When the Authentication Algorithm
is MD5, the output data is 16 bytes; during digest calculation, this is is 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 effectively followed by a pad field and a length field as defined by RFC
1321. The field is contained in a record reminiscient of other 1321. The field is contained in a record reminiscient of other
entiries, to be kind to ancient RIP implementations, but the actual entiries, to be kind to ancient RIP implementations, but the actual
length of the digest varies by algorithm. length of the digest varies by algorithm.
DRAFT RIP-II Cryptographic Authentication November 1994
2.2. Processing Algorithm 2.2. Processing Algorithm
When the authentication type is "Keyed Message Digest", message When the authentication type is "Keyed Message Digest", message
processing is changed in message creation and reception. processing is changed in message creation and reception.
0 1 2 3 3 0 1 2 3 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 | AuType=Keyed Message Digest | | 0xFFFF | AuType=Keyed Message Digest |
skipping to change at page 5, line 5 skipping to change at page 5, line 5
packet during the MD5 calculation. packet during the MD5 calculation.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more pad bytes (defined by RFC 1321 when MD5 is used) | | zero or more pad bytes (defined by RFC 1321 when MD5 is used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 bit message length MSW | | 64 bit message length MSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 bit message length LSW | | 64 bit message length LSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DRAFT RIP-II Cryptographic Authentication November 1994
2.2.1. Message Generation 2.2.1. Message Generation
The RIP-II Packet is created as usual, with these exceptions: The RIP-II Packet is created as usual, with these exceptions:
(1) The UDP checksum need not be calculated. If it is not, it MUST be (1) The UDP checksum need not be calculated. If it is not, it MUST be
set to zero. set to zero.
(2) The authentication type field indicates the Keyed Message Digest (2) The authentication type field indicates the Keyed Message Digest
Algorithm (2). Algorithm (2).
skipping to change at page 6, line 5 skipping to change at page 6, line 5
algorithms, the RIP-II Authentication Key is never longer than the algorithms, the RIP-II Authentication Key is never longer than the
output of the algorithm in use. output of the algorithm in use.
(4) Trailing pad and length fields are added and the digest calculated (4) Trailing pad and length fields are added and the digest calculated
using the indicated algorithm. When MD5 is the algorithm in use, using the indicated algorithm. When MD5 is the algorithm in use,
these are calculated per RFC 1321. these are calculated per RFC 1321.
(5) The digest is written over the RIP-II Authentication Key. When MD5 (5) The digest is written over the RIP-II Authentication Key. When MD5
is used, this digest will be 16 bytes long. is used, this digest will be 16 bytes long.
DRAFT RIP-II Cryptographic Authentication November 1994
The trailing pad is not actually transmitted, as it is entirely The trailing pad is not actually transmitted, as it is entirely
predictable from the message length and algorithm in use. predictable from the message length and algorithm in use.
2.2.2. Message Reception 2.2.2. Message Reception
When the message is received, the process is reversed: When the message is received, the process is reversed:
(1) The digest is set aside, (1) The digest is set aside,
(2) The appropriate algorithm and key are determined from the value of (2) The appropriate algorithm and key are determined from the value of
skipping to change at page 7, line 5 skipping to change at page 7, line 5
protocols or algorithms that have known flaws or fail to afford perfect protocols or algorithms that have known flaws or fail to afford perfect
forward secrecy. forward secrecy.
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 be 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., active on an interface. They MUST associate a specific lifetime (i.e.,
data/time first valid and data/time no longer valid) and a key data/time first valid and data/time no longer valid) and a key
identifier with each key, and MUST support manual key distribution identifier with each key, and MUST support manual key distribution
(e.g., the privileged user manually typing in the key, key lifetime, and (e.g., the privileged user manually typing in the key, key lifetime, and
DRAFT RIP-II Cryptographic Authentication November 1994
key identifier on the router console). The lifetime may be infinite. key identifier on the router console). The lifetime may be infinite.
If more than one algorithm is supported, then the implementation MUST If more than one algorithm is supported, then the implementation MUST
require that the algorithm be specified for each key at the time the 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 other key information is entered. Keys that are out of date MAY be
deleted at will by the implementation without requiring human deleted at will by the implementation without requiring human
intervention. Manual deletion of active keys SHOULD also be supported. intervention. Manual deletion of active keys SHOULD also be supported.
Note that there are four "times" that are important with respect to a
key:
+ The time the system starts accepting received packets signed with |
the key (KeyStartReceive).
+ The time the system starts signing packets with the key |
(KeyStartSign).
+ The time the system stops signing packets with the key, which is to |
say, the time it starts signing with the next key (KeyStopSign).
+ The time the system stops accepting received packets signed with the |
key (KeyStopReceive).
The times SHOULD be in the order listed, which is to say that none of
these times occurs before the one mentioned before it. There needs to
be some distance between starts and between stops in order to get a
seamless transition. Each system sends with whichever key has the most
recent "start" time, and makes its first attempt at validation of
incoming traffic with the same key. If this validation fails and |
another (older) key is also active, the system should attempt to |
validate with any other active keys it may possess.
Note that the concept of a "key lifetime" does not require a hardware
time of day clock or the use of NTP, although one or the other is
advised; it merely requires that the earliest and latest times that the
key is valid must be programmable in a way the router understands.
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. It is strongly desirable to use that key management protocol protocol. It is strongly desirable to use that key management protocol
to distribute RIP-II Authentication Keys among communicating RIP-II to distribute RIP-II Authentication Keys among communicating RIP-II
implementations. Such a protocol would provide scalability and implementations. Such a protocol would provide scalability and
significantly reduce the human administrative burden. The Key ID can be significantly reduce the human administrative burden. The Key ID can be
used as a hook between RIP-II and such a future protocol. Key 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 management protocols have a long history of subtle flaws that are often
discovered long after the protocol was first described in public. To discovered long after the protocol was first described in public. To
avoid having to change all RIP-II implementations should such a flaw be avoid having to change all RIP-II implementations should such a flaw be
discovered, integrated key management protocol techniques were discovered, integrated key management protocol techniques were
skipping to change at page 8, line 4 skipping to change at page 8, line 31
which key to use for authentication of the received message. More than which key to use for authentication of the received message. More than
one key may be associated with an interface at the same time. one key may be associated with an interface at the same time.
Hence it is possible to have fairly smooth RIP-II Authentication Key Hence it is possible to have fairly smooth RIP-II Authentication Key
rollovers without losing legitimate RIP-II messages because the stored rollovers without losing legitimate RIP-II messages because the stored
key is incorrect and without requiring people to change all the keys at key is incorrect and without requiring people to change all the keys at
once. To ensure a smooth rollover, each communicating RIP-II system once. To ensure a smooth rollover, each communicating RIP-II system
must be updated with the new key several minutes before they current key must be updated with the new key several minutes before they current key
will expire and several minutes before the new key lifetime begins. The will expire and several minutes before the new key lifetime begins. The
new key should have a lifetime that starts several minutes before the new key should have a lifetime that starts several minutes before the
DRAFT RIP-II Cryptographic Authentication November 1994
old key expires. This gives time for each system to learn of the new old key expires. This gives time for each system to learn of the new
RIP-II Authentication Key before that key will be used. It also ensures RIP-II 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 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 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 the overlap in key lifetimes, a system may receive messages using either
key and authenticate the message. key and authenticate the message.
Key storage SHOULD persist across a system restart, warm or cold, to
avoid operational issues. Key lifetime is an obvious issue, to be
solved by the implementation. Obvious solutions include the use of the
Network Time Protocol, hardware time of day clocks, or waiting some
period of time before emitting the initial RIP REQUEST to determine what
key other systems are signing with. The matter is left for the
implementor.
3.3. Pathological Cases 3.3. Pathological Cases
Two pathological cases exist which must be handled, which are failures Two pathological cases exist which must be handled, which are failures
of the network manager. Both of these should be exceedingly rare. of the network manager. Both of these should be exceedingly rare.
During key switchover, devices may exist which have not yet been During key switchover, devices may exist which have not yet been
successfully configured with the new key. Therefore, routers MAY successfully configured with the new key. Therefore, routers MAY
implement (and would be well advised to implement) an algorithm that implement (and would be well advised to implement) an algorithm that
detects the set of keys being used by its neighbors, and transmits its 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 messages using both the new and old keys until all of the neighbors are
skipping to change at page 9, line 4 skipping to change at page 9, line 38
NIST's Secure Hash Algorithm (SHA). Manual key distribution as NIST's Secure Hash Algorithm (SHA). Manual key distribution as
described above MUST be supported by all conforming implementations. described above MUST be supported by all conforming implementations.
All implementations MUST support the smooth key rollover described under All implementations MUST support the smooth key rollover described under
"Key Change Procedures." "Key Change Procedures."
The user documentation provided with the implementation MUST contain The user documentation provided with the implementation MUST contain
clear instructions on how to ensure that smooth key rollover occurs. clear instructions on how to ensure that smooth key rollover occurs.
Implementations SHOULD support a standard key management protocol for Implementations SHOULD support a standard key management protocol for
secure distribution of RIP-II Authentication Keys once such a key secure distribution of RIP-II Authentication Keys once such a key
DRAFT RIP-II Cryptographic Authentication November 1994
management protocol is standardized by the IETF. management protocol is standardized by the IETF.
5. Acknowledgments 5. Acknowledgments
This work was done by the RIP-II Working Group, of which Gary Malkin is This work was done by the RIP-II Working Group, of which Gary Malkin is
the Chair. This suggestion was originally made by Christian Huitema on the Chair. This suggestion was originally made by Christian Huitema on
behalf of the IAB. Jeff Honig (Cornell) and Dennis Ferguson (ANS) built behalf of the IAB. Jeff Honig (Cornell) and Dennis Ferguson (ANS) built
the first operational prototype, proving out the algorithms. The the first operational prototype, proving out the algorithms. The
authors gladly acknowledge significant inputs from each of these authors gladly acknowledge significant inputs from each of these
sources. sources.
skipping to change at page 10, line 5 skipping to change at page 10, line 35
Comments 1636, DDN Network Information Center, June 1994. Comments 1636, DDN Network Information Center, June 1994.
7. Security Considerations 7. Security Considerations
This entire memo describes and specifies an authentication mechanism for This entire memo describes and specifies an authentication mechanism for
the RIP-II routing protocol that is believed to be secure against active the RIP-II routing protocol that is believed to be secure against active
and passive attacks. Passive attacks are clearly widespread in the and passive attacks. Passive attacks are clearly widespread in the
Internet at present. Protection against active attacks is also needed Internet at present. Protection against active attacks is also needed
even though such attacks are not currently widespread. even though such attacks are not currently widespread.
DRAFT RIP-II Cryptographic Authentication November 1994
Users need to understand that the quality of the security provided by Users need to understand that the quality of the security provided by
this mechanism depends completely on the strength of the implemented this mechanism depends completely on the strength of the implemented
authentication algorithms, the strength of the key being used, and the authentication algorithms, the strength of the key being used, and the
correct implementation of the security mechanism in all communicating correct implementation of the security mechanism in all communicating
RIP-II implementations. This mechanism also depends on the RIP-II RIP-II implementations. This mechanism also depends on the RIP-II
Authentication Key being kept confidential by all parties. If any of Authentication Key being kept confidential by all parties. If any of
these incorrect or insufficiently secure, then no real security will be these incorrect or insufficiently secure, then no real security will be
provided to the users of this mechanism. provided to the users of this mechanism.
Specifically with respect to the use of SNMP, compromise of SNMP Specifically with respect to the use of SNMP, compromise of SNMP
skipping to change at page 11, line 4 skipping to change at page 11, line 36
9. Author's Address 9. Author's Address
Fred Baker Fred Baker
Cisco Systems Cisco Systems
519 Lado Drive 519 Lado Drive
Santa Barbara, California 93111 Santa Barbara, California 93111
Phone: (805) 681 0115 Phone: (805) 681 0115
Email: fred@cisco.com Email: fred@cisco.com
Randall Atkinson Randall Atkinson
DRAFT RIP-II Cryptographic Authentication November 1994
Information Technology Division Information Technology Division
Naval Research Laboratory Naval Research Laboratory
Washington, DC 20375-5320 Washington, DC 20375-5320
Voice: (DSN) 354-8590 Voice: (DSN) 354-8590
Fax: (DSN) 354-7942 Fax: (DSN) 354-7942
Email: atkinson@itd.nrl.navy.mil Email: atkinson@itd.nrl.navy.mil
DRAFT RIP-II Cryptographic Authentication November 1994
Table of Contents Table of Contents
1 Introduction .................................................... 2 1 Introduction .................................................... 2
2 Implementation Approach ......................................... 3 2 Implementation Approach ......................................... 3
2.1 RIP-II PDU Format ............................................. 3 2.1 RIP-II PDU Format ............................................. 3
2.2 Processing Algorithm .......................................... 4 2.2 Processing Algorithm .......................................... 4
2.2.1 Message Generation .......................................... 5 2.2.1 Message Generation .......................................... 5
2.2.2 Message Reception ........................................... 6 2.2.2 Message Reception ........................................... 6
3 Management Procedures ........................................... 6 3 Management Procedures ........................................... 6
3.1 Key Management Requirements ................................... 6 3.1 Key Management Requirements ................................... 6
3.2 Key Management Procedures ..................................... 7 3.2 Key Management Procedures ..................................... 8
3.3 Pathological Cases ............................................ 8 3.3 Pathological Cases ............................................ 8
4 Conformance Requirements ........................................ 8 4 Conformance Requirements ........................................ 9
5 Acknowledgments ................................................. 9 5 Acknowledgments ................................................. 9
6 References ...................................................... 9 6 References ...................................................... 10
7 Security Considerations ......................................... 9 7 Security Considerations ......................................... 10
8 Chairman's Address .............................................. 10 8 Chairman's Address .............................................. 11
9 Author's Address ................................................ 10 9 Author's Address ................................................ 11
 End of changes. 19 change blocks. 
34 lines changed or deleted 40 lines changed or added

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