Network Working Group F. Templin, Ed. Internet-Draft Boeing Research & Technology Updates: RFC3971 (if approved) January 21, 2021 Intended status: Standards Track Expires: July 25, 2021 Secure NEighbor Discovery (SEND) over OMNI Interfaces draft-templin-omni-send-02 Abstract The Overlay Multilink Network Interface (OMNI) specification can be used by nodes on public Internetworks when a suitable security service is provided to authenticate IPv6 Neighbor Discovery (IPv6 ND) control messages. The basic OMNI security service for transmission of IPv6 ND messages over public Internetworks uses a Hashed Message Authentication Code (HMAC) based on a shared secret. This document specifies use of the Secure NEighbor Discovery (SEND) protocol over OMNI interfaces which can provide a more flexible and robust service. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 25, 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Templin Expires July 25, 2021 [Page 1] Internet-Draft OMNI SEND January 2021 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. SEND Over OMNI Interfaces . . . . . . . . . . . . . . . . . . 3 3.1. Processing Rules for Senders . . . . . . . . . . . . . . 4 3.2. Processing Rules for Receivers . . . . . . . . . . . . . 5 4. SEND/CGA Updates . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Using Host Identity Tags (HITs) with OMNI/SEND . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The Overlay Multilink Network Interface (OMNI) specification [I-D.templin-6man-omni-interface] can be used by nodes on public Internetworks when a suitable security service is provided to authenticate IPv6 Neighbor Discovery (IPv6 ND) control messages [RFC4861][RFC8200]. The basic OMNI security service for transmission of IPv6 ND messages over public Internetworks uses a Hashed Message Authentication Code (HMAC) based on a shared secret. This document specifies use of the Secure NEighbor Discovery (SEND) protocol over OMNI interfaces which can provide a more flexible and robust service. The HMAC-based security service may be adequate when all OMNI access routers can be provisioned with a shared secret for all potential clients. However, the service may not be scalable and/or agile enough for all environments, e.g., when the population of clients grows and/or changes dynamically. Moreover, it is client-server oriented, and may be too cumbersome for general-purpose use between opportunistic neighbor pairs. The Secure NEighbor Discovery (SEND) protocol [RFC3971] and Cryptographically Generated Addresses (CGA) [RFC3972] were designed to provide authentication services for IPv6 ND messaging over links of all varieties, including wireless. SEND requires that the CGA appear as the IPv6 ND message source or target address (see: Section 5.1.1 of [RFC3971]) where it will be covered by the RSA Templin Expires July 25, 2021 [Page 2] Internet-Draft OMNI SEND January 2021 signature. Since OMNI interfaces use only non-CGA source and target addresses, however, this specification updates [RFC3971] by allowing CGAs to appear elsewhere in the message. The use of SEND over OMNI interfaces offers the opportunity for a certificate-based security service for large and dynamically changing populations of mobile nodes within a bounded service domain. The service domain can be as large as a major public Internetwork, and can even span multiple disjoint Internetworks when appropriate peering arrangements are in place. The remainder of this document specifies the operation of SEND over OMNI interfaces. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. 3. SEND Over OMNI Interfaces The HMAC-based authentication option specified in [I-D.templin-6man-omni-interface] is distinguished by the two-octet code 0x0001 immediately following the UDP/IP encapsulation headers. The first octet 0x00 indicates that a message preamble option follows, while the second octet 0x01 is a 'type' field that identifies the HMAC-based authentication option. Following the authentication option (and any other preamble options present), the IPv6 ND message itself begins and includes any necessary SEND options. This specification allows CGAs to appear in a location other than the source or target address of the IPv6 ND message. In particular, this specification defines a new "Cryptographically Generated Address (CGA)" sub-option for the OMNI option (see Section 10 of [I-D.templin-6man-omni-interface]) formatted as follows: Templin Expires July 25, 2021 [Page 3] Internet-Draft OMNI SEND January 2021 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type=TBD | Sub-length=16 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . Cryptographically-Generated Address (CGA) (128 bits) . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Cryptographically-Generated Address (CGA) Sub-option o Sub-Type is set to "TBD". o Sub-Length is set to 16 (i.e., the length of the CGA). o Cryptographically-Generated Address (CGA) is a 128 bit IPv6 address generated as specified in [RFC3972]. With this sub-option, OMNI nodes can place their CGAs inside the OMNI option instead of as the source or target address of the IPv6 ND message (note that this represents an update to Section 5.1.1 of [RFC3971]). The processing rules for senders and receivers are discussed in the following Sections. 3.1. Processing Rules for Senders Per the OMNI specification [I-D.templin-6man-omni-interface], a mobile node (MN) may be pre-provisioned with a Mobile Network Prefix (MNP) (e.g., 2001:db8:1:2::/64) which it uses to form an MNP-based OMNI Link Local Address (LLA) and MNP-based CGA. Otherwise, the MN obtains an MNP through an initial IPv6 ND message-based bootstrapping exchange with an Access Router (AR) while using a temporary LLA and LLA-based CGA using the prefix fe80::/64. The MN sends IPv6 ND messages with an OMNI option that includes its CGA in a CGA sub-option as shown in Figure 1. The MN also includes any necessary SEND options (e.g., CGA parameters, RSA signature, Nonce, Timestamp, etc.) per [RFC3971] while observing the updates discussed in Section 4. The RSA signature option MUST appear later in the IPv6 ND message options after the OMNI option so that the signature properly covers the CGA. The MN then sets the IPv6 source, destination and target (when present) to appropriate non-CGA addresses, and sends the message to the neighbor. Templin Expires July 25, 2021 [Page 4] Internet-Draft OMNI SEND January 2021 When an initial bootstrapping exchange is required, the temporary LLA's statistical uniqueness properties allow for optimistic operation while the LLA-based CGA's uniqueness properties are irrelevant since it will never be used as an IPv6 packet header address. Following bootstrapping, the MN forms an MNP-based OMNI LLA and MNP-based CGA from its newly-obtained MNP and retains them for future IPv6 ND messaging. These addresses are assured to be unique within the domain, since the MNP is uniquely delegated to the MN. OMNI link ARs are assigned administrative OMNI LLAs that are guaranteed to be unique on the link, but they receive no MNPs of their own. Therefore, ARs will generate only LLA-based CGAs and use them for all SEND operations. While it is possible that two or more ARs may generate duplicate LLA-based CGAs, each AR will apply its own unique private key signature such that robust IPv6 ND message authentication is supported. For these reasons (and for the reasons explained for MNs above) no Duplicate Address Detection (DAD) testing of CGAs is necessary. 3.2. Processing Rules for Receivers When an OMNI node receives an IPv6 ND message from a neighbor, if both the HMAC and SEND authentication services appear in the same message the node SHOULD process the SEND authentication credentials and ignore the HMAC credentials. If only one authentication service is present, the node SHOULD process the credentials according to the included service. If no authentication services are present (or, if the SEND service is present but the RSA signature option appears before the OMNI option) the node SHOULD regard the IPv6 ND message as unsecured. When the CGA sub-option is included in the OMNI option and the RSA signature option appears later in the IPv6 ND message options, the node verifies the signature per [RFC3971] while observing the updates discussed in Section 4. In any case, if the IPv6 ND message includes an incorrect authentication code the node SHOULD discard the message. 4. SEND/CGA Updates Since their original publications, several important updates to the SEND [RFC3971] and CGA [RFC3972] specifications have been published and are observed as follows: o [RFC4581] defines a format for the CGA parameter data structure extension field. While no extensions are introduced in this document, any future updates to this document that introduce extensions MUST observe this format. Templin Expires July 25, 2021 [Page 5] Internet-Draft OMNI SEND January 2021 o [RFC4982] introduces support for multiple hash algorithms in CGAs. The hash algorithm is identified by a value in the Sec bits of the CGA itself, which must be registered in the IANA "CGA SEC" registry. This document requests a new CGA SEC value "TBD2" for the SHA-256 hash algorithm (see: Section 5 and Section 6). o [RFC6494] defines a certificate profile that supersedes the profile for Router Authorization Certificates. Certificates used in SEND over OMNI interfaces MUST conform to this new certificate profile and MAY conform to the original profile. o [RFC6495] specifies Subject Key Identifier (SKI) Name Type Fields for SEND, which apply also to this document. o [RFC6980] analyzes the security implications of employing IPv6 fragmentation with IPv6 ND messages (especially with regards to SEND) and updates [RFC4861] such that use of the IPv6 Fragmentation Header is forbidden in all ND messages. OMNI interfaces honor [RFC6980] by employing the OMNI Adaptation Layer (OAL) [I-D.templin-6man-omni-interface] to transport IPv6 ND messages no larger than the OMNI interface MTU without causing an IPv6 Fragmentation Header to appear within the IPv6 ND message itself. 5. IANA Considerations IANA is instructed to allocate a new "OMNI option Sub-Type values" registry codepoint for the Cryptographically Generated Address (CGA) sub-option (value TBD). IANA is instructed to allocate a new "CGA SEC" registry codepoint for SHA-256 (value TBD2). 6. Security Considerations The OMNI specification [I-D.templin-6man-omni-interface] provides an HMAC authentication service that can be used for basic client-server authentication based on shared secrets. The SEND service discussed in this document uses X.509 public keys which provide a more flexible and extensible security service, especially for use on large OMNI links that support a dynamically changing collection of many MNs. [RFC6273] provides a hash threat analysis for SEND that concludes: "Current attacks on hash functions do not constitute any practical threat to the digital signatures used in SEND (both in the RSA signature option and in the X.509 certificates). Attacks on CGAs, as described in [RFC4982], will compromise the security of SEND Templin Expires July 25, 2021 [Page 6] Internet-Draft OMNI SEND January 2021 and they need to be addressed by encoding the hash algorithm information into the CGA as specified in [RFC4982]." For this reason, implementations MUST use the SHA-256 hash algorithm for CGAs, as indicated by the value TBD2 appearing in the CGA Sec field (see: Section 5). Future documents MAY specify additional hash algorithm values for the CGA Sec field. OMNI nodes assign CGAs to their OMNI interfaces but do not use them as IPv6 source, destination or target addresses, nor as node identifiers. Instead, OMNI nodes place the CGA in IPv6 ND message OMNI options, use non-CGA addresses for IPv6 packet addressing, and use Universally Unique IDentifiers (UUIDs) [RFC4122][RFC6487] for node identification purposes. The series of consecutively-numbered RFCs beginning with [RFC6480] and extending to [RFC6495] establishes standards and operational practices for secure Internet routing. The series includes updates cited in Section 4 that establish SEND as an integral component of the architecture. OMNI interfaces that use SEND over public Internetworks therefore observe these same principles. 7. Acknowledgements This work is aligned with the NASA Safe Autonomous Systems Operation (SASO) program under NASA contract number NNA16BD84C. This work is aligned with the FAA as per the SE2025 contract number DTFAWA-15-D-00030. This work is aligned with the Boeing Commercial Airplanes (BCA) Internet of Things (IoT) and autonomy programs. This work is aligned with the Boeing Information Technology (BIT) MobileNet program. 8. References 8.1. Normative References [I-D.templin-6man-omni-interface] Templin, F. and T. Whyman, "Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces", draft- templin-6man-omni-interface-68 (work in progress), January 2021. Templin Expires July 25, 2021 [Page 7] Internet-Draft OMNI SEND January 2021 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, . [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, . [RFC4581] Bagnulo, M. and J. Arkko, "Cryptographically Generated Addresses (CGA) Extension Field Format", RFC 4581, DOI 10.17487/RFC4581, October 2006, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007, . [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, . [RFC6494] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND)", RFC 6494, DOI 10.17487/RFC6494, February 2012, . [RFC6495] Gagliano, R., Krishnan, S., and A. Kukec, "Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields", RFC 6495, DOI 10.17487/RFC6495, February 2012, . [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery", RFC 6980, DOI 10.17487/RFC6980, August 2013, . Templin Expires July 25, 2021 [Page 8] Internet-Draft OMNI SEND January 2021 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 8.2. Informative References [I-D.ietf-drip-rid] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, "UAS Remote ID", draft-ietf-drip-rid-06 (work in progress), December 2020. [I-D.templin-duid-ipv6] Templin, F., "The IPv6 Address-based DHCPv6 Unique Identifier (DUID-V6ADDR)", draft-templin-duid-ipv6-01 (work in progress), January 2021. [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, . [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, DOI 10.17487/RFC6273, June 2011, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, . Appendix A. Using Host Identity Tags (HITs) with OMNI/SEND Section 4 of [RFC3971] states: "This specification also allows a node to use non-CGAs with certificates that authorize their use. However, the details of such use are beyond the scope of this specification and are left for future work." Templin Expires July 25, 2021 [Page 9] Internet-Draft OMNI SEND January 2021 The Host Identity Tag (HIT) [RFC7401] is an example of a non-CGA that is also obtained through a cryptographic hash of the node's public key. HITs (and their derivatives known as "Hierarchical HITs" [I-D.ietf-drip-rid]) have several important properties: "The HIT is 128 bits long and has the following three key properties: i) it is the same length as an IPv6 address and can be used in fixed address-sized fields in APIs and protocols; ii) it is self-certifying (i.e., given a HIT, it is computationally hard to find a Host Identity key that matches the HIT); and iii) the probability of a HIT collision between two hosts is very low; hence, it is infeasible for an attacker to find a collision with a HIT that is in use. [RFC7401]" Should IETF consensus determine that (H)HITs represent a preferred solution, the same mechanisms described for CGAs in this document can be used to enable OMNI interface SEND security operations while using (H)HITs. Namely, a new OMNI sub-option will be defined for the purpose of carrying a 128-bit (H)HIT as the sub-option of an OMNI option. The processing rules for senders and receivers specified in Section 3 will be applied in the same fashion as for CGAs, with the exception that the IPv6 ND CGA option which includes the node's public key (and other information) will be associated with the (H)HIT instead of with a CGA. Most importantly, the (H)HIT would be covered under the RSA signature applied to the IPv6 ND message thereby allowing receivers to verify proof of ownership. Use of the (H)HIT as a node identifier can also be considered per future IETF consensus determinations. If the IETF determines that an (H)HIT can be used as a node identifier (i.e., instead of a UUID) the specification of a new Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Device Unique IDentifier (DUID) type may be indicated (see: [I-D.templin-duid-ipv6]). Author's Address Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 Seattle, WA 98124 USA Email: fltemplin@acm.org Templin Expires July 25, 2021 [Page 10]