RFC 7486

HTTP Origin-Bound Authentication (HOBA)

📅 published March 2015, from ietf

HTTP Origin-Bound Authentication (HOBA) 🎀

Okay bestie, here's the title block tea ☕. This is RFC 7486, an Experimental doc from March 2015 (ISSN 2070-1721). It was written by S. Farrell (Trinity College Dublin), P. Hoffman (VPN Consortium), and M. Thomas (Phresheez). The title block doesn't list anything it obsoletes or updates, so it doesn't replace or change any other RFC 💅.

Abstract 💖

Okay so HOBA (HTTP Origin-Bound Authentication) is a digital-signature-based design for an HTTP authentication method. It can also be used for JavaScript-based authentication embedded in HTML 🧚. HOBA is an alternative to HTTP authentication schemes that need passwords, which means it dodges every password-related problem, like leaked server-side password databases. Iconic 👑.

Status of This Memo ✨

This document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🔬.

This document defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the details 🤓.

Info about this document's current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7486 🌸.

Copyright Notice 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 📜. Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💜.

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Interfacing to Applications (Cookies) . . . . . . . . . .   4
  1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
  1.3.  Step-by-Step Overview of HOBA-http  . . . . . . . . . . .   6
2.  The HOBA Authentication Scheme  . . . . . . . . . . . . . . .   6
3.  Introduction to the HOBA-http Mechanism . . . . . . . . . . .   9
4.  Introduction to the HOBA-js Mechanism . . . . . . . . . . . .  10
5.  HOBA's Authentication Process . . . . . . . . . . . . . . . .  11
  5.1.  CPK Preparation Phase . . . . . . . . . . . . . . . . . .  11
  5.2.  Signing Phase . . . . . . . . . . . . . . . . . . . . . .  11
  5.3.  Authentication Phase  . . . . . . . . . . . . . . . . . .  11
6.  Other Parts of the HOBA Process . . . . . . . . . . . . . . .  12
  6.1.  Registration  . . . . . . . . . . . . . . . . . . . . . .  13
    6.1.1.  Hobareg Definition  . . . . . . . . . . . . . . . . .  14
  6.2.  Associating Additional Keys to an Existing Account  . . .  16
    6.2.1.  Moving Private Keys . . . . . . . . . . . . . . . . .  16
    6.2.2.  Human-Memorable One-Time Password (Don't Do This One)  16
    6.2.3.  Out-of-Band URL . . . . . . . . . . . . . . . . . . .  17
  6.3.  Logging Out . . . . . . . . . . . . . . . . . . . . . . .  17
  6.4.  Getting a Fresh Challenge . . . . . . . . . . . . . . . .  17
7.  Mandatory-to-Implement Algorithms . . . . . . . . . . . . . .  18
8.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
  8.1.  Privacy Considerations  . . . . . . . . . . . . . . . . .  18
  8.2.  localStorage Security for JavaScript  . . . . . . . . . .  19
  8.3.  Multiple Accounts on One User Agent . . . . . . . . . . .  20
  8.4.  Injective Mapping for HOBA-TBS  . . . . . . . . . . . . .  20
9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
  9.1.  HOBA Authentication Scheme  . . . . . . . . . . . . . . .  21
  9.2.  .well-known URI . . . . . . . . . . . . . . . . . . . . .  21
  9.3.  Algorithm Names . . . . . . . . . . . . . . . . . . . . .  21
  9.4.  Key Identifier Types  . . . . . . . . . . . . . . . . . .  22
  9.5.  Device Identifier Types . . . . . . . . . . . . . . . . .  22
  9.6.  Hobareg HTTP Header Field . . . . . . . . . . . . . . . .  23
10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
  10.1.  Normative References . . . . . . . . . . . . . . . . . .  23
  10.2.  Informative References . . . . . . . . . . . . . . . . .  24
Appendix A.  Problems with Passwords  . . . . . . . . . . . . . .  26
Appendix B.  Example  . . . . . . . . . . . . . . . . . . . . . .  27
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  28
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28

1. Introduction ✨

Okay so HOBA is an authentication design that can be used as an HTTP authentication scheme [RFC7235] and for JavaScript-based authentication embedded in HTML 🫶. The main goal is to give you an easy-to-implement scheme that isn't based on passwords, but that can easily replace HTTP or HTML forms-based password authentication. Deploying HOBA can reduce or eliminate password entries in databases, which comes with potentially significant security benefits 🔐.

HOBA is an HTTP authentication mechanism that complies with the framework for such schemes [RFC7235]. As a JavaScript design, HOBA shows a way for clients and servers to interact using the same credentials that the HTTP authentication scheme uses 💅.

Username/password methods like HTTP Basic, HTTP Digest, and web forms have been around for years, but they're vulnerable to theft of server-side password databases 😭. So instead of passwords, HOBA uses digital signatures in a challenge-response scheme. It also adds handy features like credential management and session logout 🍓. In HOBA, the client makes a brand-new public-private key pair for each host ("web origin" [RFC6454]) it authenticates to. Those keys are used so HTTP clients can prove who they are to servers, either in the HTTP protocol or in a JavaScript authentication program 🦋.

HOBA session management works exactly like username/password session management, where a server-side session management tool or script puts a session cookie [RFC6265] into the output sent to the browser. You still need Transport Layer Security (TLS) for the HTTP session to prevent session cookie hijacking 🔒.

HOBA keys are "bare keys", so there's no need for the semantic overhead of X.509 public key certificates, especially when it comes to naming and trust anchors 🙅‍♀️. The Client Public Key (CPK) structures in HOBA don't have any publicly visible identifier for the user who holds the matching private key, or for the web origin the client is using the CPK with 🕵️‍♀️.

HOBA also defines some services that modern HTTP authentication needs:

Servers can bind a CPK with an identifier, such as an account name. Servers using HOBA define their own policies for binding CPKs with accounts during account registration 📝.
Users are likely to use more than one device or User Agent (UA) for the same HTTP-based service, so HOBA gives a way to associate more than one CPK with the same account, without having to register for each one separately 📱💻.
Logout features are useful for UAs, so HOBA defines a way to close a current HTTP "session" 👋.
Digital signatures can be expensive to compute, so HOBA defines a way for HTTP servers to say how long a given challenge value is valid, and a way for UAs to fetch a fresh challenge at any time ⏳.

Users are also likely to lose a private key, or the client's memory of which key pair goes with which origin, like when someone loses the computer or mobile device where the state was stored 😱. HOBA does not define a mechanism for deleting the association between an existing CPK and an account. Such a mechanism can be implemented at the application layer 🧹.

The HOBA scheme is far from new. For example, the basic idea is pretty much identical to the first two messages from "Mechanism R" on page 6 of [MI93], which predates HOBA by 20 years 🕰️.

1.1. Interfacing to Applications (Cookies) 🍪

HOBA can be a drop-in replacement for password-based user authentication schemes in common web applications. The simplest way is to (re)direct the UA to a HOBA "Login" URL, and for the response to a successful HTTP request containing a HOBA signature to set a session cookie [RFC6265]. After that, interactions with the web application are secured through the session cookie, just like they usually are today 💖.

Cookies are bearer tokens and therefore weaker than HOBA signatures, but they're still everywhere 🥲. If non-bearer token session continuation schemes get developed in the future, in the IETF or elsewhere, they can interface with HOBA as easily as with any password-based authentication scheme 🚀.

1.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 RFC 2119 [RFC2119] 🎯.

This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] 🧩.

