Internet-Draft Identity Claims March 2020
Wiethuechter, et al. Expires 10 September 2020 [Page]
Workgroup:
DRIP
Internet-Draft:
draft-wiethuechter-tmrid-identity-claims-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
A. Wiethuechter
AX Enterprize
S. Card
AX Enterprize
R. Moskowitz
HTT Consulting

TMRID Identity Claims

Abstract

This document describes 7 Identity Claims for use for Trusted Multipurpose RemoteIDs. These Identity Claims will be used in various Drone RemoteID 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 10 September 2020.

Table of Contents

1. Introduction

This document expands on Hierarchical HIT Registries [hhit-registries], defining defining 7 Identity Claims that are created and distributed through the Registry Provisioning process.

These claims establish trust for Hierarchical HITs [hierarchical-hit]. They are then used in various Drone RemoteID 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.

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 TM-RID there are a total of 7 Identity Claims created during the provisioning of the UA to enable trustworthiness. This section specifies the Host Identity Claims forms in detail, the individual Host Identity Claims created and their use in TM-RID.

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:


 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 TM-RID for entity 'x'. All Host 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).

3.2.1. Cxx Claims

TM-RID uses this form to create three self-signed Host Identity Claims, which are then nested into other Host Identity Claims. The three Host Identity Claims created are:

  • Aircraft on Aircraft (Caa)
  • Operator on Operator (Coo)
  • Registry on Registry (Crr)

These Host Identity 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 Host Identity 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:


 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 certificate. The new Host 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.

3.3.1. Cxy Claims

In TM-RID two Host 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 Host Identity Claims are as follows:

  • Registry on Operator (Cro): Using Crr and Coo as Cxx and Cyy respectively, this Host Identity 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 Host Identity 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:


 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 Host 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 optomization 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 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 TM-RID.

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.

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.

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

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

TBD

7. Acknowledgments

TBD

8. References

8.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <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-01, , <https://tools.ietf.org/html/draft-moskowitz-hip-hhit-registries-01>.
[hierarchical-hit]
Moskowitz, R., Card, S., and A. Wiethuechter, "Hierarchical HITs for HIPv2", Work in Progress, Internet-Draft, draft-moskowitz-hip-hierarchical-hit-04, , <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
Stuart W. Card
AX Enterprize
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Robert Moskowitz
HTT Consulting
Oak Park, MI 48237
United States of America