idnits 2.17.1 draft-templin-omni-send-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 22, 2021) is 1189 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) == Outdated reference: A later version (-99) exists of draft-templin-6man-omni-interface-68 == Outdated reference: A later version (-37) exists of draft-ietf-drip-rid-06 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Updates: RFC3971 (if approved) January 22, 2021 5 Intended status: Standards Track 6 Expires: July 26, 2021 8 Secure NEighbor Discovery (SEND) over OMNI Interfaces 9 draft-templin-omni-send-03 11 Abstract 13 The Overlay Multilink Network Interface (OMNI) specification can be 14 used by nodes on public Internetworks when a suitable security 15 service is provided to authenticate IPv6 Neighbor Discovery (IPv6 ND) 16 control messages. The basic OMNI security service for transmission 17 of IPv6 ND messages over public Internetworks uses a Hashed Message 18 Authentication Code (HMAC) based on a shared secret. This document 19 specifies use of the Secure NEighbor Discovery (SEND) protocol over 20 OMNI interfaces which can provide a more flexible and robust service. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 26, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. SEND Over OMNI Interfaces . . . . . . . . . . . . . . . . . . 3 59 3.1. Processing Rules for Senders . . . . . . . . . . . . . . 4 60 3.2. Processing Rules for Receivers . . . . . . . . . . . . . 5 61 4. SEND/CGA Updates . . . . . . . . . . . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 8.2. Informative References . . . . . . . . . . . . . . . . . 9 68 Appendix A. Using Host Identity Tags (HITs) with OMNI/SEND . . . 9 69 Appendix B. Using HIP-based Authentication Instead of SEND/CGA . 10 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 The Overlay Multilink Network Interface (OMNI) specification 75 [I-D.templin-6man-omni-interface] can be used by nodes on public 76 Internetworks when a suitable security service is provided to 77 authenticate IPv6 Neighbor Discovery (IPv6 ND) control messages 78 [RFC4861][RFC8200]. The basic OMNI security service for transmission 79 of IPv6 ND messages over public Internetworks uses a Hashed Message 80 Authentication Code (HMAC) based on a shared secret. This document 81 specifies use of the Secure NEighbor Discovery (SEND) protocol over 82 OMNI interfaces which can provide a more flexible and robust service. 84 The HMAC-based security service may be adequate when all OMNI access 85 routers can be provisioned with a shared secret for all potential 86 clients. However, the service may not be scalable and/or agile 87 enough for all environments, e.g., when the population of clients 88 grows and/or changes dynamically. Moreover, it is client-server 89 oriented, and may be too cumbersome for general-purpose use between 90 opportunistic neighbor pairs. 92 The Secure NEighbor Discovery (SEND) protocol [RFC3971] and 93 Cryptographically Generated Addresses (CGA) [RFC3972] were designed 94 to provide authentication services for IPv6 ND messaging over links 95 of all varieties, including wireless. SEND requires that the CGA 96 appear as the IPv6 ND message source or target address (see: 98 Section 5.1.1 of [RFC3971]) where it will be covered by the RSA 99 signature. Since OMNI interfaces use only non-CGA source and target 100 addresses, however, this specification updates [RFC3971] by allowing 101 CGAs to appear elsewhere in the message. 103 The use of SEND over OMNI interfaces offers the opportunity for a 104 certificate-based security service for large and dynamically changing 105 populations of mobile nodes within a bounded service domain. The 106 service domain can be as large as a major public Internetwork, and 107 can even span multiple disjoint Internetworks when appropriate 108 peering arrangements are in place. The remainder of this document 109 specifies the operation of SEND over OMNI interfaces. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119][RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 3. SEND Over OMNI Interfaces 121 The HMAC-based authentication option specified in 122 [I-D.templin-6man-omni-interface] is distinguished by the two-octet 123 code 0x0001 immediately following the UDP/IP encapsulation headers. 124 The first octet 0x00 indicates that a message preamble option 125 follows, while the second octet 0x01 is a 'type' field that 126 identifies the HMAC-based authentication option. Following the 127 authentication option (and any other preamble options present), the 128 IPv6 ND message itself begins and includes any necessary SEND 129 options. 131 This specification allows CGAs to appear in a location other than the 132 source or target address of the IPv6 ND message. In particular, this 133 specification defines a new "Cryptographically Generated Address 134 (CGA)" sub-option for the OMNI option (see Section 10 of 135 [I-D.templin-6man-omni-interface]) formatted as follows: 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Sub-Type=TBD | Sub-length=16 | | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 142 . . 143 . Cryptographically-Generated Address (CGA) (128 bits) . 144 . . 145 . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 . | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 Figure 1: Cryptographically-Generated Address (CGA) Sub-option 151 o Sub-Type is set to "TBD". 153 o Sub-Length is set to 16 (i.e., the length of the CGA). 155 o Cryptographically-Generated Address (CGA) is a 128 bit IPv6 156 address generated as specified in [RFC3972]. 158 With this sub-option, OMNI nodes can place their CGAs inside the OMNI 159 option instead of as the source or target address of the IPv6 ND 160 message (note that this represents an update to Section 5.1.1 of 161 [RFC3971]). The processing rules for senders and receivers are 162 discussed in the following Sections. 164 3.1. Processing Rules for Senders 166 Per the OMNI specification [I-D.templin-6man-omni-interface], a 167 mobile node (MN) may be pre-provisioned with a Mobile Network Prefix 168 (MNP) (e.g., 2001:db8:1:2::/64) which it uses to form an MNP-based 169 OMNI Link Local Address (LLA) and MNP-based CGA. Otherwise, the MN 170 obtains an MNP through an initial IPv6 ND message-based bootstrapping 171 exchange with an Access Router (AR) while using a temporary LLA and 172 LLA-based CGA using the prefix fe80::/64. 174 The MN sends IPv6 ND messages with an OMNI option that includes its 175 CGA in a CGA sub-option as shown in Figure 1. The MN also includes 176 any necessary SEND options (e.g., CGA parameters, RSA signature, 177 Nonce, Timestamp, etc.) per [RFC3971] while observing the updates 178 discussed in Section 4. The RSA signature option MUST appear later 179 in the IPv6 ND message options after the OMNI option so that the 180 signature properly covers the CGA. The MN then sets the IPv6 source, 181 destination and target (when present) to appropriate non-CGA 182 addresses, and sends the message to the neighbor. 184 When an initial bootstrapping exchange is required, the temporary 185 LLA's statistical uniqueness properties allow for optimistic 186 operation while the LLA-based CGA's uniqueness properties are 187 irrelevant since it will never be used as an IPv6 packet header 188 address. Following bootstrapping, the MN forms an MNP-based OMNI LLA 189 and MNP-based CGA from its newly-obtained MNP and retains them for 190 future IPv6 ND messaging. These addresses are assured to be unique 191 within the domain, since the MNP is uniquely delegated to the MN. 193 OMNI link ARs are assigned administrative OMNI LLAs that are 194 guaranteed to be unique on the link, but they receive no MNPs of 195 their own. Therefore, ARs will generate only LLA-based CGAs and use 196 them for all SEND operations. While it is possible that two or more 197 ARs may generate duplicate LLA-based CGAs, each AR will apply its own 198 unique private key signature such that robust IPv6 ND message 199 authentication is supported. For these reasons (and for the reasons 200 explained for MNs above) no Duplicate Address Detection (DAD) testing 201 of CGAs is necessary. 203 3.2. Processing Rules for Receivers 205 When an OMNI node receives an IPv6 ND message from a neighbor, if 206 both the HMAC and SEND authentication services appear in the same 207 message the node SHOULD process the SEND authentication credentials 208 and ignore the HMAC credentials. If only one authentication service 209 is present, the node SHOULD process the credentials according to the 210 included service. If no authentication services are present (or, if 211 the SEND service is present but the RSA signature option appears 212 before the OMNI option) the node SHOULD regard the IPv6 ND message as 213 unsecured. 215 When the CGA sub-option is included in the OMNI option and the RSA 216 signature option appears later in the IPv6 ND message options, the 217 node verifies the signature per [RFC3971] while observing the updates 218 discussed in Section 4. In any case, if the IPv6 ND message includes 219 an incorrect authentication code the node SHOULD discard the message. 221 4. SEND/CGA Updates 223 Since their original publications, several important updates to the 224 SEND [RFC3971] and CGA [RFC3972] specifications have been published 225 and are observed as follows: 227 o [RFC4581] defines a format for the CGA parameter data structure 228 extension field. While no extensions are introduced in this 229 document, any future updates to this document that introduce 230 extensions MUST observe this format. 232 o [RFC4982] introduces support for multiple hash algorithms in CGAs. 233 The hash algorithm is identified by a value in the Sec bits of the 234 CGA itself, which must be registered in the IANA "CGA SEC" 235 registry. This document requests a new CGA SEC value "TBD2" for 236 the SHA-256 hash algorithm (see: Section 5 and Section 6). 238 o [RFC6494] defines a certificate profile that supersedes the 239 profile for Router Authorization Certificates. Certificates used 240 in SEND over OMNI interfaces MUST conform to this new certificate 241 profile and MAY conform to the original profile. 243 o [RFC6495] specifies Subject Key Identifier (SKI) Name Type Fields 244 for SEND, which apply also to this document. 246 o [RFC6980] analyzes the security implications of employing IPv6 247 fragmentation with IPv6 ND messages (especially with regards to 248 SEND) and updates [RFC4861] such that use of the IPv6 249 Fragmentation Header is forbidden in all ND messages. OMNI 250 interfaces honor [RFC6980] by employing the OMNI Adaptation Layer 251 (OAL) [I-D.templin-6man-omni-interface] to transport IPv6 ND 252 messages no larger than the OMNI interface MTU without causing an 253 IPv6 Fragmentation Header to appear within the IPv6 ND message 254 itself. 256 5. IANA Considerations 258 IANA is instructed to allocate a new "OMNI option Sub-Type values" 259 registry codepoint for the Cryptographically Generated Address (CGA) 260 sub-option (value TBD). 262 IANA is instructed to allocate a new "CGA SEC" registry codepoint for 263 SHA-256 (value TBD2). 265 6. Security Considerations 267 The OMNI specification [I-D.templin-6man-omni-interface] provides an 268 HMAC authentication service that can be used for basic client-server 269 authentication based on shared secrets. The SEND service discussed 270 in this document uses X.509 public keys which provide a more flexible 271 and extensible security service, especially for use on large OMNI 272 links that support a dynamically changing collection of many MNs. 274 [RFC6273] provides a hash threat analysis for SEND that concludes: 276 "Current attacks on hash functions do not constitute any practical 277 threat to the digital signatures used in SEND (both in the RSA 278 signature option and in the X.509 certificates). Attacks on CGAs, 279 as described in [RFC4982], will compromise the security of SEND 280 and they need to be addressed by encoding the hash algorithm 281 information into the CGA as specified in [RFC4982]." 283 For this reason, implementations MUST use the SHA-256 hash algorithm 284 for CGAs, as indicated by the value TBD2 appearing in the CGA Sec 285 field (see: Section 5). Future documents MAY specify additional hash 286 algorithm values for the CGA Sec field. 288 OMNI nodes assign CGAs to their OMNI interfaces but do not use them 289 as IPv6 source, destination or target addresses, nor as node 290 identifiers. Instead, OMNI nodes place the CGA in IPv6 ND message 291 OMNI options, use non-CGA addresses for IPv6 packet addressing, and 292 use Universally Unique IDentifiers (UUIDs) [RFC4122][RFC6487] for 293 node identification purposes. 295 The series of consecutively-numbered RFCs beginning with [RFC6480] 296 and extending to [RFC6495] establishes standards and operational 297 practices for secure Internet routing. The series includes updates 298 cited in Section 4 that establish SEND as an integral component of 299 the architecture. OMNI interfaces that use SEND over public 300 Internetworks therefore observe these same principles. 302 7. Acknowledgements 304 This work is aligned with the NASA Safe Autonomous Systems Operation 305 (SASO) program under NASA contract number NNA16BD84C. 307 This work is aligned with the FAA as per the SE2025 contract number 308 DTFAWA-15-D-00030. 310 This work is aligned with the Boeing Commercial Airplanes (BCA) 311 Internet of Things (IoT) and autonomy programs. 313 This work is aligned with the Boeing Information Technology (BIT) 314 MobileNet program. 316 8. References 318 8.1. Normative References 320 [I-D.templin-6man-omni-interface] 321 Templin, F. and T. Whyman, "Transmission of IP Packets 322 over Overlay Multilink Network (OMNI) Interfaces", draft- 323 templin-6man-omni-interface-68 (work in progress), January 324 2021. 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, 328 DOI 10.17487/RFC2119, March 1997, 329 . 331 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 332 "SEcure Neighbor Discovery (SEND)", RFC 3971, 333 DOI 10.17487/RFC3971, March 2005, 334 . 336 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 337 RFC 3972, DOI 10.17487/RFC3972, March 2005, 338 . 340 [RFC4581] Bagnulo, M. and J. Arkko, "Cryptographically Generated 341 Addresses (CGA) Extension Field Format", RFC 4581, 342 DOI 10.17487/RFC4581, October 2006, 343 . 345 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 346 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 347 DOI 10.17487/RFC4861, September 2007, 348 . 350 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 351 Algorithms in Cryptographically Generated Addresses 352 (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007, 353 . 355 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 356 X.509 PKIX Resource Certificates", RFC 6487, 357 DOI 10.17487/RFC6487, February 2012, 358 . 360 [RFC6494] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate 361 Profile and Certificate Management for SEcure Neighbor 362 Discovery (SEND)", RFC 6494, DOI 10.17487/RFC6494, 363 February 2012, . 365 [RFC6495] Gagliano, R., Krishnan, S., and A. Kukec, "Subject Key 366 Identifier (SKI) SEcure Neighbor Discovery (SEND) Name 367 Type Fields", RFC 6495, DOI 10.17487/RFC6495, February 368 2012, . 370 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 371 with IPv6 Neighbor Discovery", RFC 6980, 372 DOI 10.17487/RFC6980, August 2013, 373 . 375 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 376 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 377 May 2017, . 379 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 380 (IPv6) Specification", STD 86, RFC 8200, 381 DOI 10.17487/RFC8200, July 2017, 382 . 384 8.2. Informative References 386 [I-D.ietf-drip-rid] 387 Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, 388 "UAS Remote ID", draft-ietf-drip-rid-06 (work in 389 progress), December 2020. 391 [I-D.templin-duid-ipv6] 392 Templin, F., "The IPv6 Address-based DHCPv6 Unique 393 Identifier (DUID-V6ADDR)", draft-templin-duid-ipv6-01 394 (work in progress), January 2021. 396 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 397 Unique IDentifier (UUID) URN Namespace", RFC 4122, 398 DOI 10.17487/RFC4122, July 2005, 399 . 401 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 402 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 403 DOI 10.17487/RFC6273, June 2011, 404 . 406 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 407 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 408 February 2012, . 410 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 411 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 412 RFC 7401, DOI 10.17487/RFC7401, April 2015, 413 . 415 Appendix A. Using Host Identity Tags (HITs) with OMNI/SEND 417 Section 4 of [RFC3971] states: 419 "This specification also allows a node to use non-CGAs with 420 certificates that authorize their use. However, the details of 421 such use are beyond the scope of this specification and are left 422 for future work." 424 The Host Identity Tag (HIT) [RFC7401] is an example of a non-CGA that 425 is also obtained through a cryptographic hash of the node's public 426 key. HITs (and their derivatives known as "Hierarchical HITs" 427 [I-D.ietf-drip-rid]) have several important properties: 429 "The HIT is 128 bits long and has the following three key 430 properties: i) it is the same length as an IPv6 address and can be 431 used in fixed address-sized fields in APIs and protocols; ii) it 432 is self-certifying (i.e., given a HIT, it is computationally hard 433 to find a Host Identity key that matches the HIT); and iii) the 434 probability of a HIT collision between two hosts is very low; 435 hence, it is infeasible for an attacker to find a collision with a 436 HIT that is in use. [RFC7401]" 438 Should IETF consensus determine that (H)HITs represent a preferred 439 solution, the same mechanisms described for CGAs in this document can 440 be used to enable OMNI interface SEND security operations while using 441 (H)HITs. Namely, a new OMNI sub-option will be defined for the 442 purpose of carrying a 128-bit (H)HIT as the sub-option of an OMNI 443 option. The processing rules for senders and receivers specified in 444 Section 3 will be applied in the same fashion as for CGAs, with the 445 exception that the IPv6 ND CGA option which includes the node's 446 public key (and other information) will be associated with the (H)HIT 447 instead of with a CGA. Most importantly, the (H)HIT would be covered 448 under the RSA signature applied to the IPv6 ND message thereby 449 allowing receivers to verify proof of ownership. 451 Use of the (H)HIT as a node identifier can also be considered per 452 future IETF consensus determinations. If the IETF determines that an 453 (H)HIT can be used as a node identifier (i.e., instead of a UUID) the 454 specification of a new Dynamic Host Configuration Protocol for IPv6 455 (DHCPv6) Device Unique IDentifier (DUID) type may be indicated (see: 456 [I-D.templin-duid-ipv6]). 458 Appendix B. Using HIP-based Authentication Instead of SEND/CGA 460 [RFC7401] specifies the Host Identity Protocol, version 2 (HIPv2) and 461 is intended as a comprehensive protocol suite which in many ways 462 overlaps with the intended use cases for OMNI. However, IPv6 ND 463 control messages over OMNI interfaces could be secured using selected 464 elements of [RFC7401] without incorporating all aspects of the 465 specification. 467 In particular, the HOST_ID and HIP_SIGNATURE parameters specified in 468 Sections 5.2.9 and 5.2.14 of [RFC7401] could be incorporated as new 469 sub-options of the OMNI option, and the SIGNATURE calculation and 470 verification procedures specified in Section 6.4 could be adapted for 471 signing IPv6 ND messages in the manner similar to that currently 472 prescribed by [RFC3971]. 474 The [RFC7401] message authentication methods could therefore be used 475 with OMNI interfaces instead of employing SEND/CGA. Furthermore, the 476 (H)HIT could be used as an OMNI node identifier instead of a UUID as 477 discussed in the previous section. 479 Author's Address 481 Fred L. Templin (editor) 482 Boeing Research & Technology 483 P.O. Box 3707 484 Seattle, WA 98124 485 USA 487 Email: fltemplin@acm.org