drip Working Group A. Wiethuechter Internet-Draft AX Enterprize, LLC Intended status: Standards Track 27 September 2024 Expires: 31 March 2025 DRIP Entity Tag (DET) Registration using CoAP & CWTs draft-wiethuechter-drip-det-registration-coap-cwt-00 Abstract This document specifies a registration interaction model and interfaces for DRIP Entity Tags to a DRIP Identity Management Entity using the Constrained Application Protocol and CBOR Web Tokens. 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 31 March 2025. Copyright Notice Copyright (c) 2024 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 to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Wiethuechter Expires 31 March 2025 [Page 1] Internet-Draft det-registration-coap-cwt September 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Interaction Model . . . . . . . . . . . . . . . . . . . . . . 2 4. X.509 Certification Signing Request . . . . . . . . . . . . . 4 5. Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Registration Model . . . . . . . . . . . . . . . . . . . 6 5.2. Response Model . . . . . . . . . . . . . . . . . . . . . 8 5.3. Model Use . . . . . . . . . . . . . . . . . . . . . . . . 8 6. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 9 7. CWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction To properly use a DRIP Entity Tag (DET) it SHOULD be registered to a DRIP Identity Management Entity (DIME). Due to the various components of Unmanned Aircraft System (UAS), typically an Unmanned Aircraft (UA) and Ground Control Station (GCS), sharing similar properties to Internet of Thing (IoT) devices the Constrained Application Protocol (CoAP) [RFC7252] is a good choice for registration interactions between the UAS and DIME. This document specifies registration interactions using CoAP as the transport and CBOR Web Tokens (CWTs) [RFC8392] as the optional secure container. This document only specifies the minimum data models for registration of a DET. Other elements that MAY be required by policy are out of scope for this document. 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. Interaction Model A general interaction model (Figure 1) is used for all DET based registrations. Wiethuechter Expires 31 March 2025 [Page 2] Internet-Draft det-registration-coap-cwt September 2024 registrant dime | | (0) GEN_DET/HI | | (1) GEN_CSR | | |----(2) INPUT----->| | | (3) VALID_INPUT? |<-------FAIL-------| | | (4) DUPE_HI? |<-------FAIL-------| | | (5) DUPE_DET? |<-------FAIL-------| | | (6) GEN_CERTS | | (7) UPDATE_DATABASE | | (8) UPDATE_NS |<----(9) OUTPUT----| Figure 1: Simplified DET Registration Z-Diagram (0) GEN_DET/HI: The registrant that plans to use the identity and its cryptographic properties SHOULD generate the asymmetric key- pair of their choosing and MUST protect the private key with best common practices. The registrant MAY derive the corresponding DET. How the registrant obtains the desired HID for DET generation is out of scope for this document. (1) GEN_CSR: The registrant MUST generate a CSR for their HI/DET. See Section 4 for more details. (2) INPUT: The registrant MUST format and send the required information for a given service registration as specified by the DIME. (3) VALID_INPUT?: The DIME, upon receipt of service registration inputs, MUST validate the input data. This may be simply performing syntax checks to ensure the data is properly formatted all the way to full semantic validation. Signed data MUST have their signatures verified before further processing. Failure of input validation SHOULD return errors to the registrant. (4) DUPE_HI?: The DIME MUST check that the proposed HI is not a duplicate already in use. The registrant SHOULD be notified with an error if duplication is detected. (5) DUPE_DET?: The DIME MUST check that the proposed DET, derived Wiethuechter Expires 31 March 2025 [Page 3] Internet-Draft det-registration-coap-cwt September 2024 from the HI, is not a duplicate already in use. If the registrant proposed a DET with HID outside that of the DIME, it MUST be rejected. If the registrant only provided the HI, the DIME MUST generate the DET using its HID. The registrant SHOULD be notified with an error if duplication is detected. (6) GEN_CERTS: The DIME, after all the above validation, MUST generate a Broadcast Endorsement using the provided HI and DET from the registrant as the evidence. This Endorsement is used in [RFC9575]. An associated X.509 is also generated which signifies the DIME accepts the DET/HI pairing from the registrant (7) UPDATE_DATABASE: The DIME MUST update the Private Information Registry with any PII that was part of the registration. It MAY include additional metadata or public information. How the Private Information Registry is updated is out of scope for this document. (8) UPDATE_NS: The DIME MUST update the Authoritative Name Server with any public information that was part of the registration. This information MUST be stored as described in [DET-DNS]. (9) OUTPUT: The DIME, upon successful updates of the Private Information Registry and Authoritative Name Server, transmits to the registrant the list of Broadcast Endorsements that make up the trust chain for use in [RFC9575]. 4. X.509 Certification Signing Request CSRs MUST be used to convey the various cryptographic and identity properties of a DET during a registration. The subjectName of the CSR is used to determine the type of registration the DET is to be used for. When the subjectName of the CSR is set to SERIAL_NUMBER then the CSR is related to the UA for use as a Session ID and/or an Authentication Key ID. Any other subjectName indicates some other entity using a DET as their identifier and are not in scope for this document. Figure 2 is an example CSR. Wiethuechter Expires 31 March 2025 [Page 4] Internet-Draft det-registration-coap-cwt September 2024 -----BEGIN CERTIFICATE REQUEST----- MIGaME4CAQAwGzEZMBcGA1UEBRMQMTY0OEJHRU4zVE1SMDAwMDAqMAUGAytlcAMh AEV/gIxyi4tbRobDCu0zleb9gmQD4teLQt5FfkCey/XxoAAwBQYDK2VwA0EA3vxm sCGt+qK39V9cfit4UptfqTd+wct7dxOgdmlYL+dTmC4HU1UaM21l0YnDP9CzoH93 4c2wzRrlB/J5BW35DQ== -----END CERTIFICATE REQUEST----- Certificate Request: Data: Version: 1 (0x0) Subject: serialNumber = 1648BGEN3TMR0000 Subject Public Key Info: Public Key Algorithm: ED25519 ED25519 Public-Key: pub: 45:7f:80:8c:72:8b:8b:5b:46:86:c3:0a:ed:33:95: e6:fd:82:64:03:e2:d7:8b:42:de:45:7e:40:9e:cb: f5:f1 Attributes: a0:00 Signature Algorithm: ED25519 de:fc:66:b0:21:ad:fa:a2:b7:f5:5f:5c:7e:2b:78:52:9b:5f: a9:37:7e:c1:cb:7b:77:13:a0:76:69:58:2f:e7:53:98:2e:07: 53:55:1a:33:6d:65:d1:89:c3:3f:d0:b3:a0:7f:77:e1:cd:b0: cd:1a:e5:07:f2:79:05:6d:f9:0d Figure 2: Broadcast RID Session CSR without subjectAltName A CSR without a subjectAltName is indicating to the DIME that they do not know or care which HID and OGA ID they are registered with. In this scenario the DIME MUST generate the DET for the registrant and return it. If the registrant does known which HID and/or OGA ID they want the CSR SHOULD contain the subjectAltName containing the DET they wish to register with. Figure 3 is an example CSR with the subjectAltName. Wiethuechter Expires 31 March 2025 [Page 5] Internet-Draft det-registration-coap-cwt September 2024 -----BEGIN CERTIFICATE REQUEST----- MIHLMH8CAQAwGzEZMBcGA1UEBRMQMTY0OEJHRU4zVE1SMDAwMDAqMAUGAytlcAMh AEV/gIxyi4tbRobDCu0zleb9gmQD4teLQt5FfkCey/XxoDEwLwYJKoZIhvcNAQkO MSIwIDAeBgNVHREBAf8EFDAShxAgAQA//gABBS9EvMRvcVpCMAUGAytlcANBAD1O ZBD16dCvhryQ1qIh5oh60ellac0gymi0dXt9QNZFrAEh3GoJrbpQKNcHc3SArCzJ AgtxkmVaUz7wJ78LXgc= -----END CERTIFICATE REQUEST----- Certificate Request: Data: Version: 1 (0x0) Subject: serialNumber = 1648BGEN3TMR0000 Subject Public Key Info: Public Key Algorithm: ED25519 ED25519 Public-Key: pub: 45:7f:80:8c:72:8b:8b:5b:46:86:c3:0a:ed:33:95: e6:fd:82:64:03:e2:d7:8b:42:de:45:7e:40:9e:cb: f5:f1 Attributes: Requested Extensions: X509v3 Subject Alternative Name: critical IP Address:2001:3F:FE00:105:2F44:BCC4:6F71:5A42 Signature Algorithm: ED25519 3d:4e:64:10:f5:e9:d0:af:86:bc:90:d6:a2:21:e6:88:7a:d1: e9:65:69:cd:20:ca:68:b4:75:7b:7d:40:d6:45:ac:01:21:dc: 6a:09:ad:ba:50:28:d7:07:73:74:80:ac:2c:c9:02:0b:71:92: 65:5a:53:3e:f0:27:bf:0b:5e:07 Figure 3: Broadcast RID Session CSR with subjectAltName 5. Models 5.1. Registration Model Wiethuechter Expires 31 March 2025 [Page 6] Internet-Draft det-registration-coap-cwt September 2024 registration-model = { csrs: [+ csr: csr-data], ? f3411: { ? uas_type: nibble-field, ? uas_ids: uas-id-map, ? self-grp, ? area-grp, ? classification-grp, ? operator-grp, }, ? utm: { operational_intent: #6.37(bstr), uss_uri: #6.32(tstr) / tstr }, * tstr => any } csr-data = [ csr: bstr ? vnb: time, ? vna_offset: uint, ] uas-id-map = { &uas-id-types: [+ uas-id] } uas-id-types = (none: 0, serial: 1, caa_id: 2, utm_id: 3, session_id: 4) uas-id: tstr .size(1..20) / bstr .size(1..20) area-grp = ( area_count: 1..255, area_radius: float, area_floor: float, area_ceiling: float ) classification-grp = ( ua_class: 0..8, eu_class: nibble-field, eu_category: nibble-field ) self-grp = ( desc_type: nibble-field, description: tstr .size(23) ) operator-grp = ( operator_id_type: nibble-field, operator_id: bstr .size(20) ) nibble-field = 0..15 Wiethuechter Expires 31 March 2025 [Page 7] Internet-Draft det-registration-coap-cwt September 2024 Figure 4: Registration Model CDDL The csr-data model allows flexibility of the registrant to specify the time bounds for a given key. Exclusion of either the vnb and/or vna_offset indicates to the DIME to use the defaults of the jurisdiction for the missing datum. Other keys MAY be provided and specified to carry specific data required for the registration to the DIME. Such data can include operator/organizational information. The details of such extension are out of scope for this document. 5.2. Response Model response-model = { registration_cert: bstr / #6.TBD, ? be_chain: [+ be: bstr .size(136)] } Figure 5: Response Model CDDL registration_cert MUST be the Canonical Public Registration Certificate defined in [DET-DNS] in a DER (X.509) or CBOR (C.509) encoding. The be_chain contains the Broadcast Endorsement structures required for [RFC9575] and MUST be sent in responses for a Broadcast RID Session. 5.3. Model Use Below are overviews of variants of the above data models for supported registrations in this document. Other registration types that are defined by RAA and/or HDA policy are out of scope for this document. Broadcast RID Session: Registrations from UA for either Session IDs, Authentication Key IDs or both. It MAY use the f3411 key to provide static F3411 Broadcast RID information. MUST use the be_chain key to return Broadcast Endorsements for [RFC9575]. Operator: MUST NOT use the f3411 key. MUST NOT use the be_chain key. DIME: MUST NOT use the f3411 key. MUST use the be_chain key to return Broadcast Endorsements for [RFC9575]. Wiethuechter Expires 31 March 2025 [Page 8] Internet-Draft det-registration-coap-cwt September 2024 6. CoAP CoAP SHOULD be used using DTLS when possible and MUST send the data model encoded as CBOR. When DTLS is not possible, and CoAP is instead used with UDP, the payload MUST be in a CWT as defined in Section 7. 6.1. Endpoints The base URL of a given URI is out of scope for this document, however the path of such SHOULD be /operator, /aircraft or /broadcast_session per the class of registration. These URIs SHOULD be publicly accessible and discoverable via some mechanism (such as /.well-known/). 7. CWT When a CWT is to be used it SHOULD be encrypted. The CWT is signed by the registrant. For a Broadcast Session the registrant usually is the Operator (or a proxy for the Operator such as the GCS) but MAY be the UA directly if the UA has a long term cryptographic identity. 8. IANA Considerations TBD 9. Security Considerations Cryptographic materials (key-pairs, CSRs, etc.) SHOULD be generated on the device they are intended to be used. There may be scenarios where other parts of the UAS MAY generate the cryptographic materials and provision them as needed during an operation. Any such system SHOULD ensure security of the cryptographic material is guaranteed. 10. References 10.1. Normative References [DET-DNS] Wiethuechter, A. and J. Reid, "DRIP Entity Tags (DET) in the Domain Name System (DNS)", Work in Progress, Internet- Draft, draft-ietf-drip-registries-18, 27 September 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Wiethuechter Expires 31 March 2025 [Page 9] Internet-Draft det-registration-coap-cwt September 2024 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . 10.2. Informative References [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023, . [RFC9434] Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July 2023, . [RFC9575] Wiethuechter, A., Ed., Card, S., and R. Moskowitz, "DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast Remote Identification (RID)", RFC 9575, DOI 10.17487/RFC9575, June 2024, . Author's Address Adam Wiethuechter AX Enterprize, LLC 4947 Commercial Drive Yorkville, NY 13495 United States of America Email: adam.wiethuechter@axenterprize.com Wiethuechter Expires 31 March 2025 [Page 10]