idnits 2.17.1 draft-ietf-ospf-md5-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 154 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 179: '... started) SHOULD be used. Since t...' RFC 2119 keyword, line 240: '...is specification SHOULD NOT be stored ...' RFC 2119 keyword, line 244: '... Implementations MUST support the stor...' RFC 2119 keyword, line 246: '...interface. They MUST associate a spec...' RFC 2119 keyword, line 250: '... identifier, and MUST support manual k...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1994) is 10784 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 359, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 361, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 364, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1583 (ref. '1') (Obsoleted by RFC 2178) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '2') ** Obsolete normative reference: RFC 1253 (ref. '3') (Obsoleted by RFC 1850) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 15 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRAFT OSPF MD5 Authentication October 1994 4 OSPF MD5 Authentication 5 draft-ietf-ospf-md5-02.txt 7 Fri Oct 14 09:40:36 PDT 1994 9 Fred Baker 10 Advanced Computer Communications 11 fbaker@acc.com 13 Randall Atkinson 14 Information Technology Division 15 Naval Research Laboratory 16 atkinson@itd.nrl.navy.mil 18 Status of this Memo 20 This document is an Internet Draft. Internet Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its Areas, and 22 its Working Groups. Note that other groups may also distribute working 23 documents as Internet Drafts. 25 Internet Drafts are valid for a maximum of six months and may be 26 updated, replaced, or obsoleted by other documents at any time. It is 27 inappropriate to use Internet Drafts as reference material or to cite 28 them other than as a "work in progress". 30 DRAFT OSPF MD5 Authentication October 1994 32 1. Introduction 34 Growth in the Internet has made us aware of the need for improved 35 authentication of routing information. OSPF provides two authentication 36 mechanisms for use in an area: "No Authentication" and "Simple 37 Password". Both are vulnerable to passive attacks currently widespread 38 in the Internet. Well-understood security issues exist in routing 39 protocols [4]. Clear text passwords, currently specified for use with 40 OSPF, are no longer considered sufficient [5]. 42 If authentication is disabled, then only simple misconfigurations are 43 detected. Simple passwords transmitted in the clear will further 44 protect against the honest neighbor, but are useless in the general 45 case. By simply capturing information on the wire - straightforward 46 even in a remote environment - a hostile process can learn the password 47 and overcome the network. 49 We propose that OSPF use an authentication algorithm, as in SNMP Version 50 2, augmented by a sequence number. MD5 is proposed as the standard 51 authentication algorithm for OSPF, but the mechanism is intended to be 52 algorithm-independent. While this mechanism is not unbreakable (no 53 known mechanism is), it provides a greatly enhanced probability that a 54 system being attacked will detect and ignore hostile messages. This is 55 because we transmit the output of an authentication algorithm (e.g., 56 MD5) rather than the secret OSPF Authentication Key. This output is a 57 one-way function of a message and a secret OSPF Authentication Key. 58 This OSPF Authentication Key is never sent over the network in the 59 clear, thus providing protection against the passive attacks now 60 commonplace in the Internet. 62 In this way, protection is afforded against forgery or message 63 modification. It is possible to replay a message until the sequence 64 number changes, but the sequence number makes replay in the long term 65 less of an issue. The mechanism does not afford confidentiality, since 66 messages stay in the clear; however, the mechanism is also exportable 67 from most countries, which test a privacy algorithm would fail. 69 Other relevant rationales for the approach are that MD5 is used in SNMP 70 Version 2, and is therefore present in routers already, as is some form 71 of password management. A similar approach has been proposed for 72 authentication in IP version 6 (IPv6). 74 DRAFT OSPF MD5 Authentication October 1994 76 2. Implementation Approach 78 Implementation requires three issues to be addressed: 80 (1) A changed packet format, 82 (2) Authentication procedures, and 84 (3) Management controls. 86 2.1. OSPF PDU Format 88 The basic OSPF message format provides for a 24 byte header with an 89 arbitrary data content. When MD5 is used, the same header and content 90 are used, except that the eight byte "authentication key" field is 91 reused to describe a "Keyed Message Digest" trailer. This consists in 92 five fields: 94 (1) The "Authentication Type" is Keyed Message Digest Algorithm, 95 indicated by the value 2. 97 (2) A 16 bit offset from the OSPF header to the MD5 digest (if no 98 other trailer fields are ever defined, this value equals the OSPF 99 Data Length). 101 (3) An unsigned 8-bit field that contains the Key Identifier or Key- 102 ID. This identifies the key used to create the Authentication 103 Data for this OSPF message. A key is associated with an 104 interface. 106 (4) An unsigned 8-bit field that contains the length in octets of the 107 trailing Authentication Data field. The presence of this field 108 permits other algorithms (e.g., SHA) to be substituted for MD5 if 109 desired. 111 (5) An unsigned 32 bit non-decreasing sequence number. 113 The trailer consists of the Authentication Data, which is the output of 114 the Keyed Message Digest Algorithm. When the Authentication Algorithm 115 is MD5, the output data is 16 bytes; during digest calculation, this is 116 effectively followed by a pad field and a length field as defined by RFC 117 1321. 119 DRAFT OSPF MD5 Authentication October 1994 121 2.2. Processing Algorithm 123 When the authentication type is "Keyed Message Digest", message 124 processing is changed in message creation and reception. 125 0 1 2 3 126 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 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Version # | type | OSPF Data Length | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Router ID | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Area ID | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Reserved - Must be Zero | AuType=Keyed Message Digest Fn| 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Reserved - Must be Zero | Key ID | Auth Data Len | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Sequence Number (non-decreasing) | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | | 141 / (OSPF Data Length-24) bytes Data / 142 | | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 / Authentication Data (var. length; 16 bytes when MD5 is used) / 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 In memory, the following trailer is appended by the MD5 algorithm and 148 treated as though it were part of the message. 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | zero or more pad bytes (defined by RFC 1321 when MD5 is used) | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | 64 bit message length MSW | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | 64 bit message length LSW | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 DRAFT OSPF MD5 Authentication October 1994 159 2.2.1. Message Generation 161 The OSPF Packet is created as usual, with these exceptions: 163 (1) The OSPF checksum is not calculated, but is set to zero. 165 (2) The authentication type field indicates the Keyed Message Digest 166 Algorithm (2). 168 (3) The authentication "password" field is reused to store a packet 169 offset to the Authentication Data, a Key Identifier, the 170 Authentication Data Length, and a non-decreasing sequence number. 172 The value used in the sequence number is arbitrary, but two suggestions 173 are the time of the message's creation or a simple message counter. 175 The OSPF Authentication Key is selected by the sender based on the 176 outgoing interface. Each key has a lifetime associated with it. No key 177 is ever used outside its lifetime. If more than one key is currently 178 alive, then the youngest key (the key whose lifetime most recently 179 started) SHOULD be used. Since the key's algorithm is an attribute of 180 the key, stored in the sender and receiver along with it, the Key ID 181 effectively indicates which authentication algorithm is in use if the 182 implementation supports more than one authentication algorithm. 184 (1) The OSPF header's packet length field indicates the standard OSPF 185 portion of the packet. 187 (2) The Authentication Data Offset, Key Identifier, and 188 Authentication Data size fields are filled in appropriately. 190 (3) The OSPF Authentication Key, which is 16 bytes long when the MD5 191 algorithm is used, is now appended to the data. For all 192 algorithms, the OSPF Authentication Key is never longer than the 193 output of the algorithm in use. 195 (4) Trailing pad and length fields are added and the digest 196 calculated using the indicated algorithm. When MD5 is the 197 algorithm in use, these are calculated per RFC 1321. 199 (5) The digest is written over the OSPF Authentication Key. When MD5 200 is used, this digest will be 16 bytes long. 202 The trailing pad is not actually transmitted, as it is entirely 203 predictable from the message length and algorithm in use. 205 DRAFT OSPF MD5 Authentication October 1994 207 2.2.2. Message Reception 209 When the message is received, the process is reversed: 211 (1) The OSPF Checksum is not calculated, 213 (2) The digest is set aside, 215 (3) The appropriate algorithm and key are determined from the value 216 of the Key Identifier field, 218 (4) The OSPF Authentication Key is written into the appropriate 219 number (16 when MD5 is used) of bytes starting at the offset 220 indicated, 222 (5) Appropriate padding is added as needed, and 224 (6) A new digest calculated using the indicated algorithm. 226 If the calculated digest does not match the received digest, the message 227 is discarded unprocessed. If the neighbor is in a state other than DOWN 228 or ATTEMPT and the received sequence number is less than the last one 229 received, the message likewise is discarded unprocessed. The received 230 sequence number must, of course, be stored by neighbor and zeroed upon a 231 "neighbor down" event. Acceptable messages are now truncated to "OSPF 232 Data Length" and treated normally. 234 3. Management Procedures 236 3.1. Key Management Requirements 238 It is strongly desirable that a hypothetical security breach in one 239 Internet protocol not automatically compromise other Internet protocols. 240 The Authentication Key of this specification SHOULD NOT be stored using 241 protocols or algorithms that have known flaws or fail to afford perfect 242 forward secrecy. 244 Implementations MUST support the storage of more than one key at the 245 same time, although it is recognized that only one key will normally be 246 active on an interface. They MUST associate a specific lifetime (i.e., 247 DRAFT OSPF MD5 Authentication October 1994 249 data/time first valid and data/time no longer valid) with each key, the 250 key identifier, and MUST support manual key distribution (e.g., the 251 privileged user manually typing in the key, key lifetime, and key 252 identifier on the router console). The lifetime may be infinite. If 253 more than one algorithm is supported, then the implementation MUST 254 require that the algorithm be specified for each key at the time the 255 other key information is entered. Keys that are out of date MAY be 256 deleted at will by the implementation without requiring human 257 intervention. Manual deletion of active keys SHOULD also be supported. 259 It is likely that the IETF will define a standard key management 260 protocol. It is strongly desirable to use that key management protocol 261 to distribute OSPF Authentication Keys among communicating OSPF 262 implementations. Such a protocol would provide scalability and 263 significantly reduce the human administrative burden. The Key ID can be 264 used as a hook between OSPF and such a future protocol. Key management 265 protocols have a long history of subtle flaws that are often discovered 266 long after the protocol was first described in public. To avoid having 267 to change all OSPF implementations should such a flaw be discovered, 268 integrated key management protocol techniques were deliberately omitted 269 from this specification. 271 3.2. Key Management Procedures 273 As with all security methods using keys, it is necessary to change the 274 OSPF Authentication Key on a regular basis. To maintain routing 275 stability during such changes, implementations are required to store and 276 support the use of more than one OSPF Authentication Key on a given 277 interface at the same time. 279 Each key will have its own Key Identifier, which is stored locally. The 280 combination of the Key Identifier and the interface associated with the 281 message uniquely identifies the Authentication Algorithm and OSPF 282 Authentication Key in use. 284 As noted above in Section 2.2.1, the party creating the OSPF message 285 will select a valid key from the set of valid keys for that interface. 286 The receiver will use the Key Identifier and interface to determine 287 which key to use for authentication of the received message. More than 288 one key may be associated with an interface at the same time. 290 Hence it is possible to have fairly smooth OSPF Authentication Key 291 rollovers without losing legitimate OSPF messages because the stored key 292 is incorrect and without requiring people to change all the keys at 293 once. To ensure a smooth rollover, each communicating OSPF system must 294 DRAFT OSPF MD5 Authentication October 1994 296 be updated with the new key several minutes before they current key will 297 expire and several minutes before the new key lifetime begins. The new 298 key should have a lifetime that starts several minutes before the old 299 key expires. This gives time for each system to learn of the new OSPF 300 Authentication Key before that key will be used. It also ensures that 301 the new key will begin being used and the current key will go out of use 302 before the current key's lifetime expires. For the duration of the 303 overlap in key lifetimes, a system may receive messages using either key 304 and authenticate the message. 306 3.3. Pathological Cases 308 Two pathological cases exist which must be handled, which are failures 309 of the network manager. Both of these should be exceedingly rare. 311 During key switchover, devices may exist which have not yet been 312 successfully configured with the new key. Therefore, routers MAY 313 implement (and would be well advised to implement) an algorithm that 314 detects the set of keys being used by its neighbors, and transmits its 315 messages using both the new and old keys until all of the neighbors are 316 using the new key or the lifetime of the old key expires. Under normal 317 circumstances, this elevated transmission rate will exist for a single 318 HELLO interval. 320 In the event that the last key associated with an interface expires, it 321 is unacceptable to revert to an unauthenticated condition, and not 322 advisable to disrupt routing. Therefore, the router should send a "last 323 authentication key expiration" notification to the network manager and 324 treat the key as having an infinite lifetime until the lfietime is 325 extended, the key is deleted by network management, or a new key is 326 configured. 328 4. Conformance Requirements 330 To conform to this specification, an implementation MUST support all of 331 its aspects. The MD5 authentication algorithm defined in RFC-1321 MUST 332 be implemented by all conforming implementations. A conforming 333 implementation MAY also support other authentication algorithms such as 334 NIST's Secure Hash Algorithm (SHA). Manual key distribution as 335 described above MUST be supported by all conforming implementations. 336 All implementations MUST support the smooth key rollover described under 337 "Key Change Procedures." 339 The user documentation provided with the implementation MUST contain 340 clear instructions on how to ensure that smooth key rollover occurs. 342 DRAFT OSPF MD5 Authentication October 1994 344 Implementations SHOULD support a standard key management protocol for 345 secure distribution of OSPF Authentication Keys once such a key 346 management protocol is standardized by the IETF. 348 5. Acknowledgments 350 This work was done by the OSPF Working Group, of which John Moy is the 351 Chair. This suggestion was originally made by Christian Huitema on 352 behalf of the IAB. Jeff Honig (Cornell) and Dennis Ferguson (ANS) built 353 the first operational prototype, proving out the algorithms. The 354 authors gladly acknowledge significant inputs from each of these 355 sources. 357 6. References 359 [1] Moy, John, "OSPF Version 2", RFC 1583, March 1994. 361 [2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 362 1992. 364 [3] F. Baker, R. Coltun, "OSPF Version 2 Management Information 365 Base", RFC 1253, August 1991 367 [4] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM 368 Computer Communications Review, Volume 19, Number 2, pp.32-48, 369 April 1989. 371 [5] N. Haller, R. Atkinson, "Internet Authentication Guidelines", 372 RFC-XXXX (already submitted to RFC Editor), September 1994. 374 7. Security Considerations 376 This entire memo describes and specifies an authentication mechanism for 377 the OSPF routing protocol that is believed to be secure against active 378 and passive attacks. Passive attacks are clearly widespread in the 379 Internet at present. Protection against active attacks is also needed 380 even though such attacks are not currently widespread. 382 Users need to understand that the quality of the security provided by 383 this mechanism depends completely on the strength of the implemented 384 authentication algorithms, the strength of the key being used, and the 385 correct implementation of the security mechanism in all communicating 386 OSPF implementations. This mechanism also depends on the OSPF 387 DRAFT OSPF MD5 Authentication October 1994 389 Authentication Key being kept confidential by all parties. If any of 390 these incorrect or insufficiently secure, then no real security will be 391 provided to the users of this mechanism. 393 Specifically with respect to the use of SNMP, compromise of SNMP 394 security has the necessary result that the various OSPF configuration 395 parameters (e.g. routing table, OSPF Authentication Key) managable via 396 SNMP could be compromised as well. Changing Authentication Keys using 397 non-encrypted SNMP is no more secure than sending passwords in the 398 clear. 400 Confidentiality is not provided by this mechanism. Work is underway 401 within the IETF to specify a standard mechanism for IP-layer encryption. 402 That mechanism might be used to provide confidentiality for OSPF in the 403 future. Protection against traffic analysis is also not provided. 404 Mechanisms such as bulk link encryption might be used when protection 405 against traffic analysis is required. 407 The memo is written to address a security consideration in OSPF Version 408 2 that was raised during the IAB's recent security review [cite RFC 409 here]. 411 8. Author's Address 413 Fred Baker 414 Cisco Systems 415 519 Lado Drive 416 Santa Barbara, California 93111 417 Phone: (805) 964 8007 418 Email: fred@cisco.com 420 Randall Atkinson 421 Information Technology Division 422 Naval Research Laboratory 423 Washington, DC 20375-5320 424 Voice: (DSN) 354-8590 425 Fax: (DSN) 354-7942 426 Email: atkinson@itd.nrl.navy.mil 427 DRAFT OSPF MD5 Authentication October 1994 429 Table of Contents 431 1 Introduction .................................................... 2 432 2 Implementation Approach ......................................... 3 433 2.1 OSPF PDU Format ............................................... 3 434 2.2 Processing Algorithm .......................................... 4 435 2.2.1 Message Generation .......................................... 5 436 2.2.2 Message Reception ........................................... 6 437 3 Management Procedures ........................................... 6 438 3.1 Key Management Requirements ................................... 6 439 3.2 Key Management Procedures ..................................... 7 440 3.3 Pathological Cases ............................................ 8 441 4 Conformance Requirements ........................................ 8 442 5 Acknowledgments ................................................. 9 443 6 References ...................................................... 9 444 7 Security Considerations ......................................... 9 445 8 Author's Address ................................................ 10