]> Google

goto@google.com

Google

mkwst@google.com

Security One Time Password Authentication one-time passcode otp email phishing autofill This document defines the OTP-Token email header field, which can be used to deliver One-Time Passcodes (OTP) in a machine-readable and origin-bound manner alongside the human-readable message carrying that content today. Recipient Message User Agents (rMUA) can collaborate with other entities in the ecosystem to assist in the delivery of these codes to the context which wishes to verify their successful delivery. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction One-time passcodes delivered via email are widely used as part of flows which require verification of a user's contact information. Sign-in/-up flows, reauth for high-risk transactions, account recovery, and so on all might reasonably rely on verifying a user's access to a particular email address by sending a secret code to that address, and waiting for the user to prove that they know what code was sent by typing it into some other context. Today, actions which require verification through email will begin in one context (say, a sign-in form on a website), but require users to hop to another context (their rMUA) to track down the relevant email after waiting for delivery, memorize a short code, and then hop back to the verifying context to type it in. This flow is frustrating, as context-switching leads to confusion and failure. It's also phishable, as users can be tricked into typing a code meant for a trusted context into an attacker-controlled site. showed that a machine-readable, origin-bound format for SMS-based OTPs can reduce both frustration and phishing by making it possible for software to easily extract OTPs and feed them into systems like or a platform's autofill mechanism. This approach can dramatically reduce the friction users experience, only in those cases where the context into which the code is delivered can be verified to be the destination to which the code has asserted a binding. This doesn't prevent phishing as users can still be tricked into typing the code manually, but it's a substantial improvement in the system's general security posture. Learning from that experience, this document proposes two things: first, we can extend the core concept of a standardized delivery format from SMS to email, taking advantage of email's distinction between headers and user-visible content to do so. Second, we suggest that the header can carry information that's supplemental to the short OTP meant for human consumption, and that such information might create additional opportunities to improve the entire system's robustness. It's important to note, however, that these proposals address only one piece of a larger system, allowing automated extraction of OTPs, but leaving important, platform-specific details of their integration with the rest of the system out of scope. Those mechanisms will be defined elsewhere (e.g. HTML defines <input autocomplete="one-time-code">, iOS defines NSTextInput with .oneTimeCode, and so on).

Examples A typical email-based OTP message could contain a header like the following, specifying an OTP code of 123456, and binding that code to the origin https://example.com:

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. This document relies on to define Recpient Mail User Agents (rMUA) and other aspects of email infrastructure. This document further relies on Section 3 of to define a number of concepts around parsing and syntax, including: String, Byte Sequence, Parameters, and the sf-item ABNF rule. This document relies on for the definition of an origin, and on Section 6.2 of that document for its ASCII serialization. The serialized-origin grammar is defined in Section 7.1.

One-Time Passcode A One-Time Passcode is a tuple consisting of:

• code: a string, containing the human-readable OTP.
• origin: an origin to which the code is bound.
• token: null or a byte sequence carrying a machine-readable value intended for automated consumption.
• received: a timestamp set by the rMUA when the OTP is received.

The OTP-Token Header Field The OTP-Token header field delivers an origin-bound OTP, optionally including a high-entropy token. For example: This header is a Structured Field containing a String (Section 3.3.3 of ) representing the OTP, along with with Parameters (Section 3.1.2 of ) representing the origin to which the OTP is bound, and an optional high-entropy token. OTP-Token MUST appear at most once in a message's header section. Instances appearing in the header sections of MIME body parts MUST be ignored. Note that headers including a token Parameter are likely to exceed the 998/78 character limitations specified in Section 2.2.3 of , and will be folded accordingly. specifies how that common case is to be handled.

Parameters The OTP-Token header MUST contain an origin Parameter, and MAY contain a token Parameter:

