]> Windy Hill Systems, LLC

ekr@rtfm.com

Google

lassey@google.com

Applications and Real-Time Transfer dIGital cREdentialS Securely There are many systems in which people use "digital credentials" to control real-world systems, such as digital car keys, digital hotel room keys, etc. In these settings, it is common for one person to want to transfer their credentials to another, e.g., to share your hotel key. It is desirable to be able to initiate this transfer with a single message (e.g., SMS) which kicks off the transfer on the receiver side. However, in many cases the credential transfer itself cannot be completed over these channels, e.g., because it is too large or because it requires multiple round trips. However, the endpoints cannot speak directly to each other and may not even be online at the same time. This draft defines a mechanism for providing an appropriate asynchronous channel using HTTP as a dropbox. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Transfer dIGital cREdentialS Securely Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction DISCLAIMER: This draft is work-in-progress and has not yet seen significant (or really any) security analysis. It should not be used as a basis for building production systems. There are many systems in which people use "digital credentials" to control real-world systems, such as digital car keys, digital hotel room keys, etc. Generally these are proprietary system-specific credentials are embedded in and used by a (potentially proprietary) mobile app. In these settings, it is common for one person to want to transfer their credentials to another, e.g., to share your hotel key with a family member. Although the credentials and transfer mechanisms are often proprietary they share a common workflow in which:

1. The Sender initiates the transfer from their app and sends an invitation message over a preexisting channel such as SMS or e-mail.
2. Bob receives the invitation message from Alice and hands it to his app (ideally this would happen automatically, e.g., by some URL handler).
3. Bob uses the invitation message to contact Alice to complete the transfer. This may require multiple round trips between Alice and Bob. In addition, Alice or Bob may need to contact some external server, but this is out of scope for this protocol.

The preexisting channel may not be suitable for completing the transfer, for instance because it has insufficient bandwidth. or because it requires manual intervention by the users. In addition, the participants may not be online simultaneously, so a "store-and-forward" channel is required. describes the requirements in more detail. This document specifies how to build such a channel using a standard HTTP server.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Overview of Operation provides a broad overview of the message flow:

Overview of Operation PUT MSG0 ----------------> <-------------------- GET <----------------- DELETE <--------------- PUT MSG1 GET ---------------------> <------------------------- MSG1 DELETE ----------------> ... ]]>

In order to initiate the transfer, Alice generates a random secret value R. She then does the following:

1. Sends R and the address of the HTTP server to Bob over the preexisting channel.
2. Generates the first protocol message MSG0 and stores it in a location on the HTTP server (L0) pseudorandomly generated from R.

When Bob receives the initiating message, he uses R to determine L0, retrieves it from the server, and then deletes it. In order to send a message (MSG1) to Alice, Bob stores it at a new pseudorandom location L1 (again, based on R). Alice retrieves it and then deletes it. Any further message exchanges proceed in the same fashion.

Architectural Model The overall system has the following architecture: The lowest level of operation is a binding to HTTP specifying how to use an HTTP server as a store-and-forward channel, specified in . That channel is then used to carry encrypted messages in the format defined in . Those messages contain an opaque payload that is used by the relevant proprietary credential exchange protocol.

Initiating Message The initiating message needs to contain at least the following three values:

• A URI template. This MUST contain a single variable, named "tigress_location". [[TODO: Need to flesh this out some more.]] This template MUST be for an HTTPS URI.
• A secret value R generated with a cryptographically secure PRNG and containing at least 256 bits of entropy.
• The AEAD algorithm defined using TLS 1.3 cipher suites .

In practice, it will probably contain other information such as the type of credential to be transferred and perhaps some human-readable context. These values are out of topic for this specification. The initiating message SHOULD be delivered over a secure channel but this protocol provides limited security even when that does not happen (see ).

