draft-ietf-ospf-md5-01.txt   draft-ietf-ospf-md5-02.txt 
DRAFT OSPF MD5 Authentication September 1994 DRAFT OSPF MD5 Authentication October 1994
OSPF MD5 Authentication OSPF MD5 Authentication
draft-ietf-ospf-md5-01.txt draft-ietf-ospf-md5-02.txt
Tue Sep 6 14:53:55 PDT 1994 Fri Oct 14 09:40:36 PDT 1994
Fred Baker Fred Baker
Advanced Computer Communications Advanced Computer Communications
fbaker@acc.com fbaker@acc.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 OSPF MD5 Authentication September 1994 DRAFT OSPF MD5 Authentication October 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. OSPF provides two authentication authentication of routing information. OSPF provides two authentication
mechanisms for use in an area: "No Authentication" and "Simple mechanisms for use in an area: "No Authentication" and "Simple
Password". Both are vulnerable to passive attacks currently widespread Password". Both are vulnerable to passive attacks currently widespread
in the Internet. Well-understood security issues exist in routing in the Internet. Well-understood security issues exist in routing
protocols [4]. Clear text passwords, currently specified for use with protocols [4]. Clear text passwords, currently specified for use with
OSPF, are no longer considered sufficient [5]. OSPF, 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 privacy algorithm would fail. from most countries, which test a privacy 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 OSPF MD5 Authentication September 1994 DRAFT OSPF MD5 Authentication October 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.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
desired. desired.
(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. 1321.
DRAFT OSPF MD5 Authentication September 1994 DRAFT OSPF MD5 Authentication October 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 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | type | OSPF Data Length | | Version # | type | OSPF Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID | | Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID | | Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType=Keyed Message Digest Fn| | Reserved - Must be Zero | AuType=Keyed Message Digest Fn|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| offset to MD5 digest | Key ID | Auth Data Len | | Reserved - Must be Zero | Key ID | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| non-decreasing sequence number | | Sequence Number (non-decreasing) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ (OSPF Data Length-24) bytes Data / / (OSPF Data Length-24) bytes Data /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Authentication Data (var. length; 16 bytes when MD5 is used) / / Authentication Data (var. length; 16 bytes when MD5 is used) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In memory, the following trailer is appended by the MD5 algorithm and In memory, the following trailer is appended by the MD5 algorithm and
treated as though it were part of the message. treated as though it were part of the message.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 OSPF MD5 Authentication September 1994 DRAFT OSPF MD5 Authentication October 1994
2.2.1. Message Generation 2.2.1. Message Generation
The OSPF Packet is created as usual, with these exceptions: The OSPF Packet is created as usual, with these exceptions:
(1) The OSPF checksum is not calculated, but is set to zero. (1) The OSPF checksum is not calculated, but is 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
(4) Trailing pad and length fields are added and the digest (4) Trailing pad and length fields are added and the digest
calculated using the indicated algorithm. When MD5 is the calculated using the indicated algorithm. When MD5 is the
algorithm in use, these are calculated per RFC 1321. algorithm in use, these are calculated per RFC 1321.
(5) The digest is written over the OSPF Authentication Key. When MD5 (5) The digest is written over the OSPF Authentication Key. When MD5
is used, this digest will be 16 bytes long. is used, this digest will be 16 bytes long.
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.
DRAFT OSPF MD5 Authentication September 1994 DRAFT OSPF MD5 Authentication October 1994
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 OSPF Checksum is not calculated, (1) The OSPF Checksum is not calculated,
(2) The digest is set aside, (2) The digest is set aside,
(3) The appropriate algorithm and key are determined from the value (3) The appropriate algorithm and key are determined from the value
skipping to change at page 6, line 36 skipping to change at page 6, line 36
If the calculated digest does not match the received digest, the message If the calculated digest does not match the received digest, the message
is discarded unprocessed. If the neighbor is in a state other than DOWN is discarded unprocessed. If the neighbor is in a state other than DOWN
or ATTEMPT and the received sequence number is less than the last one or ATTEMPT and the received sequence number is less than the last one
received, the message likewise is discarded unprocessed. The received received, the message likewise is discarded unprocessed. The received
sequence number must, of course, be stored by neighbor and zeroed upon a sequence number must, of course, be stored by neighbor and zeroed upon a
"neighbor down" event. Acceptable messages are now truncated to "OSPF "neighbor down" event. Acceptable messages are now truncated to "OSPF
Data Length" and treated normally. Data Length" and treated normally.
3. Management Procedures 3. Management Procedures
3.1. Use of SNMP in Key Management 3.1. Key Management Requirements
It is strongly desirable that a hypothetical security breach in one It is strongly desirable that a hypothetical security breach in one
Internet protocol not automatically compromise other Internet protocols. Internet protocol not automatically compromise other Internet protocols.
Also, the default method for changing SNMP Version 2 encryption keys The Authentication Key of this specification SHOULD NOT be stored using
does not provide the property of perfect forward secrecy. Therefore, protocols or algorithms that have known flaws or fail to afford perfect
the OSPF Authentication key of this specification SHOULD NOT be stored forward secrecy.
using SNMP.
3.2. Key Management Requirements
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. They MUST associate a specific lifetime (i.e., data/time same time, although it is recognized that only one key will normally be
first valid and data/time no longer valid) with each key, the key active on an interface. They MUST associate a specific lifetime (i.e.,
identifier, and MUST support manual key distribution (e.g., the DRAFT OSPF MD5 Authentication October 1994
privileged user manually typing in the key, key lifetime, and key
DRAFT OSPF MD5 Authentication September 1994
identifier on the router console). If more than one algorithm is data/time first valid and data/time no longer valid) with each key, the
supported, then the implementation MUST require that the algorithm be key identifier, and MUST support manual key distribution (e.g., the
specified for each key at the time the other key information is entered. privileged user manually typing in the key, key lifetime, and key
Keys that are out of date MAY be deleted at will by the implementation identifier on the router console). The lifetime may be infinite. If
without requiring human intervention. 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.
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 OSPF Authentication Keys among communicating OSPF to distribute OSPF Authentication Keys among communicating OSPF
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 OSPF and such a future protocol. Key management used as a hook between OSPF and such a future protocol. Key management
protocols have a long history of subtle flaws that are often discovered protocols have a long history of subtle flaws that are often discovered
long after the protocol was first described in public. To avoid having long after the protocol was first described in public. To avoid having
to change all OSPF implementations should such a flaw be discovered, to change all OSPF implementations should such a flaw be discovered,
integrated key management protocol techniques were deliberately omitted integrated key management protocol techniques were deliberately omitted
from this specification. from this specification.
3.3. Key Management Procedures 3.2. Key Management Procedures
As with all security methods using keys, it is necessary to change the As with all security methods using keys, it is necessary to change the
OSPF Authentication Key on a regular basis. To maintain routing OSPF Authentication Key on a regular basis. To maintain routing
stability during such changes, implementations are required to store and stability during such changes, implementations are required to store and
support the use of more than one OSPF Authentication Key on a given support the use of more than one OSPF Authentication Key on a given
interface at the same time. interface at the same time.
Each key will have its own Key Identifier, which is stored locally. The Each key will have its own Key Identifier, which is stored locally. The
combination of the Key Identifier and the interface associated with the combination of the Key Identifier and the interface associated with the
message uniquely identifies the Authentication Algorithm and OSPF message uniquely identifies the Authentication Algorithm and OSPF
skipping to change at page 7, line 47 skipping to change at page 8, line 4
As noted above in Section 2.2.1, the party creating the OSPF message As noted above in Section 2.2.1, the party creating the OSPF message
will select a valid key from the set of valid keys for that interface. will select a valid key from the set of valid keys for that interface.
The receiver will use the Key Identifier and interface to determine The receiver will use the Key Identifier and interface to determine
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 OSPF Authentication Key Hence it is possible to have fairly smooth OSPF Authentication Key
rollovers without losing legitimate OSPF messages because the stored key rollovers without losing legitimate OSPF messages because the stored key
is incorrect and without requiring people to change all the keys at is incorrect and without requiring people to change all the keys at
once. To ensure a smooth rollover, each communicating OSPF system must once. To ensure a smooth rollover, each communicating OSPF system must
DRAFT OSPF MD5 Authentication October 1994
be updated with the new key several minutes before they current key will be updated with the new key several minutes before they current key will
expire and several minutes before the new key lifetime begins. The new 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 should have a lifetime that starts several minutes before the old
key expires. This gives time for each system to learn of the new OSPF key expires. This gives time for each system to learn of the new OSPF
DRAFT OSPF MD5 Authentication September 1994
Authentication Key before that key will be used. It also ensures that 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 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 before the current key's lifetime expires. For the duration of the
overlap in key lifetimes, a system may receive messages using either key overlap in key lifetimes, a system may receive messages using either key
and authenticate the message. and authenticate the message.
3.3. Pathological Cases
Two pathological cases exist which must be handled, which are failures
of the network manager. Both of these should be exceedingly rare.
During key switchover, devices may exist which have not yet been
successfully configured with the new key. Therefore, routers MAY
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
HELLO interval.
In the event that the last key associated with an interface expires, 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 lfietime is
extended, the key is deleted by network management, or a new key is
configured.
4. Conformance Requirements 4. Conformance Requirements
To conform to this specification, an implementation MUST support all of To conform to this specification, an implementation MUST support all of
its aspects. The MD5 authentication algorithm defined in RFC-1321 MUST its aspects. The MD5 authentication algorithm defined in RFC-1321 MUST
be implemented by all conforming implementations. A conforming be implemented by all conforming implementations. A conforming
implementation MAY also support other authentication algorithms such as implementation MAY also support other authentication algorithms such as
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.S "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.
DRAFT OSPF MD5 Authentication October 1994
Implementations SHOULD support a standard key management protocol for Implementations SHOULD support a standard key management protocol for
secure distribution of OSPF Authentication Keys once such a key secure distribution of OSPF Authentication Keys once such a key
management protocol is standardized by the IETF. management protocol is standardized by the IETF.
5. Acknowledgments 5. Acknowledgments
This work was done by the OSPF Working Group, of which John Moy is the This work was done by the OSPF Working Group, of which John Moy is the
Chair. This suggestion was originally made by Christian Huitema on 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
skipping to change at page 9, line 4 skipping to change at page 9, line 29
6. References 6. References
[1] Moy, John, "OSPF Version 2", RFC 1583, March 1994. [1] Moy, John, "OSPF Version 2", RFC 1583, March 1994.
[2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April [2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992. 1992.
[3] F. Baker, R. Coltun, "OSPF Version 2 Management Information [3] F. Baker, R. Coltun, "OSPF Version 2 Management Information
Base", RFC 1253, August 1991 Base", RFC 1253, August 1991
DRAFT OSPF MD5 Authentication September 1994
[4] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM [4] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM
Computer Communications Review, Volume 19, Number 2, pp.32-48, Computer Communications Review, Volume 19, Number 2, pp.32-48,
April 1989. April 1989.
[5] N. Haller, R. Atkinson, "Internet Authentication Guidelines", [5] N. Haller, R. Atkinson, "Internet Authentication Guidelines",
RFC-XXXX (already submitted to RFC Editor), September 1994. RFC-XXXX (already submitted to RFC Editor), September 1994.
7. Security Considerations 7. Security Considerations
skipping to change at page 9, line 26 skipping to change at page 10, line 4
the OSPF routing protocol that is believed to be secure against active the OSPF 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.
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
OSPF implementations. This mechanism also depends on the OSPF OSPF implementations. This mechanism also depends on the OSPF
DRAFT OSPF MD5 Authentication October 1994
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
security has the necessary result that the various OSPF configuration
parameters (e.g. routing table, OSPF Authentication Key) managable via
SNMP could be compromised as well. Changing Authentication Keys using
non-encrypted SNMP is no more secure than sending passwords in the
clear.
Confidentiality is not provided by this mechanism. Work is underway Confidentiality is not provided by this mechanism. Work is underway
within the IETF to specify a standard mechanism for IP-layer encryption. within the IETF to specify a standard mechanism for IP-layer encryption.
That mechanism might be used to provide confidentiality for OSPF in the That mechanism might be used to provide confidentiality for OSPF in the
future. Protection against traffic analysis is also not provided. future. Protection against traffic analysis is also not provided.
Mechanisms such as bulk link encryption might be used when protection Mechanisms such as bulk link encryption might be used when protection
against traffic analysis is required. against traffic analysis is required.
The memo is written to address a security consideration in OSPF Version The memo is written to address a security consideration in OSPF Version
2 that was raised during the IAB's recent security review [cite RFC 2 that was raised during the IAB's recent security review [cite RFC
here]. here].
8. Author's Address 8. Author's Address
Fred Baker Fred Baker
Advanced Computer Communications Cisco Systems
315 Bollay Drive 519 Lado Drive
Santa Barbara, California 93117 Santa Barbara, California 93111
Phone: (805) 685 4455 Phone: (805) 964 8007
Email: fbaker@acc.com Email: fred@cisco.com
Randall Atkinson Randall Atkinson
DRAFT OSPF MD5 Authentication September 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 OSPF MD5 Authentication September 1994 DRAFT OSPF MD5 Authentication October 1994
Table of Contents Table of Contents
1 Introduction .................................................... 2 1 Introduction .................................................... 2
2 Implementation Approach ......................................... 3 2 Implementation Approach ......................................... 3
2.1 OSPF PDU Format ............................................... 3 2.1 OSPF 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 Use of SNMP in Key Management ................................. 6 3.1 Key Management Requirements ................................... 6
3.2 Key Management Requirements ................................... 6 3.2 Key Management Procedures ..................................... 7
3.3 Key Management Procedures ..................................... 7 3.3 Pathological Cases ............................................ 8
4 Conformance Requirements ........................................ 8 4 Conformance Requirements ........................................ 8
5 Acknowledgments ................................................. 8 5 Acknowledgments ................................................. 9
6 References ...................................................... 8 6 References ...................................................... 9
7 Security Considerations ......................................... 9 7 Security Considerations ......................................... 9
8 Author's Address ................................................ 9 8 Author's Address ................................................ 10
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/