DRIP Identity Claims
draft-wiethuechter-drip-identity-claims-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Adam Wiethuechter , Stuart W. Card , Robert Moskowitz | ||
| Last updated | 2020-03-23 | ||
| RFC stream | (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-identity-claims-00
DRIP A. Wiethuechter
Internet-Draft S. Card
Intended status: Standards Track AX Enterprize
Expires: 24 September 2020 R. Moskowitz
HTT Consulting
23 March 2020
DRIP Identity Claims
draft-wiethuechter-drip-identity-claims-00
Abstract
This document describes 7 Identity Claims for use in various Drone
Remote ID Protocols (DRIP).
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 24 September 2020.
Copyright Notice
Copyright (c) 2020 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 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.
Wiethuechter, et al. Expires 24 September 2020 [Page 1]
Internet-Draft Identity Claims March 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 2
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 2
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. Host Identity Claims . . . . . . . . . . . . . . . . . . . . 3
3.1. Why the term: Host Identity Claims . . . . . . . . . . . 3
3.2. Cxx Form . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.1. Cxx Claims . . . . . . . . . . . . . . . . . . . . . 5
3.3. Cxy Form . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.1. Cxy Claims . . . . . . . . . . . . . . . . . . . . . 7
3.4. Claim Registry on Aircraft . . . . . . . . . . . . . . . 7
4. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. HHIT Delegation . . . . . . . . . . . . . . . . . . . . . 9
4.2. Operator . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Aircraft . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Registry . . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
This document expands on Hierarchical HIT Registries
[hhit-registries], defining defining 7 Identity Claims that are
created and distributed through the provisioning process of a
Unmanned Aircraft in Trustworthy Multipupose Remote ID (TMRID).
These claims establish trust for Hierarchical HITs
[hierarchical-hit]. They are then used in various Drone Remote ID
Protocols to establish the trustworthy claims needed to safely use
the data provided.
2. Terms and Definitions
2.1. Requirements 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.
Wiethuechter, et al. Expires 24 September 2020 [Page 2]
Internet-Draft Identity Claims March 2020
2.2. Definitions
HDA (Hierarchical HIT Domain Authority): The 14 bit field
identifying the HIT Domain Authority under a RAA.
HID (Hierarchy ID): The 32 bit field providing the HIT Hierarchy ID.
RAA (Registered Assigning Authority): The 18 bit field identifying
the Hierarchical HIT Assigning Authority.
3. Host Identity Claims
Under DRIP there are a total of 7 Identity Claims created during the
provisioning of the UA to enable trustworthiness. This document
specifies the Host Identity Claims forms in detail, the individual
Host Identity Claims created and their use in DRIP.
3.1. Why the term: Host Identity Claims
Host Identity Claims are a form of digital certificates, specially
crafted for the UAS/USS ecosystem. The term "certificates" has been
avoided due to the significant technology and legal baggage around
X.509 certificates.
X.509 certificates and Public Key Infrastructure invokes more legal
and public policy considerations than probably any other electronic
communication sector. It emerged as a governmental platform for
trusted identity management and was pursued in intergovernmental
bodies with links into treaty instruments.
Thus there is a common expectation whenever the term "Certificates"
are used, and the term "Host Identity Claims" to carefully separate
these objects from X.509 objects and to emphasize their role as
claims.
3.2. Cxx Form
Cxx is a self-signed Host Identity Claim on entity 'x' with the
following format:
Wiethuechter, et al. Expires 24 September 2020 [Page 3]
Internet-Draft Identity Claims March 2020
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
+---------------+---------------+---------------+---------------+
| |
| Hierarchical |
| Host Identity Tag |
| |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| Host |
| Identity |
| |
| |
| |
+---------------+---------------+---------------+---------------+
| Expiration Timestamp |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| |
| |
| |
| |
| Signature |
| |
| |
| |
| |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
This Host Identity Claim form is used to stake an unverified claim
onto the specified HI/HHIT pairing, until an expiration time, to be
used in DRIP for entity 'x'. All Identity Claims of this form are
116 bytes in length.
The Expiration Timestamp MUST be current UNIX time, at the time of
signing, plus an offset into the future. This offset SHOULD be of
significant length (possibly years).
Wiethuechter, et al. Expires 24 September 2020 [Page 4]
Internet-Draft Identity Claims March 2020
3.2.1. Cxx Claims
DRIP uses this form to create three self-signed Host Identity Claims,
which are then nested into other claims. The three claims created
are:
Aircraft on Aircraft (Caa)
Operator on Operator (Coo)
Registry on Registry (Crr)
These claims (and keypairs needed to create them) SHOULD be created
on the entities that own them. Crr on the Registry, Coo on the
Operator device and Caa on the Aircraft itself (if able).
These claims could also be stored in DNS under the CERT RR [RFC4398].
The value of doing so is currently unknown.
3.3. Cxy Form
Cxy is a binding Host Identity Claim with the following format:
Wiethuechter, et al. Expires 24 September 2020 [Page 5]
Internet-Draft Identity Claims March 2020
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
+---------------+---------------+---------------+---------------+
| |
. .
. Cxx .
. .
| |
+---------------+---------------+---------------+---------------+
| |
. .
. Cyy .
. .
| |
+---------------+---------------+---------------+---------------+
| Timestamp |
+---------------+---------------+---------------+---------------+
| Expiration Timestamp |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| |
| |
| |
| |
| Signature |
| |
| |
| |
| |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
In the Cxy form a binding is asserted between the entities of 'x' and
'y'. The self-signed Host Identity Claims of Cxx and Cyy are used in
the new claim. The new Identity Claims is signed by the first party
(in the example above owner of Cxx) using their keypair.
During Host Identity Claim creation Timestamp and Expiration
Timestamp MUST be UNIX time (with Expiration Timestamp being created
using an offset setting it into the future) and MUST be no later than
the Expiration Timestamps found in Cxx and Cyy.
Wiethuechter, et al. Expires 24 September 2020 [Page 6]
Internet-Draft Identity Claims March 2020
3.3.1. Cxy Claims
In DRIP two Identity Claims are created in the Cxy way, and third one
which is a special nesting of the created Host Identity Claims (but
following the Cxy form). These claims are as follows:
Registry on Operator (Cro): Using Crr and Coo as Cxx and Cyy
respectively, this claims asserts the Registry's Acceptance of the
claims in Coo. This MUST be performed on the Registry. It is 304
bytes in length.
Operator on Aircraft (Coa): Using Coo and Caa (Cxx and Cyy
respectively) this claim asserts a binding between an Operator and
Aircaft. This MUST be performed on the Operator device. It is
304 bytes in length.
Registry on Operator on Aircraft (Croa): A special claim created,
asserting the transitivity between Registry, Operator and
Aircraft. It uses Cro as Cxx and Coa as Cyy. This MUST be
performed on the Registry. It is 608 bytes in length.
The exact methods of transfering data between the entities are out of
scope of this document. It MUST be secure, especially when the
Registry sends back Croa. It is RECOMMENED that HIP be used if
possible, considering that HHITs are being used already.
Croa is special in that it is similiar to an issued automobile
registration. The Operator, once it recieves Croa via a secure
channel from the Registry, should store it somewhere safe to be
recalled if required. It SHOULD not be public availibe, as it can be
classified as Personally Identifiable Information (PII).
It is possible that Cro and/or Coa are stored in DNS and are public
availible as a result. If so, the CERT RR [RFC3498] should be used
to store them. It is unknown the value of storing them in DNS gives.
3.4. Claim Registry on Aircraft
The Registry on Aircraft claim is a special Host Identity Claim
defined as follows:
Wiethuechter, et al. Expires 24 September 2020 [Page 7]
Internet-Draft Identity Claims March 2020
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
+---------------+---------------+---------------+---------------+
| |
| Hierarchical |
| Host Identity Tag |
| |
+---------------+---------------+---------------+---------------+
| |
. .
. Caa .
. .
| |
+---------------+---------------+---------------+---------------+
| Expiration Timestamp |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| |
| |
| |
| |
| Signature |
| |
| |
| |
| |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
This Identity Claim uses the HHIT of the Registry and Caa to form a
short (200 byte) certificate to be used on the Aircraft in Broadcast
Remote ID.
During Host Identity Claim creation the Expiration Timestamp MUST be
UNIX time (with an offset added to it, setting it into the future)
and also MUST be no later than the Expiration Timestamp found in Caa.
The Registry HHIT is substitued for Crr to keep the Host Identity
Claim within the contraints of Broadcast RID payload size. This
optimization does allow for an attacker to attempt a hash collision
on the HHIT. This, the authors argue, would be incredible hard as
the attacker would need to corrupt DNS to go undetected. That is if
a collision on the HHIT is even found in time as it is expected that
Wiethuechter, et al. Expires 24 September 2020 [Page 8]
Internet-Draft Identity Claims March 2020
standard operating procedure for UAS would be to use "one-time"
identifiers.
Cra could also be stored in DNS using the CERT RR [RFC3498]. If this
is of any benefit has not been explored.
4. Provisioning
This section gives an overview of how an Operator then Aircraft are
provisioned under DRIP.
First keypairs are generates on the required devices. Due to
limitations in hardware and connectivity it is acceptable to generate
the Aircraft keypairs and Host Identity Claims on the Operator device
and later embed the data into the Aircraft at the end of
provisioning. The methods to securely perform the action of handling
the data and embedding it into the Aircraft hardware are out of scope
for this document. This section of the document assumes that the
Operator is acting on behalf of the Aircraft.
4.1. HHIT Delegation
Under the FAA NPRM, it is expect that IDs for UAS are assigned by the
UTM and are generally one-time use. The methods for this however is
unspecified leaving two options.
The entity generates its own HHIT, discovering and using the RRA
and HDA for the target Registry. The method for discovering a
Registry's RRA and HDA is out of scope here. This allows for the
device to generate an HHIT to send to the Registry to be accepted
(thus generating the required Host Identity Claim) or denied.
The entity sends to the Registry its HI for it to be hashed and
result in the HHIT. The Registry would then either accept
(returning the HHIT to the device) or deny this pairing.
In either case the Registry must make a decision on if the HI/HHIT
pairing is valid. This in its simplest form is checking the current
Registry for a collision on the HHIT.
Upon accepting a HI/HHIT pair the Registry MUST populate the requried
the DNS serving the HDA with the HIP RR and other relevant RR types
(such as TXT and CERT). The Registry MUST also generate the
appropriate Host Identity Claim for the given operation.
If the Registry denied the HI/HHIT pair, because their was a HHIT
collision or any other reason, the Registry MUST signal back to the
device being provisioned that a new HI needs to be generated.
Wiethuechter, et al. Expires 24 September 2020 [Page 9]
Internet-Draft Identity Claims March 2020
The subsequent sections follow that the device is generating its own
HHIT.
4.2. Operator
+----------+ +---------+
| Registry | ---------> | HDA DNS |
+----------+ HIP RR +---------+
^ |
| |
| |
Coo | | Cro
| |
| v
+----------+
| Operator |
+----------+
The Operator generates his HHIT then Coo and sends Coo (along with
other relevant information if required) to the desired Registry.
The Registry performs Operator registration, by confirming that no
HHIT collisions occur. Coo undergoes a signature verification. If
everything passes the Registry adds the HIP RR and optionally CERT
RRs and TXT RRs into the HDA DNS, generates Cro and transmits it back
to the Operator.
Upon recieving Cro the Operator is now registered in the Registry and
can proceed to provision any Aircraft. Further verification of Cro
can be done, if desired.
4.3. Aircraft
+----------+ +---------+
| Registry | ---------> | HDA DNS |
+----------+ HIP RR +---------+
^ |
| |
| |
Caa, Coa | | Croa, Cra
| |
| v
+----------+ +----------+
| Operator | ---------------------> | Aircraft |
+----------+ Aircraft Keypair, +----------+
Aircraft HHIT,
Caa, Cra
Wiethuechter, et al. Expires 24 September 2020 [Page 10]
Internet-Draft Identity Claims March 2020
The Operator generates the HHIT for the Aircraft along with Caa and
Coa, sending them to the Registry.
The Registry confirms that the Operator is valid user and then begins
Aircraft registration. The HHIT is checked to see if there is a
collision in the current Registry. Caa and Coa undergo a signature
check. Once complete and all passes, then the Registry adds the HIP
RR (and other RRs) to the HDA DNS. The Registry then generates two
Host Identity Claims: Croa and Cra. Both are sent back to the
Operator to signal successful completion of Aircraft registration.
Upon recieving Croa the Operator stores it for safe keeping. After
any additional verification and signature checking Cra, the Aircraft
HHIT and the Aircraft keypair and embedded onto the Aircaft.
4.4. Registry
It should be noted that the Registry can undergo a similar process as
Operator/Aircraft to provision them to an RRA (as a Registry is most
likely the HDA). This is currently not specified here for berevity
of the document.
5. IANA Considerations
TBD
6. Security Considerations
A major consideration is the optimization done in Cra to get its
length down to 200 bytes. The truncation of Crr down to just its
HHIT is one that could be used against the system to act as a false
Registry. For this to occur an attacker would need to find a hash
collision on that Registry HHIT and then manage to spoof all of DNS
being used in the system.
The authors believe that the probabilty of such an attack is low when
Registry operators are using best practices in security. If such an
attack is able to occur (especially in the time frame of "one-time
use IDs") then there are more serious issues present in the system.
7. Acknowledgments
TBD
8. References
8.1. Normative References
Wiethuechter, et al. Expires 24 September 2020 [Page 11]
Internet-Draft Identity Claims March 2020
[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>.
[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>.
8.2. Informative References
[hhit-registries]
Moskowitz, R., Card, S., and A. Wiethuechter,
"Hierarchical HIT Registries", Work in Progress, Internet-
Draft, draft-moskowitz-hip-hhit-registries-02, 9 March
2020, <https://tools.ietf.org/html/draft-moskowitz-hip-
hhit-registries-02>.
[hierarchical-hit]
Moskowitz, R., Card, S., and A. Wiethuechter,
"Hierarchical HITs for HIPv2", Work in Progress, Internet-
Draft, draft-moskowitz-hip-hierarchical-hit-04, 3 March
2020, <https://tools.ietf.org/html/draft-moskowitz-hip-
hierarchical-hit-04>.
Authors' Addresses
Adam Wiethuechter
AX Enterprize
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: adam.wiethuechter@axenterprize.com
Stuart W. Card
AX Enterprize
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: stu.card@axenterprize.com
Robert Moskowitz
HTT Consulting
Oak Park, MI 48237
Wiethuechter, et al. Expires 24 September 2020 [Page 12]
Internet-Draft Identity Claims March 2020
United States of America
Email: rgm@labs.htt-consult.com
Wiethuechter, et al. Expires 24 September 2020 [Page 13]