HTTP Binding The basic concept of the HTTP binding is very simple. In order for endpoint A to send a message to endpoint B, A does a PUT to a resource in a predefined secret location. B then does a GET to retrieve the resource and a DELETE to remove it. Receivers MUST delete messages immediately after they have retrieved them. [[OPEN ISSUE: Polling is bad, so we're going to need some kind of notification mechanism, but this document doesn't specify that.]] HTTP requests MUST not contain information from other context (e.g., browser cookies). [[OPEN ISSUE: Can it contain other authentication information, for instance for attestation.]] The URL for message i is generated as follows, using the HKDF-Expand-Label function from TLS 1.3 . [[OPEN ISSUE: This construction puts some secret information (the nonces from the previous messages) in the transcript. Maybe we should instead do a combiner?]] Where "Transcript" is the concatenation of the plaintext of all previous messages and HKDF-Expand-Label uses the hash from the defined cipher suite. The URL is then generated by subsituting the URL-safe base64 encoding for the "tigress_location" variable in the URL template. [[OPEN ISSUE: What is the media type of the message?]] HTTP servers used for this protocol MUST NOT allow enumeration of resources that match the URL template. This protocol operates in a lock-step "ping-pong" fashion. Each endpoint can send exactly one message and then must wait for the other side to reply before sending another. The sender of the credential speaks first.

Message Format All messages are encrypted using the AEAD algorithm specified by the cipher suite, formatted as an O-HTTP "Encapsulated Response" ). The "nonce" MUST be pseudorandomly generated. The encryption key is generated as follows: The plaintext of the message is as follows (using TLS syntax): ; uint16 message_id; opaque message<0..2^32-1>; } TigressPlaintext; ]]> These fields have the following values:

random

A cryptographically random field. The first message in each direction MUST have a random value of at least 16 octets. Subsequent messages MAY contain random values of at any length.

message_id

The sequence number of the message, starting from 0 and incrementing with each message in the exchange. This space is shared and so in practice even numbers are from the credential sender and odd numbers from the receiver. [[OPEN ISSUE: Do we need this? It's basically a double check because the system guarantees uniqueness.]]

message

The proprietary credential exchange message.

Upon receiving a message, an endpoint MUST first deprotect it using the correct key and algorithm. If AEAD deprotection fails, it MUST signal an error and abort the protocol run. Endpoints MUST check that the message_id has the expected value and that the random values are of the right length must signal an error and abort the protocol run if they are incorrect.

Security Considerations The protocol is intended to guarantee the following properties:

1. In order to determine the location of a message, an entity must know both R and the plaintext of every previous message.
2. In order to decrypt a message, an entity must know both R and the plaintext of every previous message.

If R is delivered over a secure channel, then an attacker should not be able to read any message or inject a new one. Because the HTTP server sees messages when they are stored it can delete them or replace them with an invalid message, but because it does not have R it cannot generate a new valid message or replay an old one. The result of this attack is to cause the credential exchange to fail. An attacker other than the server does not know the location of the resource and therefore cannot even store bogus values. If the An attacker who learns R prior to the protocol exchange can simply impersonate the receiver. This is why R should be sent over a secure channel. If it is necessary to send R over an insecure channel then some other mechanism is required to prevent this attack. [[OPEN ISSUE: this is not great, but it seems to be the assumed setting based on list discussion.]] An attacker who learns R after the receiver has retrieved and and deleted the first message will not have the random value from MSG0 and therefore will not be able to determine either the location and encryption key for MSG1, so cannot forge their own message to the sender or any future message. Note that an attacker who learns R after the receiver has retrieved MSG0 but before they have deleted it and replied can race the receiver to respond. If they win the race, then they will be able to complete the protocol exchange with the sender and the receiver will be locked out. This is why it is important for the receiver to delete MSG0 immediately upon retrieval. The reason for including the transcript of all previous messages in the next key and URL is that it straightforwardly includes the random values which each side must send in their first message. It also serves to bind each message to those that came before it, though this does not have a straightforward security rationale. Note that if any message is lost, then the entire exchange fails and so the HTTP server is assumed to be reliable. This is one reason why the delete is explicit rather than a side effect, thus avoiding issues where the retrieval of a message fails but the server thinks it succeeded and deletes the message.

IANA Considerations This document has no IANA actions.

References Normative References The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Mozilla Cloudflare This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages. Informative References Apple Inc Apple Inc Apple Inc Apple Inc Alphabet Inc This document describes the use cases necessitating the secure transfer of Digital Credentials, residing in a Digital Wallet, between two devices and defines general assumptions, requirements and the scope for possible solutions to this problem.

Acknowledgments Thanks to Chris Wood and Martin Thomson for helpful discussions.