idnits 2.17.1 draft-ietf-ospf-md5-01.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-27) 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 141 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 242: '...his specification SHOULD NOT be stored...' RFC 2119 keyword, line 247: '... Implementations MUST support the stor...' RFC 2119 keyword, line 248: '...same time. They MUST associate a spec...' RFC 2119 keyword, line 250: '... identifier, and MUST support manual k...' (9 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 (September 1994) is 10817 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 336, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 338, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 341, 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 September 1994 4 OSPF MD5 Authentication 5 draft-ietf-ospf-md5-01.txt 7 Tue Sep 6 14:53:55 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 September 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 September 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 September 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 | Checksum | AuType=Keyed Message Digest Fn| 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | offset to MD5 digest | Key ID | Auth Data Len | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | non-decreasing sequence number | 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 September 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 September 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. Use of SNMP in Key Management 238 It is strongly desirable that a hypothetical security breach in one 239 Internet protocol not automatically compromise other Internet protocols. 240 Also, the default method for changing SNMP Version 2 encryption keys 241 does not provide the property of perfect forward secrecy. Therefore, 242 the OSPF Authentication key of this specification SHOULD NOT be stored 243 using SNMP. 245 3.2. Key Management Requirements 247 Implementations MUST support the storage of more than one key at the 248 same time. They MUST associate a specific lifetime (i.e., data/time 249 first valid and data/time no longer valid) with each key, the key 250 identifier, and MUST support manual key distribution (e.g., the 251 privileged user manually typing in the key, key lifetime, and key 252 DRAFT OSPF MD5 Authentication September 1994 254 identifier on the router console). If more than one algorithm is 255 supported, then the implementation MUST require that the algorithm be 256 specified for each key at the time the other key information is entered. 257 Keys that are out of date MAY be deleted at will by the implementation 258 without requiring human intervention. 260 It is likely that the IETF will define a standard key management 261 protocol. It is strongly desirable to use that key management protocol 262 to distribute OSPF Authentication Keys among communicating OSPF 263 implementations. Such a protocol would provide scalability and 264 significantly reduce the human administrative burden. The Key ID can be 265 used as a hook between OSPF and such a future protocol. Key management 266 protocols have a long history of subtle flaws that are often discovered 267 long after the protocol was first described in public. To avoid having 268 to change all OSPF implementations should such a flaw be discovered, 269 integrated key management protocol techniques were deliberately omitted 270 from this specification. 272 3.3. Key Management Procedures 274 As with all security methods using keys, it is necessary to change the 275 OSPF Authentication Key on a regular basis. To maintain routing 276 stability during such changes, implementations are required to store and 277 support the use of more than one OSPF Authentication Key on a given 278 interface at the same time. 280 Each key will have its own Key Identifier, which is stored locally. The 281 combination of the Key Identifier and the interface associated with the 282 message uniquely identifies the Authentication Algorithm and OSPF 283 Authentication Key in use. 285 As noted above in Section 2.2.1, the party creating the OSPF message 286 will select a valid key from the set of valid keys for that interface. 287 The receiver will use the Key Identifier and interface to determine 288 which key to use for authentication of the received message. More than 289 one key may be associated with an interface at the same time. 291 Hence it is possible to have fairly smooth OSPF Authentication Key 292 rollovers without losing legitimate OSPF messages because the stored key 293 is incorrect and without requiring people to change all the keys at 294 once. To ensure a smooth rollover, each communicating OSPF system must 295 be updated with the new key several minutes before they current key will 296 expire and several minutes before the new key lifetime begins. The new 297 key should have a lifetime that starts several minutes before the old 298 key expires. This gives time for each system to learn of the new OSPF 299 DRAFT OSPF MD5 Authentication September 1994 301 Authentication Key before that key will be used. It also ensures that 302 the new key will begin being used and the current key will go out of use 303 before the current key's lifetime expires. For the duration of the 304 overlap in key lifetimes, a system may receive messages using either key 305 and authenticate the message. 307 4. Conformance Requirements 309 To conform to this specification, an implementation MUST support all of 310 its aspects. The MD5 authentication algorithm defined in RFC-1321 MUST 311 be implemented by all conforming implementations. A conforming 312 implementation MAY also support other authentication algorithms such as 313 NIST's Secure Hash Algorithm (SHA). Manual key distribution as 314 described above MUST be supported by all conforming implementations. 315 All implementations MUST support the smooth key rollover described under 316 "Key Change Procedures.S 318 The user documentation provided with the implementation MUST contain 319 clear instructions on how to ensure that smooth key rollover occurs. 321 Implementations SHOULD support a standard key management protocol for 322 secure distribution of OSPF Authentication Keys once such a key 323 management protocol is standardized by the IETF. 325 5. Acknowledgments 327 This work was done by the OSPF Working Group, of which John Moy is the 328 Chair. This suggestion was originally made by Christian Huitema on 329 behalf of the IAB. Jeff Honig (Cornell) and Dennis Ferguson (ANS) built 330 the first operational prototype, proving out the algorithms. The 331 authors gladly acknowledge significant inputs from each of these 332 sources. 334 6. References 336 [1] Moy, John, "OSPF Version 2", RFC 1583, March 1994. 338 [2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 339 1992. 341 [3] F. Baker, R. Coltun, "OSPF Version 2 Management Information 342 Base", RFC 1253, August 1991 344 DRAFT OSPF MD5 Authentication September 1994 346 [4] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM 347 Computer Communications Review, Volume 19, Number 2, pp.32-48, 348 April 1989. 350 [5] N. Haller, R. Atkinson, "Internet Authentication Guidelines", 351 RFC-XXXX (already submitted to RFC Editor), September 1994. 353 7. Security Considerations 355 This entire memo describes and specifies an authentication mechanism for 356 the OSPF routing protocol that is believed to be secure against active 357 and passive attacks. Passive attacks are clearly widespread in the 358 Internet at present. Protection against active attacks is also needed 359 even though such attacks are not currently widespread. 361 Users need to understand that the quality of the security provided by 362 this mechanism depends completely on the strength of the implemented 363 authentication algorithms, the strength of the key being used, and the 364 correct implementation of the security mechanism in all communicating 365 OSPF implementations. This mechanism also depends on the OSPF 366 Authentication Key being kept confidential by all parties. If any of 367 these incorrect or insufficiently secure, then no real security will be 368 provided to the users of this mechanism. 370 Confidentiality is not provided by this mechanism. Work is underway 371 within the IETF to specify a standard mechanism for IP-layer encryption. 372 That mechanism might be used to provide confidentiality for OSPF in the 373 future. Protection against traffic analysis is also not provided. 374 Mechanisms such as bulk link encryption might be used when protection 375 against traffic analysis is required. 377 The memo is written to address a security consideration in OSPF Version 378 2 that was raised during the IAB's recent security review [cite RFC 379 here]. 381 8. Author's Address 383 Fred Baker 384 Advanced Computer Communications 385 315 Bollay Drive 386 Santa Barbara, California 93117 387 Phone: (805) 685 4455 388 Email: fbaker@acc.com 390 Randall Atkinson 392 DRAFT OSPF MD5 Authentication September 1994 394 Information Technology Division 395 Naval Research Laboratory 396 Washington, DC 20375-5320 397 Voice: (DSN) 354-8590 398 Fax: (DSN) 354-7942 399 Email: atkinson@itd.nrl.navy.mil 400 DRAFT OSPF MD5 Authentication September 1994 402 Table of Contents 404 1 Introduction .................................................... 2 405 2 Implementation Approach ......................................... 3 406 2.1 OSPF PDU Format ............................................... 3 407 2.2 Processing Algorithm .......................................... 4 408 2.2.1 Message Generation .......................................... 5 409 2.2.2 Message Reception ........................................... 6 410 3 Management Procedures ........................................... 6 411 3.1 Use of SNMP in Key Management ................................. 6 412 3.2 Key Management Requirements ................................... 6 413 3.3 Key Management Procedures ..................................... 7 414 4 Conformance Requirements ........................................ 8 415 5 Acknowledgments ................................................. 8 416 6 References ...................................................... 8 417 7 Security Considerations ......................................... 9 418 8 Author's Address ................................................ 9