Account: The term "account" is (loosely) used to refer to whatever data structure(s) the server keeps that are tied to an identity. It contains at least one CPK and a web origin, and it can also optionally include an HTTP "realm" as defined in the HTTP authentication specification [RFC7235]. It might have lots of other non-standard data the server collects during account creation 🗃️. An account can have many CPKs that count as equivalent for authentication, but what "equivalent" means is up to the server and isn't defined here 🤷‍♀️.

Client public key (CPK): A CPK is the public key and the associated cryptographic parameters a server needs to validate a signature 🔑.

HOBA-http: We use this term when describing something specific to HOBA as an HTTP authentication mechanism 🌐.

HOBA-js: We use this term when describing something that's unrelated to HOBA-http but relevant for HOBA as a design pattern that can be implemented in a browser in JavaScript 🧃.

User agent (UA): Typically, but not always, a web browser 🌍.

User: A person who is running a UA. In this document, "user" does not mean "user name" or "account name" 🙃.

Web client: The content and JavaScript code that run within the context of a single UA instance, like a tab in a web browser 🎀.

1.3. Step-by-Step Overview of HOBA-http 🦋

okay bestie, here's how a typical HOBA-http registration and login flow goes, step by step 💅

The client connects to the server and makes a request. The server's response includes a WWW-Authenticate header field that contains the "HOBA" auth-scheme, along with associated parameters (see Section 3). 🌸
If the client wasn't already registered with the web origin and realm it's trying to access, the "joining" process kicks off (see Section 6.1). This creates a key pair and makes the CPK known to the server, so the server can do all the account creation stuff it needs to do. 🔑
The client takes the challenge from the HOBA auth-scheme parameters, plus whatever else it knows about the web origin and realm, and uses them to create and sign a HOBA to-be-signed (HOBA-TBS) string (see Section 2). ✍️
The client makes a HOBA client-result (HOBA-RES), using the signed HOBA-TBS for the "sig" value (see Section 2). 🎀
The client includes the Authorization header field in its next request, using the "HOBA" auth-scheme and putting the HOBA client-result in an auth-param named "result" (see Section 3). 📬
The server authenticates the HOBA client-result (see Section 5.1). 🛡️
Typically, the server's response includes a session cookie, so the client can show its authentication state in future requests (see Section 1.1). 🍪

2. The HOBA Authentication Scheme 💜

okay so a UA that implements HOBA keeps a list of web origins and realms 📝 It also holds one or more client credentials for each web origin/realm combination it has made a CPK for 🔐

when a client gets a challenge (and optional realm) from a server, it marshals a HOBA-TBS blob. That blob includes a client-generated nonce, the web origin, the realm, an identifier for the CPK, and the challenge string 🧁 The client then signs the blob with the private key that matches the CPK for that web origin. The format of this TBS blob was picked specifically to make server-side signature verification as simple as possible across a wide range of current server tooling. it's giving efficiency ✨

Figure 1 spells out the ABNF for the signature input. The term "unreserved" means the field has no specific format defined and allows the characters listed in Section 2.3 of [RFC3986].

   HOBA-TBS = len ":" nonce
           len ":" alg
           len ":" origin
           len ":" [ realm  ]
           len ":" kid
           len ":" challenge
   len = 1*DIGIT
   nonce = 1*base64urlchars
   alg = 1*2DIGIT
   origin = scheme "://" authority ":" port
   ; scheme, etc., are from RFC 3986
   realm = unreserved
   ; realm is to be treated as in Section 2.2 of RFC 7235
   kid = 1*base64urlchars
   challenge = 1*base64urlchars
   ; Characters for Base64URL encoding from Table 2 of RFC 4648
   ; all of which are US-ASCII (see RFC 20)
   base64urlchars = %x30-39             ; Digits
                 / %x41-5A           ; Uppercase letters
                 / %x61-7A           ; Lowercase letters
                 / "-" / "_" / "="   ; Special characters

Figure 1: To-Be-Signed Data for HOBA

here's what each field is giving:

