DRIP Entity Tag (DET) Registration using CoAP & CWTs
draft-wiethuechter-drip-det-registration-coap-cwt-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Adam Wiethuechter | ||
| Last updated | 2024-09-27 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wiethuechter-drip-det-registration-coap-cwt-00
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-
registries-18>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
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,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
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,
<https://www.rfc-editor.org/info/rfc8126>.
[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,
<https://www.rfc-editor.org/info/rfc9374>.
[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, <https://www.rfc-editor.org/info/rfc9434>.
[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,
<https://www.rfc-editor.org/info/rfc9575>.
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]