DRIP Entity Tag (DET) Registration using CoAP & CWTs

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.¶

Table of Contents

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.¶

            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----|

(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 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.¶

-----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

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.¶

-----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

5. Models

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

response-model = {
    registration_cert: bstr / #6.TBD,
    ? be_chain: [+ be: bstr .size(136)]
}

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.¶

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.¶

Author's Address