len: every field is preceded by the number of octets in the following field, written as a decimal number in ASCII [RFC20]. The length gets separated from the field value by a colon. So if a nonce with the value "ABCD" were used, it would be preceded by "4:" (see the example in Appendix B for details).
nonce: a random value chosen by the UA. It MUST be base64url encoded before being included in the HOBA-TBS value. (base64url encoding is defined in [RFC4648]; guidelines for randomness are given in [RFC4086].) UAs MUST be able to use at least 32 bits of randomness when generating a nonce. UAs SHOULD be able to use 64 or more bits of randomness for nonces. 🎲
alg: specifies the signature algorithm being used. See Section 7 for details of algorithm support requirements. The IANA-registered algorithm values (see Section 9.3) are encoded as one- or two-digit ASCII numbers. For example, RSA-SHA256 (number 0) is encoded as the ASCII character "0" (0x30), while a future algorithm registered as number 17 would be encoded as the ASCII characters "17" (0x3137). 🔢
origin: the web origin, written as the concatenation of the scheme, authority, and port from [RFC3986]. These aren't base64 encoded, since the server will most readily have them in plain text. For example, if accessing the URL "https://www.example.com:8080/foo", then the bytes input to the signature process will be "https://www.example.com:8080". There is no default for the port number, and the port number MUST be present. 🌐
realm: a string with the syntactic restrictions defined in [RFC7235]. If no realm is specified for this authentication, it's absent but still preceded by a length of zero ("0:"). Recall that both sides know when this needs to be there, independent of the encoding via a zero length. 🫶
kid: a key identifier. This MUST be a base64url-encoded value that is presented to the server in the HOBA client result (see below). 🪪
challenge: MUST be a base64url-encoded challenge value that the server chose to send to the client. The challenge MUST be chosen so that it is infeasible to guess, and SHOULD be indistinguishable from (the base64url encoding of) a random string that is at least 128 bits long. 🧩

The HOBA-TBS string is the input to the client's signing process, but it's not itself sent over the network, since some fields are already inherent in the HTTP exchange. The challenge, however, IS sent over the network, so servers don't have to keep as much state around. (One form of stateless challenge might be a ciphertext that the server decrypts and checks, but that's an implementation detail.) The value the UA actually sends over the network is the HOBA "client result", which we define now 👀

The HOBA "client result" is a dot-separated string that includes the signature. It goes in the HTTP Authorization header field value, using the value syntax in Figure 2. The "sig" value is the base64url-encoded version of the binary output of the signing process. The kid, challenge, and nonce are as defined above, and they're also base64url encoded.

   HOBA-RES = kid "." challenge "." nonce "." sig
   sig = 1*base64urlchars

Figure 2: HOBA Client Result Value

⚠️ If a malformed message of any kind is received by a server, the server MUST fail authentication. If a malformed message of any kind is received by a client, the client MUST abandon that authentication attempt. (The client is, of course, free to start another authentication attempt if it desires.) 💀

3. Introduction to the HOBA-http Mechanism 🧚

an HTTP server that supports HOBA authentication includes the "HOBA" auth-scheme value in a WWW-Authenticate header field when it wants the client to authenticate with HOBA. Note that HOBA might not be the only auth-scheme the server includes in a WWW-Authenticate header 🌈

The HOBA scheme has two REQUIRED attributes (challenge and max-age) and one OPTIONAL attribute (realm):

The "challenge" attribute MUST be included. The challenge is the string made up of the base64url-encoded octets that the server wants the client to sign in its response. The challenge MUST be unique for every 401 HTTP response, so replay attacks from passive observers don't work 🙅‍♀️
A "max-age" attribute MUST be included. It specifies the number of seconds from the time the HTTP response is emitted during which responses to this challenge can be accepted. For example, "max-age: 10" would indicate ten seconds. If max-age is set to zero, then only one signature will be accepted for this challenge. ⏱️
A "realm" attribute MAY be included to indicate the scope of protection, in the manner described in HTTP/1.1, Authentication [RFC7235]. The "realm" attribute MUST NOT appear more than once. 🏷️

When the "client response" gets created, the UA encodes the HOBA client-result and returns it in the Authorization header. The client-result is a string matching the HOBA-RES production in Figure 2, as an auth-param with the name "result" 📦

The server MUST check the cryptographic correctness of the signature based on a public key it knows for the kid in the signatures. If the server can't do that, or if the signature fails cryptographic checks, then validation has failed. The server can use any additional mechanisms to validate the signature. If validation fails, or if the server chooses to reject the signature for any reason whatsoever, the server fails the request with a 401 Unauthorized HTTP response. 🚫

The server MUST check that the same web origin is used in all of the server's TLS server certificates, the URL being accessed, and the HOBA signature. If any of those checks fail, the server treats the signature as being cryptographically incorrect. 🔒

Note that a HOBA signature is good for however long a non-zero max-age parameter allows. This means replay is possible within the time window set by the "max-age" value the server chose. Servers can attempt to detect any such replay (via caching, if they so choose) and MAY react to such replays by responding with a second (or subsequent) 401 HTTP response containing a new challenge. 🔁

To optimize their use of challenges, UAs MAY prefetch a challenge value, for example, after (max-age)/2 seconds have elapsed, using the ".well-known/hoba/getchal" scheme described later in this document. This also allows for precalculation of HOBA signatures, if that's required in order to produce a responsive user interface. ⚡

4. Introduction to the HOBA-js Mechanism ✨

Okay so, websites using JavaScript can do origin-bound authentication too, and they don't need the HTTP layer to do it 🌸 That means they don't need HOBA-http support in browsers either! HOBA-js isn't an on-the-wire protocol like HOBA-http is. It's a design pattern that you can build completely in JavaScript, served in normal HTML pages 💖