• origin: This parameter represents the origin to which the OTP is bound. Its value is a String containing the ASCII serialization of an origin conforming to Section 6.2 of . This value MUST not be the serialization of an opaque origin ("null"), MUST be a potentially trustworthy origin as defined in , and MUST be in canonical form (lowercase, default ports omitted, ASCII-only). Note: and / do not entirely agree on origins or their serialization. The constraints above keep them more or less aligned for the subset of origins this document permits; reconciliation beyond that is well outside this document's scope.
• token: This parameter represents a validation token associated with the OTP that's meant for automated systems rather than human interaction. Its value is a Byte Sequence .

Unknown Parameters are ignored in order to make future expansion possible if necessary.

Parsing The following algorithm describes the process of parsing and validating the OTP-Token header into an One-Time Passcode object, given a message and receipt-timestamp. Parsing fails if no valid OTP is available:

1. If message's header section contains zero or more than one OTP-Token header, fail.
2. Let value be the result of unfolding message's header section's OTP-Token header as specified in Section 2.2.3 of .
3. Let parsed be the result of parsing value as specified in Section 4.2 of , with a field_type of "item". If parsing value as a Structured Field fails, fail.
4. If parsed's bare_item is not a String, fail.
5. If parsed's parameters contains no item whose key is "origin", fail.
6. Let origin be the value of parsed's parameters' item whose key is "origin".
7. Fail if any of the following conditions are true:
   • origin is not a String
   • origin does not conform to the serialized-origin grammar defined in Section 7.1 of .
   • origin is "null"
   • origin is not canonical, per .
8. Let token be null.
9. If parsed's parameters contains an item whose key is "token":
   1. Fail if its value is not a Byte Sequence.
   2. Set token to its value.
10. Return a new One-Time Passcode whose:
    • code is parsed's bare_item
    • origin is origin
    • token is token
    • received is receipt-timestamp

Note: has no concept of header folding. The ordering of steps 2 and 3 above is therefore necessary to enable proper parsing of message headers.

Syntax The header's ABNF is as follows:

Security Considerations TODO. Probably something about DKIM?

token Availability? The token value is a bearer token. Its usefulness rests entirely upon its general invisibility to humans, meaning that a user tricked into inputing an OTP will not be able to easily hand it over. While this seems accurate, it is not impossible to overcome. Users could be socially engineered into accessing the message headers via an rMUA's "show original" affordance. Or they could be convinced to forward the email to an attacker, headers and all. Likewise, the token is only as secure as the mailbox itself. In short, token can raise the bar for an attacker, but it does not absolutely prevent phishing.

Shouldn't we focus on more robustly phishing-resistant authentication? Authentication mechanisms like federation and are clearly the directions in which the ecosystem should move. Improvements to OTP delivery are not arguments in the other direction. Still, it's important to recognize that email verification often serves as a last-resort fallback mechanism for account recovery. This document's proposal aims only to create low-cost opportunities to mitigate some of that validation path's inherent risks.

Origin Binding TODO: Say something here about identifying the initiating context's origin and how it'll all be platform-specific.

IANA Considerations IANA is asked to update the Provisional Message Header Field Names registry with the following entry:

• Header Field Name: OTP-Token
• Protocol: mail
• Status: provisional
• Author/Change controller: Mike West
• Reference: This document
• Related information: None

Open Questions

1. Is specifying a single origin enough? Do we need scoping rules to tie OTPs to multiple origins? Sites rather than origins?
2. Rather than relying on the relying party to examine the received timestamp, should we offer a ttl/expires Parameter after which the automated system would refuse to offer the OTP?
3. Should we try to create tighter checks for the OTP's specified origin? That is, should we only accept origin bindings that can be authenticated via DKIM/DMARC?

And, of course, we should bikeshed the naming. OTP-Token, One-Time-Passcode, Super-Secret-Thing-That-Humans-Should-Not-Read, etc.

References Normative References This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. This memo provides information for the Internet community. This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK] This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields. This document obsoletes RFC 8941. 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. Informative References

Acknowledgments This can be considered an email-based implementation of , which paved the way to formalizing a machine-readable format for these short-lived verification codes.