idnits 2.17.1 draft-ietf-ospf-doi-00.txt: ** The Abstract section seems to be numbered 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 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. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Abstract' ) ** 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.) ** There are 92 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 6 instances of too long lines in the document, the longest one being 3 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 77: '...wn identifiers MUST be registered ...' RFC 2119 keyword, line 106: '... implementations MUST support SIT_AUTH...' RFC 2119 keyword, line 108: '... exchanges ([IO], Section 5) and MUST abort any security association...' RFC 2119 keyword, line 130: '...n the OSPFv2 DOI MUST support PROTO_IS...' RFC 2119 keyword, line 159: '...n the OSPFv2 DOI MUST support KEY_OAKL...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '... Drafts are ...' == Line 11 has weird spacing: '...cuments of t...' == Line 12 has weird spacing: '.... Note that ...' == Line 16 has weird spacing: '... months and m...' == Line 17 has weird spacing: '...afts as refer...' == (87 more instances...) -- 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 (15 October 1997) is 9688 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) -- Missing reference section? 'RFC-xxxx' on line 72 looks like a reference -- Missing reference section? 'STD-2' on line 75 looks like a reference -- Missing reference section? 'IO' on line 473 looks like a reference -- Missing reference section? 'OAKLEY' on line 480 looks like a reference -- Missing reference section? 'ISAKMP' on line 476 looks like a reference -- Missing reference section? 'RFC-2065' on line 468 looks like a reference -- Missing reference section? 'RFC-2178' on line 471 looks like a reference -- Missing reference section? 'PFKEY' on line 483 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Atkinson, Editor 3 Internet Draft @Home Network 4 draft-ietf-ospf-doi-00.txt 15 October 1997 6 OSPFv2 Domain Of Interpretation (DOI) for ISAKMP 8 STATUS OF THIS MEMO 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and working groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other documents 17 at any time. It is inappropriate to use Internet Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet Draft, please check 21 the ``1id-abstracts.txt'' listing contained in the Internet Drafts 22 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Australia), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Distribution of this memo is unlimited. This draft will expire six 27 months from date of issue. This draft is a work item of the Open 28 Shortest Path First (OSPF) Routing Protocol Working Group in the 29 IETF. Comments may be sent to the editor or to the OSPF WG as a 30 whole at its mailing list. 32 1. Abstract 34 The Internet Security Association and Key Management Protocol 35 (ISAKMP) defines a framework for security association management and 36 cryptographic key establishment for the Internet. This framework 37 consists of defined exchanges and processing guidelines that occur 38 within a given Domain of Interpretation (DOI). This document details 39 the OSPFv2 DOI, which is defined to cover the use of ISAKMP to 40 negotiate Security Associations for the OSPFv2 routing protocol. 42 2. Introduction 44 Within ISAKMP, a Domain of Interpretation is used to group related 45 protocols using ISAKMP to negotiate security associations. Security 46 protocols sharing a DOI choose security protocol and cryptographic 47 transforms from a common namespace and share key exchange protocol 48 identifiers. They also share a common interpretation of DOI-specific 49 payload data content, including the Security Association and 50 Identification payloads. 52 Overall, ISAKMP places the following requirements on a DOI 53 definition: 55 o define the naming scheme for DOI-specific protocol identifiers 56 o define the interpretation for the Situation field 57 o define the set of applicable security policies 58 o define the syntax for DOI-specific SA Attributes (phase II) 59 o define the syntax for DOI-specific payload contents 60 o define additional mappings or Key Exchange types, if needed 62 The remainder of this document details the instantiation of these 63 requirements for using the OSPFv2 cryptographic authentication 64 mechanism to provide data origin authentication for OSPFv2 routing 65 packets sent between cooperating routers. 67 3. Terms and Definitions 69 In this document, the words that are used to define the 70 significance of each particular requirement are usually capitalised. 71 These words are defined in RFC-xxxx, which is hereby incorporated 72 into this document by reference. [RFC-xxxx] 74 Within ISAKMP, all DOI's must be registered with the IANA in the 75 ``Assigned Numbers'' RFC [STD-2]. The IANA Assigned Number for the 76 OSPFv2 DOI is . Within the OSPFv2 DOI, all 77 well-known identifiers MUST be registered with the IANA under the 78 OSPFv2 DOI. Unless otherwise noted, all tables within this document 79 refer to IANA Assigned Numbers for the OSPFv2 DOI. 81 4.0 Assigned Numbers 83 The following sections list the Assigned Numbers for the OSPFv2 84 DOI Security Protocol Identifiers, Transform Identifiers, and 85 Security Association Attribute Types. Note that all multi-octet 86 binary values are stored in network byte order. 88 4.1 OSPFv2 Situation Definition 90 Within ISAKMP, the Situation provides information that can be used 91 by the responder to make a policy determination about how to process 92 the incoming Security Association request. For the OSPFv2 DOI, the 93 Situation field is a four (4) octet bitmask with the following 94 values. 96 Situation Value 97 --------- ----- 98 SIT_AUTHENTICATION 0x01 100 All other values are reserved to IANA. 102 The SIT_AUTHENTICATION type specifies that the security 103 association will be identified by source identity information present 104 in an associated Identification Payload. See Section 4.8.2 for a 105 complete description of the various Identification types. All OSPFv2 106 DOI implementations MUST support SIT_AUTHENTICATION by including an 107 Identification Payload in at least one of the phase I Oakley 108 exchanges ([IO], Section 5) and MUST abort any security association 109 setup that does not include an Identification Payload. 111 4.2 OSPFv2 Security Protocol Identifiers 113 The ISAKMP proposal syntax was specifically designed to allow for 114 the simultaneous negotiation of multiple security protocol suites 115 within a single negotiation. As a result, a Protocol ID must be 116 indicated. The size of this field is one octet. The values 3-255 are 117 reserved to IANA. 119 Protocol ID Value 120 ----------- ----- 121 RESERVED 0 122 PROTO_ISAKMP 1 123 PROTO_OSPFv2 2 125 4.3 PROTO_ISAKMP 127 The PROTO_ISAKMP type specifies message protection required during 128 Phase I of the ISAKMP protocol. The specific protection mechanism 129 used for the OSPFv2 DOI is described in [IO]. All implementations 130 within the OSPFv2 DOI MUST support PROTO_ISAKMP. 132 NB: ISAKMP reserves the value one (1) across all DOI definitions. 134 4.3.1 PROTO_OSPFv2 136 The PROTO_OSPFv2 type specifies IP packet data origin 137 authentication. The default OSPFv2 transform includes data origin 138 authentication and replay prevention. 140 4.4 OSPFv2 ISAKMP Transform Values 142 As part of an ISAKMP Phase I negotiation, the initiator's choice 143 of Key Exchange offerings is made using some host system policy 144 description. The actual selection of Key Exchange mechanism is made 145 using the standard ISAKMP Proposal Payload. The following table 146 lists the defined ISAKMP Phase I Transform Identifiers for the 147 Proposal Payload for the OSPFv2 DOI. 149 Transform Value 150 --------- ----- 151 RESERVED 0 152 KEY_OAKLEY 1 154 The size of this field is one octet. The values 4-255 are 155 reserved to IANA. 157 The KEY_OAKLEY type specifies the hybrid ISAKMP/Oakley Diffie- 158 Hellman key exchange as defined in the [IO] document. All 159 implementations within the OSPFv2 DOI MUST support KEY_OAKLEY. It is 160 anticipated that in future values will be assigned for Kerberos v5, 161 GKMP, and/or other protocols to handle multicast SA creation more 162 effectively. 164 4.5 OSPFv2 Cryptographic Authentication Transform Values 166 The OSPFv2 Cryptographic Authentication mechanism is designed to 167 be algorithm-independent, even though only one algorithm transform 168 was been defined as of the time this document was written. The 169 following table lists the defined OSPFv2 Cryptographic Transform 170 Identifiers for the ISAKMP Proposal Payload for the OSPFv2 DOI. 172 Transform ID Value 173 ------------ ----- 174 RESERVED 0 175 OSPFv2_MD5_KPDK 1 177 The size of this field is one octet. The values 4-255 are 178 reserved to IANA. 180 The AH_MD5_KPDK type specifies the AH transform (Key/Pad/Data/Key) 181 described in RFC-2178. Implementations are required to support this 182 mode. 184 4.6 OSPFv2 Security Association Attributes 186 The following SA attribute definitions are used in phase II of an 187 ISAKMP/Oakley negotiation. Attribute types can be either Basic (B) 188 or Variable-Length (V). Encoding of these attributes is defined in 189 the base ISAKMP specification. 191 Attribute Classes 193 class value type 194 ------------------------------------------------- 195 Auth Key Life Type 1 B 196 Auth Key Life Duration 2 B/V 197 Enc Key Life Type 3 B 198 Enc Key Life Duration 4 B/V 199 SA Life Type 5 B 200 SA Life Duration 6 B/V 201 Replay Protection 7 B 202 Group Description 8 B 203 CA Distinguished Name 9 B 204 Encapsulation Mode 10 B 206 Class Values 208 Auth Key Life Type 209 Auth Key Duration 210 Specifies the time-to-live for the authentication key(s) 211 used in the corresponding AH HMAC transform. 213 SA Life Type 214 SA Duration 215 Specifies the time-to-live for the overall security 216 association. When the SA expires, all keys negotiated 217 under the association (AH or ESP) must be renegotiated 218 regardless of the time-to-live remaining for the keys. 220 RESERVED 0 221 seconds 1 222 kilobytes 2 224 Values 3-61439 are reserved to IANA. Values 61440-65535 225 are for experimental use. For a given "Life Type," the 226 value of the "Life Duration" attribute defines the actual 227 length of the component lifetime -- either a number of 228 seconds, or a number of Kbytes that can be protected. 230 If unspecified, the default value shall be assumed to be 231 28800 seconds (8 hours) for Auth, Enc, and SA lifetime. 233 Replay Protection 234 RESERVED 0 235 required 1 236 disallowed 2 238 Values 3-61439 are reserved to IANA. Values 61440-65535 239 are for private use among mutually consenting parties. 241 There is no default value for Replay Protection, as it 242 must be specified to correctly identify the applicable 243 transform. 245 Group Description 246 RESERVED 0 247 default group 1 249 Values 2-61439 are reserved to IANA. Values 61440-65535 250 are for private use among mutually consenting parties. 252 If unspecified, the default value shall be assumed to be 253 the default Oakley group ([IO], Section 5.5.1). 255 CA Distinguished Name 256 RESERVED 0 257 DNS Security 1 259 Values 2-61439 are reserved to IANA. Values 61440-65535 260 are for private use among mutually consenting parties. 262 If unspecified, the default value shall be assumed to be 263 DNS Security (Section 4.8). 265 4.7.1 Required Attribute Support 267 To ensure basic interoperability, all implementations MUST support 268 all of the following attributes: 270 Auth Key Life Type 271 Auth Key Duration 272 SA Life Type 273 SA Duration 274 Replay Protection 276 4.7.2 Attribute List Parsing Requirement 278 To allow for flexible semantics, the OSPFv2 DOI requires that a 279 conforming ISAKMP implementation MUST correctly parse an attribute 280 list that contains multiple instances of the same attribute class, so 281 long as the different attribute entries do not conflict with one 282 another. 284 If conflicting attributes are detected, an ATTRIBUTES-NOT- 285 SUPPORTED Notification Payload SHOULD be returned and the security 286 association setup MUST be aborted. 288 4.8 OSPFv2 Payload Content 290 The following sections describe those ISAKMP payloads whose data 291 representations are dependent on the applicable DOI. 293 4.8.1 Security Association Payload 295 The following diagram illustrates the content of the Security 296 Association Payload for the OSPFv2 DOI. See above for a description 297 of the Situation bitmap. 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Next Payload | RESERVED | Payload Length | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Domain of Interpretation (OSPFv2) | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Situation (bitmap) | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Figure 1: Security Association Payload Format 310 The Security Association Payload is defined as follows: 312 o Next Payload (2 octets) - Identifier for the payload type of 313 the next payload in the message. If the current payload is 314 the last in the message, this field will be zero (0). 316 o RESERVED (1 octet) - Unused, must be zero (0). 318 o Payload Length (2 octets) - Length, in octets, of the current 319 payload, including the generic header. 321 o Domain of Interpretation (4 octets) - Specifies the OSPFv2 DOI, 322 which has been assigned the value . 324 o Situation (4 octets) - Bitmask used to interpret the 325 remainder of the Security Association Payload. See Section 326 4.2 for a complete list of values. 328 4.8.2 Identification Payload Content 330 The Identification Payload is used to identify the initiator of 331 the Security Association. The identity of the initiator SHOULD be 332 used by the responder to determine the correct host system security 333 policy requirement for the association. Typically, OSPF sessions use 334 an identity that is either an IP Address or a Fully Qualified Domain 335 Name (FQDN). 337 The Identification Payload provides information that can be used by 338 the responder to make this decision. 340 The following diagram illustrates the content of the Identification 341 Payload. 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Next Payload | ID Type | Payload Length | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 ~ Identification Data ~ 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Figure 2: Identification Payload Format 352 The Identification Payload field is defined as follows: 354 o Next Payload (2 octets) - Identifier for the payload type of 355 the next payload in the message. If the current payload is 356 the last in the message, this field will be zero (0). 358 o Identification Type (1 octet) - Value describing the 359 identity information found in the Identification Data field. 361 o Payload Length (2 octets) - Length, in octets, of the 362 identification data, including the generic header. 364 4.8.2.1 Identification Type Values 366 The following table lists the assigned values for the 367 Identification Type field found in the Identification Payload. 369 ID Type Value 370 ------- ----- 371 RESERVED 0 372 ID_IPV4_ADDR 1 373 ID_IPV6_ADDR 2 374 ID_FQDN 3 375 ID_USER_FQDN 4 377 The size of this field is one octet. The values 5-255 are reserved 378 to IANA. 380 The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address. 382 The ID_IPV4_ADDR type specifies a single sixteen (16) octet IPv6 383 address. 385 The ID_FQDN type specifies a fully-qualified domain name string. An 386 example of a ID_FQDN is, "foo.bar.com". 388 The ID_USER_FQDN type specifies a fully-qualified username string, An 389 example of a ID_USER_FQDN is, "john-doe@foo.bar.com". 391 4.9 OSPFv2 Security Parameter Index (SPI) Encoding 393 ISAKMP defines the SPI field as eight octets in length, however 394 the OSPFv2 Cryptographic Authentication only uses a one octet Key 395 Identifier. All implementations MUST use the following mapping for 396 the ISAKMP SPI field in the OSPFv2 DOI. 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | KEY ID | RESERVED MUST BE ZERO | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | RESERVED MUST BE ZERO | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Figure 3: ISAKMP SPI Encoding 407 The ISAKMP SPI field is defined as follows: 409 o KEY ID - Key Identifier (1 octet) - contains the 410 KEY ID value which identifies the OSPFv2 Authentication Key. 412 o RESERVED (7 octets) - Reserved for future use, 413 must be sent as zero (0) and 414 ignored upon receipt. 416 4.8 OSPFv2 Certificate Authorities 418 The ISAKMP Certificate Request Payload allows either side of 419 an ISAKMP negotiation to request its peer to provide a certificate 420 chain needed to authenticate itself. The Certificate Request Payload 421 includes a list of acceptable Certificate Types and Certificate 422 Authorities. Appropriate certificate chains are then returned in a 423 Certificate Payload response. 425 The OSPFv2 DOI defines the following Certificate Authorities 426 for the processing of Certificate Request Payloads. See Section 4.5 427 for details on the specific data attribute type values for these CAs. 429 Certificate Authority 430 --------------------- 431 DNS Security 433 4.8.1 DNS Security 435 This CA type represents the combination of KEY and SIG records, as 436 defined in RFC-2065, that can be used for authentication. The 437 particular encoding required to formulate the Certificate Payload 438 (response) is TBD. 440 4.9 OSPFv2 Key Exchange Requirements 442 The OSPFv2 DOI introduces no additional Key Exchange types. 444 5. Security Considerations 446 This entire note pertains to a hybrid protocol, combining 447 Oakley ([OAKLEY]) with ISAKMP ([ISAKMP]), to negotiate and derive 448 keying material for security associations in a secure and 449 authenticated manner. Specific discussion of the various security 450 protocols and transforms identified in this document can be found in 451 the associated base documents. 453 This document describes the additional data needed to apply 454 the ISAKMP protocol for use in managing OSPFv2 Authentication Keys 455 and related data. Implementers should consult the OSPFv2 456 specification for more information on OSPFv2 Cryptographic 457 Authentication. 459 ACKNOWLEDGEMENTS: 461 This document is directly derived from the "IP Security DOI for 462 ISAKMP" by Derrell Piper. That document is in turn derived, in part, 463 from previous works by Douglas Maughan, Mark Schertler, Mark 464 Schneider, Jeff Turner, Dan Harkins, and Dave Carrel. 466 REFERENCES: 468 [RFC-2065] D. Eastlake 3rd & C. Kaufman, "Domain Name System Security 469 Extensions (DNSSEC)", RFC-2065, January 1997. 471 [RFC-2178] J. Moy, "OSPF Version 2", RFC-2178, July 1997. 473 [IO] D. Carrel & D. Harkins, "The Resolution of ISAKMP with Oakley," 474 draft-ietf-ipsec-isakmp-oakley-03.txt. 476 [ISAKMP] D. Maughan, M. Schertler, M. Schneider, & J. Turner, 477 "Internet Security Association and Key Management Protocol (ISAKMP)," 478 draft-ietf-ipsec-isakmp-07.{ps,txt}. 480 [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," 481 draft-ietf-ipsec-oakley-01.txt. 483 [PFKEY] D.L. McDonald, C.W. Metz, B.G. Phan, "PF_KEY Key Management API, 484 Version 2", draft-mcdonald-pf-key-v2-01.txt, work in progress. 486 Editor's Address: 488 Randall Atkinson 489 @Home Network 490 425 Broadway Street 491 Redwood City, CA, 492 USA 94063 494 +1 (650) 569-5449