WebCrypto (see http://www.w3.org/TR/WebCryptoAPI) is highly desirable for HOBA-js, and at the time of writing it's starting to get deployed 🔥 If you don't have WebCrypto, you can use JavaScript crypto libraries instead, but those come with known weaknesses in their pseudo-random number generators and they're generally still pretty immature 💀

Without WebCrypto, there's one thing HOBA-js requires: localStorage (see http://www.w3.org/TR/webstorage/) from HTML5, which can be used for persistent key storage 🗝️ For example, an implementation would store a dictionary account identifier, plus public key and private key tuples, in the origin's localStorage so it can use them for later authentication requests. How that information gets stored in localStorage is an implementation detail, so it's up to you 🎀 This kind of key storage relies on the security properties of the same-origin policy that localStorage enforces. Check the security considerations for the scoop on attacks against localStorage 😭 Also, IndexedDB (see http://www.w3.org/TR/IndexedDB/) is an alternative to localStorage that can be used here too, and it's the one WebCrypto uses 👑

Because of JavaScript's same-origin policy, scripts on subdomains can't access the same localStorage that scripts on their parent domains can 🙈 For bigger or more complicated sites, this can turn into a real problem that requires enrolling into each subdomain, and that could be really hard for users. One way around it is to use session cookies, since they can be shared across subdomains 🧚 So with HOBA-js, the user might log in through one well-known domain, and then session cookies carry them along while they browse the rest of the site 🦋

5. HOBA's Authentication Process 💅

This section explains how clients and servers use HOBA to authenticate, and it's giving main character energy 🌈 An HTTP client and HTTP server using HOBA go through three phases: the CPK preparation phase, the signing phase, and the authentication phase. This section also covers the actions that give HOBA features similar to today's password-based schemes 🔐

5.1. CPK Preparation Phase

In the CPK preparation phase, the client checks whether it already has a CPK for the web origin it needs to authenticate with 👀 If the client already has one, it uses that one. If it doesn't, it generates one ahead of time, just in case the server asks for it ✨

5.2. Signing Phase

In the signing phase, the client connects to the server, the server asks for HOBA-based authentication, and the client authenticates by signing a blob of information, as described in the previous sections 🖊️

5.3. Authentication Phase

The authentication phase depends entirely on the policies and practices of the server 🫠 So this phase doesn't involve any standardized protocol in HOBA-http, and in HOBA-js there's no suggested interaction template either. Honestly, it's a choose-your-own-adventure 🍓

In the authentication phase, the server uses the key identifier (kid) to find the CPK from the signing phase, and then decides whether it recognizes that CPK 🔍 If it does, the server may finish the client authentication process 🎉

If this stage needs extra information for authentication, like asking the user which account they want to use (say a UA is used for multiple accounts on a site), the server can prompt the user for account identifying information. Or the user could pick based on HTML the server offered before the 401 response got triggered 🧐 None of this is standardized. It all follows the server's security policy and session flow. At the end of all this, the server probably assigns or updates a session cookie for the client 🍪

During the authentication phase, if the server can't work out the correct CPK, it could use HTML and JavaScript to ask the user whether they're really a new user or want to link this new CPK to another one 🤔 Then the server can use an out-of-band method (like a confirmation email round trip, SMS, or a UA that's already enrolled) to verify that the "new" user is the same as the already-enrolled one 📱 So logging in on a new UA is exactly the same as logging in to an existing account. Iconic, honestly 👑

If the server doesn't recognize the CPK, it might send the client through either a join or login-new-UA process (see below) 🚪 This process is completely up to the server. It probably involves HTML and JavaScript asking the user some questions to figure out whether the server wants to give the client an account. Finishing the joining process might require confirmation by email, SMS, CAPTCHA, and so on 🤖

Also, the server doesn't have to start a joining or login process just because the signing phase finished 💁‍♀️ In fact, the server might want to challenge the UA even for unprotected resources, and set a session cookie to use later in a join or login process when it's needed. For example, a server might only want to offer an account to someone who has been to a few pages on the site. In that case, the server could use the CPK from an associated session cookie to build up the user's reputation until it's ready for them to join 🌟

6. Other Parts of the HOBA Process 🫶

Authentication is more than just the act of authenticating 💅 In both password-based authentication and HOBA, there are other processes needed before and after the authentication step. This section covers those processes. Where possible, it mixes HOBA-http and HOBA-js practices, and where that isn't possible, the differences get called out 📝

All HOBA interactions other than those defined in Section 5 MUST be performed in TLS-protected sessions [RFC5246]. If the current HTTP traffic isn't running under TLS, a new session gets started before any of the actions described here are performed 🔒

HOBA-http uses a well-known URI [RFC5785] "hoba" as a base URI for lots of tasks: "https://www.example.com/.well-known/hoba" (you'll spot the pattern, bestie 🧚). These URIs are based on the name of the host the HTTP client is accessing 🌐

There are lots of use cases where these URLs redirect to other URLs. For example, a site might do registration through a federated site, or a site might only do registration under HTTPS, and so on 🔀 Like any HTTP client, HOBA-http clients have to be able to handle redirection of these requests. But redirects could cause security issues when they send the client to a different web origin, so servers implementing HOBA-http SHOULD NOT redirect to a different web origin from below ".well-known/hoba" URLs. The above is considered enough to allow experimentation with HOBA. But if HOBA ever goes onto the Standards Track, a full analysis of off-origin redirections would need to be documented 📚

6.1. Registration

Normally, registration (also called "joining") is expected to happen after a UA gets a 401 response for a web origin and realm (for HOBA-http), or on demand (for HOBA-js), when it has no associated CPK 🎀 Registering a HOBA account on a server is pretty lightweight. The UA generates a new key pair and associates it with that web origin and realm 💜

Note that if the UA has a CPK associated with the web origin but not for the realm concerned, then a new registration is REQUIRED. If the server didn't want that outcome, then it ought to use the same realm or no realm at all 🙃

The registration message for HOBA-http is sent as a POST message to the URL ".well-known/hoba/register", as an HTML form (x-www-form-encoded, see http://www.w3.org/TR/2014/REC-html5-20141028/forms.html#url-encoded-form-data). The fields are described below 📋 The registration message for HOBA-js can be in any format the server specifies, but it could be the same as the one described here for HOBA-http. It's up to the server to decide what kind of user interaction is needed before the account is finally set up ✨ When the server's chosen registration flow completes successfully, the server MUST add a Hobareg HTTP header (see Section 6.1.1) to the HTTP response message that completes the registration flow 🥳

The registration message sent to the server has one mandatory field (pub), plus some optional fields that let the UA specify the type and value of the key and device identifiers it wants to use 🗂️

pub: a mandatory field containing the Privacy Enhanced Mail (PEM) formatted public key of the client. See Appendix C of [RFC6376] for an example of how to generate this key format 🔑
kidtype: contains the type of key identifier. This is a numeric value intended to contain one of the values from Section 9.4. If this isn't present, then the mandatory-to-implement hashed public key option MUST be used 🔢
kid: contains the key identifier as a base64url-encoded string that's of the type indicated in the kidtype. If the kid is a hash of a public key, then the correct (base64url-encoded) hash value MUST be provided, and the server SHOULD check that and refuse the registration if an incorrect value was supplied 🧾
didtype: specifies a kind of device identifier, intended to contain one of the values from Section 9.5. If absent, then the "string" form of device identifier defined in Section 9.5 MUST be used 📱
did: a UTF-8 string that specifies the device identifier. This can help a user feel confident that authentication worked. For example, after authentication, some web content might say "You last logged in from device 'did' at time T." 🥰

Note that replaying registration (and other HOBA) messages is totally possible 😬 That can be counteracted if challenge freshness is ensured. See Section 2 for details. Also note that with HOBA-http, the HOBA signature does not cover the POST message body. If that's required, then HOBA-JS may be a better fit for registration and other account management actions 💀

6.1.1. Hobareg Definition ✨

Okay so registration can be a whole multi-step saga 📝, like the site wants you to fill in your contact details first. That means the initial response to the HTTP POST message defined above can come back with a 200 OK status and still NOT be the end of the process 😭. This is a big mood problem for the UA. While it's stuck on interstitial pages, it doesn't know yet whether the CPK is good for that web origin or not 🙈.

So the server MUST add a header field to the response message when registration has succeeded, to show the new state 💅. The header is called Hobareg, and the value for success is regok 🎀. When registration is in an intermediate state (like an HTTP response for an interstitial page), the server MAY add this header with a value of reginwork 🌀. Check Section 9.6 for the IANA registration of this header field 📚.

For interstitial pages, the client MAY include a HOBA Authorization header 🫶. This is not considered a "MUST", because that might needlessly complicate client implementations 😩. It's flagged here anyway, in case a server implementer assumes that every registration message has a HOBA Authorization header.

      Hobareg-val = "regok" / "reginwork"

Figure 3: Hobareg Header Field Definition

Figure 3 gives you the ABNF for the values allowed in the Hobareg header field 🔥. Note that these values (and the header field name) are case insensitive 💜. Section 8.3.1 of [RFC7231] wants the following details documented for this new header field, so here we go 👑:

Only one single value is allowed in a Hobareg header field. Should more than one value (a list) be encountered, or any other ABNF-invalid value, that SHOULD be interpreted as being the same as "reginwork".
The Hobareg header field can only be used in HTTP responses.
Since Hobareg is only meant for responses, it ought not appear in requests.
The HTTP response code does affect the interpretation of Hobareg. Registration is only considered to have succeeded if the regok value is seen in a 2xx response. 4xx and other errors mean that registration has failed, regardless of the value of Hobareg seen. The request method has no influence on the interpretation of Hobareg.
Intermediaries never insert, delete, or modify a Hobareg header field.
As a response-only header field, it is not appropriate to list a Hobareg in a Vary response header field.
Hobareg is allowed in trailers.
As a response-only header field, Hobareg will not be preserved across re-directs.
Hobareg itself discloses little security- or privacy-sensitive information. If an attacker can somehow detect that a Hobareg header field is being added, then that attacker would know that the UA is in the process of registration, which could be significant. However, it is likely that the set of messages between the UA and server would expose this information in many cases, regardless of whether or not TLS is used. Using TLS is still, however, a good plan 🔒.

6.2. Associating Additional Keys to an Existing Account 🗝️

From the user's perspective, the UA having a CPK for a web origin will often feel like having a way to sign in to an account at that website 🧚. Users often have more than one UA, and the CPKs are, in general, UA specific. So the question becomes how the user can sign in to that account from different UAs. From the server's perspective, that turns into the question of how to safely bind different CPKs to one account 🤔. In this section, we describe some ways in which this can be done, plus one way in which this ought not be done 🙅‍♀️.

The context here is usually that the user has succeeded in registering with one or more UAs (for the purposes of this section, we call this "the first UA" below) and can use HOBA with those. Now the user is adding another UA. The newest UA might or might not have a CPK for the site in question. Since it is in fact trivial, we assume that the site is able to put in place some appropriate, quicker, easier registration for a CPK for the newest UA ⚡. The issue then becomes binding the CPK from the newest UA with those of the other UAs bound to the account.

6.2.1. Moving Private Keys 🚚

It is common for a user to have multiple UAs and to want all of them to be able to authenticate to a single account 📱💻. One method to let a user with an existing account authenticate on a second device is to securely transport the private and public keys and the origin information from the first device to the second. If this approach is taken, then there is no impact on the HOBA-http or HOBA-js. So this is a pure UA implementation issue and not discussed further 🌸.

6.2.2. Human-Memorable One-Time Password (Don't Do This One) 🚫

It will be tempting for implementers to use a human-memorable One-Time Password (OTP) in order to "authenticate" binding CPKs to the same account 😬. The workflow here would likely be something along the lines of a server administrative utility generating a human-memorable OTP such as "1234", then sending that to the user out of band for the user to enter at two web pages, each authenticated via the relevant CPK. While this seems obvious enough and could even be secure enough in some limited cases, we consider that this is too risky to use on the Internet, so servers SHOULD NOT provide such a mechanism 💀. The reason this is so dangerous is that it would be trivial for an automated client to guess such tokens and "steal" the binding intended for some other user. At any scale, there would always be some in-process bindings, so even with only a trickle of guesses (and hence not being detectable via message volume), an attacker would have a high probability of succeeding in registering a binding with the attacker's CPK.

This method of binding CPKs together is therefore NOT RECOMMENDED 🙅‍♀️.

6.2.3. Out-of-Band URL 🔗

One easy binding method is to simply provide a web page where, using the first UA, the user can generate a URL (containing some "unguessable" cryptographically generated value). The user then later dereferences that URL on the newest UA 💫. The user could email that URL to themselves, for example, or the web server accessed at the first UA could do that automatically 📧.

Such a URL SHOULD contain at least the equivalent of 128 bits of randomness 🎲.

6.3. Logging Out 👋

The user can tell the server they want to log out 🚪. With HOBA-http, this is done by sending a HOBA-authenticated POST message to the URL ".well-known/hoba/logout" on the site in question. The UA SHOULD also delete session cookies associated with the session, so that the user's state is no longer "logged in" 🍪.

The server MUST NOT allow TLS session resumption for any logged out session 🛑.

The server SHOULD also revoke or delete any cookies associated with the session 🧹.

6.4. Getting a Fresh Challenge 🆕

The UA can get a "fresh" challenge from the server ✨. In HOBA-http, it sends a POST message to ".well-known/hoba/getchal". If successful, the response MUST contain a fresh (base64url-encoded) HOBA challenge for this origin in the body of the response. Whitespace in the response MUST be ignored 🫧.

7. Mandatory-to-Implement Algorithms 🔐

RSA-SHA256 MUST be supported. HOBA implementations MUST use RSA-SHA256 if it is provided by the underlying cryptographic libraries 💪. RSA-SHA1 MAY be used 🤷‍♀️. RSA modulus lengths of at least 2048 bits SHOULD be used 🔑. RSA indicates the RSASSA-PKCS1-v1_5 algorithm defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS] 📖. Keys with moduli shorter than 2048 bits SHOULD only be used in cases where generating 2048-bit (or longer) keys is impractical, e.g., on very constrained or old devices 🧓📟.

8. Security Considerations 🚨

Binding my CPK with someone else's account would be fun and profitable, so SHOULD be appropriately hard 😈. (Yes, the spec really says that. Iconic.) In particular, URLs or other values generated by the server as part of any CPK binding process MUST be hard to guess, for whatever level of difficulty is chosen by the server 🔒. The server SHOULD NOT allow a random guess to reveal whether or not an account exists 🫣.

If key binding was server selected, then a bad actor could bind different accounts belonging to the user from the network, with possible bad consequences, especially if one of the private keys was compromised somehow 💀.

When the max-age parameter is not zero, a HOBA signature has a property that is like a bearer token for the relevant number of seconds: it can be replayed for a server-selected duration ⏳. Similarly, for HOBA-js, signatures might be replayable depending on the specific implementation. The security considerations of [RFC6750] therefore apply in any case where the HOBA signature can be replayed 🚩. Server administrators can set the max-age to the minimum acceptable value in such cases, which would often be expected to be just a few seconds ⏱️. There seems to be no reason to ever set the max-age more than a few minutes, and the value ought also to decrease over time as device capabilities improve 📉. The administrator will most likely want to set the max-age to something that is not too short for the slowest signing device that is significant for that site 🐢.

8.1. Privacy Considerations 🕵️‍♀️

HOBA does, to some extent, impact privacy. It could be considered a super-cookie to the server, or to any entity on the path from UA to HTTP server that can see the HOBA signature 🍪👀. This is because we need to send a key identifier as part of the signature, and that will not vary for a given key. For this reason, and others, it is strongly RECOMMENDED to only use HOBA over server-authenticated TLS, and to migrate web sites using HOBA to only use "https" URLs 🔐🌈.

UAs SHOULD provide users a way to manage their CPKs 🎛️. Ideally, there would be a way for a user to maintain their HOBA details for a site while at the same time deleting other site information, such as cookies or non-HOBA HTML5 localStorage. However, as this is likely to be complex, and the appropriate user interfaces counterintuitive, we expect that UAs that implement HOBA will likely treat HOBA information as just more site data that would disappear should the user choose to "forget" that site 🗑️.

Device identifiers are intended to specify classes of device in a way that can assist with registration, and with presenting the user with information about previous sessions, e.g., last login time 📅. Device identifier types MUST NOT be privacy sensitive, with values that would allow tracking a user in unexpected ways 🚫. In particular, using a device identifier type that is analogous to the International Mobile Equipment Identifier (IMEI) would be a really bad idea, and is the reason for the "MUST NOT" above 📵. In that case, "mobile phone" could be an acceptable choice 📱.

If possible, implementations ought to encourage the use of device identifier values that are not personally identifying except for the user concerned 🫶. For example, "Alice's mobile" is likely to be chosen and is somewhat identifying, but "Alice's phone: UUID 1234-5567-89abc-def0" would be a very bad choice 😭.

8.2. localStorage Security for JavaScript

okay bestie, let's talk about localStorage 🥺💅 Using localStorage (probably with a non-WebCrypto build of HOBA-js) is gonna be a whole concern, and that's not a vibe 😭. localStorage uses the same-origin model, which means the scheme, domain, and port together define which localStorage instance you get 🌐. Beyond that, any code that runs there can access the private keying material 💀. The scariest one is Cross-Site Scripting (XSS) attacks, since they could grab the keys and use them to create UAs (user agents) under an attacker's control 🙈. XSS is honestly devastating across the board, because it can steal credit card info and passwords and do all kinds of shady stuff. It's not evident that HOBA adds any unique threat that cleartext passwords don't already deal with 🫶.

Another thing to watch is local access to the keys 👀. If an attacker has access to the UA itself, they could snoop on the key through a JavaScript console or find the file(s) that implement localStorage on the host computer 🕵️. Again, it's not clear that we're worse off here, because that same attacker could get at browser password files too. One possible mitigation is to encrypt the keystore with a password/PIN that the user supplies 🔐. This may sound counterintuitive, but the whole point is to keep passwords off of servers, so a large-scale compromise (e.g., [ThreatReport]) doesn't get multiplied by shared passwords across sites 🧚.

It's worth noting that HOBA uses asymmetric keys and not passwords when evaluating threats ✨. As various password database leaks have shown, the real danger of a password breach isn't just the site that got breached, it's also every site where the user used the same password 😬. The collateral damage is severe because password reuse is super common. Storing a password in localStorage would have a similar multiplier effect for an attacker, maybe on a smaller scale than a server-side compromise, but one successful crack could still give them access to hundreds if not thousands of sites the user visits 💔. HOBA doesn't suffer from that attack multiplier, since each asymmetric key pair is unique per site/UA/user 🦋.

8.3. Multiple Accounts on One User Agent

A shared UA with multiple accounts is possible, as long as the account identifier is stored along with the asymmetric key pair that binds them to one another 🎀. You can keep multiple entries, one for each account, and the current user picks which one to use 💜. This is, of course, fraught with the possibility for abuse 😤. A server might enroll the device for a long period, and the user may not want to be on the hook for that credential for that long. To ease this problem, the user could ask for the credential to be erased from the browser 🧹. Similarly, during the enrollment phase, a user could ask that the key pair only be kept for a certain amount of time, or that it not be stored beyond the current browser session ⏳. However, all of these features really ought to be part of the operating system or platform and not part of a HOBA implementation, so we won't be discussing them any further 💅.

8.4. Injective Mapping for HOBA-TBS

The repeated length fields in the HOBA-TBS structure are there so that catenating different input values can never cause confusion that leads to an attack 🔒. That covers attacks against HOBA as specified here, and attacks against some other protocol that reused this to-be-signed structure too 🙅‍♀️. Those fields make sure that the mapping from input fields to the HOBA-TBS string is an injective mapping, which is basically the main character of this whole section 👑.

9. IANA Considerations

IANA has made registrations and created new registries, as described below 📋.

All new registries have been placed beneath a new "HTTP Origin-Bound Authentication (HOBA) Parameters" category 🌸.

9.1. HOBA Authentication Scheme

A new scheme has been registered in the HTTP Authentication Scheme Registry, and it looks like this 🦋:

Authentication Scheme Name: HOBA

Reference: Section 3 of RFC 7486

Notes (optional): The HOBA scheme can be used with either HTTP
servers or proxies.  When used in response to a 407 Proxy
Authentication Required indication, the appropriate proxy
authentication header fields are used instead, as with any other HTTP
authentication scheme.

9.2. .well-known URI

A new .well-known URI has been registered in the Well-Known URIs registry, and here's the entry 🍓:

URI Suffix: hoba

Change Controller: IETF

Reference: Section 6 of RFC 7486

Related Information: N/A

9.3. Algorithm Names

A new HOBA signature algorithms registry has been created, with Specification Required as the registration procedure 🔥. New HOBA signature algorithms SHOULD be in use with other IETF Standards Track protocols before being added to this registry 📚.

Number       Meaning                         Reference
-----------  ------------------------------  ------------
0            RSA-SHA256                      RFC 7486
1            RSA-SHA1                        RFC 7486

RSA is defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS] 🧠.

For this registry, the number column should contain a small positive integer. Following the ABNF in Figure 1, the maximum value for this is decimal 99 🔢.

9.4. Key Identifier Types

A new HOBA Key Identifier Types registry has been created, also with Specification Required as the registration procedure 🗝️.

Number       Meaning                         Reference
-----------  ------------------------------  ------------
0            a hashed public key             [RFC6698]
1            a URI                           [RFC3986]
2            an unformatted string, at the   RFC 7486
             user's/UA's whim

For the number 0, hashed public keys are as done in DNS-Based Authentication of Named Entities (DANE) [RFC6698] 💖.

For this registry, the number column should contain a small positive integer ✨.

9.5. Device Identifier Types

A new HOBA Device Identifier Types registry has been created, with Specification Required as the registration procedure 📝.

The designated expert for this registry is to carefully pay attention to the notes on this field in Section 8.1, in particular, the "MUST NOT" stated therein 🚫. Please read those notes, bestie, they matter 🫶.

Number       Meaning                         Reference
-----------  ------------------------------  -----------
0            an unformatted string, at the   RFC 7486
             user's/UA's whim

For this registry, the number column should contain a small positive integer 🌈.

9.6. Hobareg HTTP Header Field

A new identifier has been registered in the Permanent Message Header Field Names registry, and here's how it looks 🎀:

Header Field Name: Hobareg

Protocol: http (RFC 7230)

Status: experimental

Author/Change controller: IETF

Reference: Section 6.1.1 of RFC 7486

Related information: N/A

10. References

10.1. Normative References

[RFC20]    Cerf, V., "ASCII format for network interchange", STD 80,
           RFC 20, October 1969,
           <http://www.rfc-editor.org/info/rfc20>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
           Standards (PKCS) #1: RSA Cryptography Specifications
           Version 2.1", RFC 3447, February 2003,
           <http://www.rfc-editor.org/info/rfc3447>.

[RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
           Resource Identifier (URI): Generic Syntax", STD 66, RFC
           3986, January 2005,
           <http://www.rfc-editor.org/info/rfc3986>.

[RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
           Encodings", RFC 4648, October 2006,
           <http://www.rfc-editor.org/info/rfc4648>.

[RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
           Specifications: ABNF", STD 68, RFC 5234, January 2008,
           <http://www.rfc-editor.org/info/rfc5234>.

[RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
           (TLS) Protocol Version 1.2", RFC 5246, August 2008,
           <http://www.rfc-editor.org/info/rfc5246>.

[RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
           Uniform Resource Identifiers (URIs)", RFC 5785, April
           2010, <http://www.rfc-editor.org/info/rfc5785>.

[RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454, December
           2011, <http://www.rfc-editor.org/info/rfc6454>.

[RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
           of Named Entities (DANE) Transport Layer Security (TLS)
           Protocol: TLSA", RFC 6698, August 2012,
           <http://www.rfc-editor.org/info/rfc6698>.

[RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
           Framework: Bearer Token Usage", RFC 6750, October 2012,
           <http://www.rfc-editor.org/info/rfc6750>.

[RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
           Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
           June 2014, <http://www.rfc-editor.org/info/rfc7231>.

[RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
           Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014,
           <http://www.rfc-editor.org/info/rfc7235>.

[SHS]      NIST, "Secure Hash Standard (SHS)", FIPS PUB 180-4, March
           2012.

10.2. Informative References

[Bonneau]  Bonneau, J., "The Science of Guessing: Analyzing an
           Anonymized Corpus of 70 Million Passwords", IEEE Symposium
           on Security and Privacy 538-552, 2012.

[MI93]     Mitchell, C. and A. Thomas, "Standardising authentication
           protocols based on public key techniques", Journal of
           Computer Security Volume 2, 23-36, 1993.

[RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
           "Randomness Requirements for Security", BCP 106, RFC 4086,
           June 2005, <http://www.rfc-editor.org/info/rfc4086>.

[RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
           April 2011, <http://www.rfc-editor.org/info/rfc6265>.

[RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
           "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
           RFC 6376, September 2011,
           <http://www.rfc-editor.org/info/rfc6376>.

[ThreatReport]
           Sophos, "Security Threat Report 2013", January 2013,
           <http://www.sophos.com/en-us/medialibrary/pdfs/other/
           sophossecuritythreatreport2013.pdf>.

Appendix A. Problems with Passwords 🔐

Okay, so the most common way websites log you in is the classic password you can actually remember, aka "human-memorable passwords" 🙈. There's a lot of solid research on how people use them (see [Bonneau] if you want the deep dive), but the big takeaways are that people try SO hard to reuse the same password everywhere, and that sites usually pair these passwords with your email address or your username.

If an attacker gets into the database of memorable passwords, they can impersonate anyone in it 💀. Even after the breach is found, they can keep pretending to be users until every single password gets changed. And even if everyone's password is changed or made unusable, the attacker still has a list of likely username and password pairs that might work on other sites 😭.

Memorable passwords on unencrypted channels are risky too 🚨. If a site uses HTTP Basic authentication, or an HTML form that doesn't cryptographically protect the password in transit, a passive attacker can just read the password and instantly impersonate you. If the site uses a hash-based scheme like HTTP Digest authentication, a passive attacker still has a high chance of cracking the password with a dictionary of known passwords.

Passwords that aren't human-memorable can still get stolen from a database, but they're much less likely to be reused across lots of systems, so that's a small win 🌸. Also, database attacks of some form or other will work against any password-based scheme, no matter which cryptographic protocol it uses. So zero-knowledge and Password-Authenticated Key Exchange (PAKE) schemes are elegant cryptographic protocols, but they're still just as vulnerable to what is clearly the most common exploit when it comes to passwords 💅. HOBA, however, is not vulnerable to database theft ✨.

Appendix B. Example 🦋

Here's a full example of HOBA-http authentication to the origin https://example.com:443. Heads up bestie: carriage returns were added so everything fits on the page, and you need to remove them before you validate the example 🎀.

Public Key:

Origin: https://example.com:443

Key Identifier: vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-k_L6t3w

Challenge: pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=

Signature algorithm: RSA-SHA256 ("0")

Nonce: Pm3yUW-sW5Q

Signature:

VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0i
4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miUz
q04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrKP
tG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr9
6ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9kI
S13qQA43m4IMExkbApqrSg

Authorization Header:

Authorization: HOBA result="vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-
k_L6t3w.pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=.Pm3yUW-sW5Q
.VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0
i4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miU
zq04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrK
PtG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr
96ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9k
IS13qQA43m4IMExkbApqrSg"

Acknowledgements 💖

Huge thanks to these amazing people for their good comments while this spec was being put together 🫶: Richard Barnes, David Black, Alissa Cooper, Donald Eastlake, Amos Jeffries, Benjamin Kaduk, Watson Ladd, Barry Leiba, Matt Lepinski, Ilari Liusvaara, James Manger, Alexey Melnikov, Kathleen Moriarty, Yoav Nir, Mark Nottingham, Julian Reschke, Pete Resnick, Michael Richardson, Yaron Sheffer, and Michael Sweet. And yes, any errors and stupidities are 100% the editors' fault 😭🙈.

Authors' Addresses 🎀

Stephen Farrell
Trinity College Dublin
Dublin  2
Ireland

Phone: +353-1-896-2354
EMail: stephen.farrell@cs.tcd.ie


Paul Hoffman
VPN Consortium

EMail: paul.hoffman@vpnc.org


Michael Thomas
Phresheez

EMail: mike@phresheez.com

📦 where this page comes from

ietf: rfc7486 2015-03
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms