RFC 8120
Mutual Authentication Protocol for HTTP
Pages: 53
Experimental
Experimental
Part 1 of 3 – Pages 1 to 15
Internet Engineering Task Force (IETF) Y. Oiwa Request for Comments: 8120 H. Watanabe Category: Experimental H. Takagi ISSN: 2070-1721 ITRI, AIST K. Maeda Individual Contributor T. Hayashi Lepidum Y. Ioku Individual Contributor April 2017 Mutual Authentication Protocol for HTTPAbstract
This document specifies an authentication scheme for the Hypertext Transfer Protocol (HTTP) that is referred to as either the Mutual authentication scheme or the Mutual authentication protocol. This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password. Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8120.
Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents
1. Introduction ....................................................3 1.1. Terminology ................................................5 1.2. Document Structure and Related Documents ...................6 2. Protocol Overview ...............................................6 2.1. Messages ...................................................7 2.2. Typical Flows of the Protocol ..............................8 2.3. Alternative Flows .........................................10 3. Message Syntax .................................................12 3.1. Non-ASCII Extended Header Parameters ......................12 3.2. Values ....................................................13 3.2.1. Tokens .............................................13 3.2.2. Strings ............................................14 3.2.3. Numbers ............................................14 4. Messages .......................................................15 4.1. 401-INIT and 401-STALE ....................................16 4.2. req-KEX-C1 ................................................19 4.3. 401-KEX-S1 ................................................19 4.4. req-VFY-C .................................................20 4.5. 200-VFY-S .................................................21 5. Authentication Realms ..........................................21 5.1. Resolving Ambiguities .....................................23 6. Session Management .............................................24 7. Host Validation Methods ........................................26 7.1. Applicability Notes .......................................27 7.2. Notes on "tls-unique" .....................................28 8. Authentication Extensions ......................................28 9. String Preparation .............................................29 10. Decision Procedure for Clients ................................29 10.1. General Principles and Requirements ......................29 10.2. State Machine for the Client (Informative) ...............31
11. Decision Procedure for Servers ................................36 12. Authentication Algorithms .....................................39 12.1. Support Functions and Notations ..........................39 12.2. Default Functions for Algorithms .........................41 13. Application Channel Binding ...................................42 14. Application for Proxy Authentication ..........................42 15. Methods to Extend This Protocol ...............................43 16. IANA Considerations ...........................................44 16.1. Addition to HTTP Authentication Schemes Registry .........44 16.2. Registry for Authentication Algorithms ...................44 16.3. Registry for Validation Methods ..........................45 17. Security Considerations .......................................46 17.1. Security Properties ......................................46 17.2. Secrecy of Credentials ...................................46 17.3. Denial-of-Service Attacks on Servers .....................47 17.3.1. Online Active Password Attacks ....................47 17.4. Communicating the Status of Mutual Authentication with Users ...............................................48 17.5. Implementation Considerations ............................48 17.6. Usage Considerations .....................................49 18. References ....................................................49 18.1. Normative References .....................................49 18.2. Informative References ...................................51 Authors' Addresses ................................................531. Introduction
This document specifies an authentication scheme for the Hypertext Transfer Protocol (HTTP) that is referred to as either the Mutual authentication scheme or the Mutual authentication protocol. This scheme provides true mutual authentication between an HTTP client and an HTTP server using just a simple password as a credential. Password-stealing attacks are one of the most critical threats for Web systems. Plain-text password authentication techniques (Basic authentication and Web-form-based authentication) have been widely used for a long time. When these techniques are used with plain HTTP protocols, it is trivially easy for attackers to sniff the password credentials on the wire. The Digest authentication scheme [RFC7616] uses SHA-256 and SHA-512/256 (formerly SHA-1 and MD5) hash algorithms to hide the raw user password from network sniffers. However, if the number of possible candidate users' passwords is not enough, newer and more powerful computers can compute possible hash values for billions of password candidates and compare these with the sniffed values to find out the correct password. This kind of attack is called an offline password dictionary attack; the search capacity of these newer
computers reduces the effectiveness of users' memorable passwords, thereby threatening the effectiveness of such hash-based password protections. Transport Layer Security (TLS) [RFC5246] provides strong cryptographic protection against the network-based sniffing of passwords and other communication contents. If TLS is correctly used by both server operators and client users, passwords and other credentials will not be available to any outside attackers. However, there is a pitfall related to TLS deployment on Web systems: if the users are fraudulently routed to a "wrong Website" via some kind of social engineering attack (e.g., phishing) and tricked into performing authentication on that site, the credentials will be sent to the attacker's server and trivially leaked. Attacks such as phishing have become a serious threat. In current Web system deployments, TLS certificates will be issued to almost any users of the Internet (including malicious attackers). Although those certificates include several levels of the "validation results" (such as corporate names) of the issued entities, the task of "checking" those validation results is left to the users of Web browsers, still leaving open the possibility of such social engineering attacks. Another way to avoid such threats is to avoid password-based authentication and use some kinds of pre-deployed strong secret keys (on either the client side or the server side) for authentications. Several federated authentication frameworks, as well as HTTP Origin-Bound Authentication (HOBA) [RFC7486], are proposed and deployed on real Web systems to satisfy those needs. However, a type of authentication based on "human-memorable secrets" (i.e., passwords) is still required in several scenarios, such as initialization, key deployment to new clients, or recovery of secret accounts with lost cryptographic keys. The Mutual authentication protocol, as proposed in this document, is a strong cryptographic solution for password authentications. It mainly provides the following two key features: o No password information at all is exchanged in the communications. When the server and the user fail to authenticate with each other, the protocol will not reveal even the tiniest bit of information about the user's password. This prevents any kind of offline password dictionary attacks, even with the existence of phishing attacks. o To successfully authenticate, the server, as well as client users, must own the valid registered credentials (authentication secret). This means that a phishing attacker cannot trick users into thinking that it is an "authentic" server. (It should be
pointed out that this is not true for Basic and Digest
authentication; for example, servers using Basic authentication
can answer "YES" to any clients without actually checking
authentication at all.) Client users can ascertain whether or not
the communicating peer is truly "the server" that registered their
account beforehand. In other words, it provides "true" mutual
authentication between servers and clients.
Given the information above, the proposed protocol can serve as a
strong alternative to the Basic, Digest, and Web-form-based
authentication schemes and also as a strong companion to the
non-password-based authentication frameworks.
The proposed protocol will serve in the same way as does existing
Basic or Digest authentication: it meets the requirements for new
authentication schemes for HTTP, as described in Section 5.1.2 of
[RFC7235]. Additionally, to communicate authentication results more
reliably between the server and the client user, it suggests that Web
browsers have some "secure" way of displaying the authentication
results. Having such a user interface in future browsers will
greatly reduce the risk of impersonation by various kinds of social
engineering attacks, in a manner similar to that of the
"green padlock" for Extended Validation TLS certificates.
Technically, the authentication scheme proposed in this document is a
general framework for using password-based authenticated key exchange
(PAKE) and similar stronger cryptographic primitives with HTTP. The
two key features shown above correspond to the nature of PAKE.
1.1. 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
[RFC2119].
This document distinguishes the terms "client" and "user" in the
following way: a "client" is an entity that understands and
implements HTTP and the specified authentication protocol -- usually
computer software; a "user" is typically a human being who wants to
access data resources using a "client".
The term "natural numbers" refers to the non-negative integers
(including zero) throughout this document.
This document treats both the input (domain) and the output (codomain) of hash functions as octet strings. When a natural number output for a hash function is required, it will be written as INT(H(s)).1.2. Document Structure and Related Documents
The entire document is organized as follows: o Section 2 presents an overview of the protocol design. o Sections 3 through 11 define a general framework of the Mutual authentication protocol. This framework is independent of specific cryptographic primitives. o Section 12 describes properties needed for cryptographic algorithms used with this protocol framework and defines a few functions that will be shared among such cryptographic algorithms. o Sections 13 through 15 contain general normative and informative information about the protocol. o Sections 16 and 17 describe IANA considerations and security considerations, respectively. In addition, we will refer to the following two companion documents, as they are related to this specification: o [RFC8121] defines cryptographic primitives that can be used with this protocol framework. o [RFC8053] defines small but useful extensions to the current HTTP authentication framework so that it can support application-level semantics of existing Web systems.2. Protocol Overview
The protocol, as a whole, is designed as a natural extension to HTTP [RFC7230] and uses the framework defined in [RFC7235]. Internally, the server and the client will first perform a cryptographic key exchange, using the secret password as a "tweak" to the exchange. The key exchange will only succeed when the secrets used by both peers are correctly related (i.e., generated from the same password). Then, both peers will verify the authentication results by confirming the sharing of the exchanged key. This section provides a brief outline of the protocol and the exchanged messages.
2.1. Messages
The authentication protocol uses six kinds of messages to perform mutual authentication. These messages have specific names within this specification. o Authentication request messages: used by the servers to request that clients start mutual authentication. * 401-INIT message: a general message to start the authentication protocol. It is also used as a message indicating an authentication failure. * 401-STALE message: a message indicating that the client has to start a new key exchange. o Authenticated key exchange messages: used by both peers to perform authentication and the sharing of a cryptographic secret. * req-KEX-C1 message: a message sent from the client. * 401-KEX-S1 message: an intermediate response to a req-KEX-C1 message from the server. o Authentication verification messages: used by both peers to verify the authentication results. * req-VFY-C message: a message used by the client to request that the server authenticate and authorize the client. * 200-VFY-S message: a response used by the server to indicate that client authentication succeeded. It also contains information necessary for the client to check the authenticity of the server. In addition to the above six kinds of messages, a request or response without any HTTP headers related to this specification will be hereafter called a "normal request" or "normal response", respectively.
2.2. Typical Flows of the Protocol
In typical cases, client access to a resource protected by the Mutual authentication scheme will use the following protocol sequence: Client Server | | | ---- (1) normal request ---------> | GET / HTTP/1.1 | | | | <---------------- (2) 401-INIT --- | | 401 Unauthorized | | WWW-Authenticate: Mutual realm="a realm" | | [user, | | pass]-->| | | ---- (3) req-KEX-C1 -------------> | GET / HTTP/1.1 | Authorization: Mutual user="john", |--> [user DB] kc1="...", ... |<-- [user info] | | | <-------------- (4) 401-KEX-S1 --- | | 401 Unauthorized | | WWW-Authenticate: Mutual sid=..., ks1="...", ... | | [compute] (5) compute session secret [compute] | | | | | ---- (6) req-VFY-C --------------> | GET / HTTP/1.1 |--> [verify (6)] Authorization: Mutual sid=..., |<-- OK vkc="...", ... | | | | <--------------- (7) 200-VFY-S --- | [verify | 200 OK | (7)]<--| Authentication-Info: Mutual vks="..." | | v v Figure 1: Typical Communication Flow for First Access to Resource o As is typical in general HTTP protocol designs, a client will at first request a resource without any authentication attempt (1). If the requested resource is protected by the Mutual authentication protocol, the server will respond with a message requesting authentication (401-INIT) (2).
o The client processes the body of the message and waits for the
user to input the username and password. If the username and
password are available, the client will send a message with the
authenticated key exchange (req-KEX-C1) to start the
authentication (3).
o If the server has received a req-KEX-C1 message, the server
looks up the user's authentication information within its user
database. Then, the server creates a new session identifier (sid)
that will be used to identify sets of the messages that follow it
and responds with a message containing a server-side authenticated
key exchange value (401-KEX-S1) (4).
o At this point (5), both peers calculate a shared "session secret"
using the exchanged values in the key exchange messages. Only
when both the server and the client have used secret credentials
generated from the same password will the session secret values
match. This session secret will be used for access authentication
of every individual request/response pair after this point.
o The client will send a request with a client-side authentication
verification value (req-VFY-C) (6), calculated from the
client-generated session secret. The server will check the
validity of the verification value using its own version of the
session secret.
o If the authentication verification value from the client was
correct, then the client definitely owns the credential based on
the expected password (i.e., the client authentication succeeded).
The server will respond with a successful message (200-VFY-S) (7).
Unlike the usual one-way authentication (e.g., HTTP Basic
authentication or POP APOP authentication [RFC1939]), this message
also contains a server-side authentication verification value.
When the client's verification value is incorrect (e.g., because
the user-supplied password was incorrect), the server will respond
with a 401-INIT message (the same message as the message used
in (2)) instead.
o The client MUST first check the validity of the server-side
authentication verification value contained in the message (7).
If the value was equal to the expected value, server
authentication succeeded.
If it is not the expected value or the message does not contain
the authentication verification value, then the mutual
authentication has been broken for some unexpected reason. The
client MUST NOT process any body or header values contained in the
HTTP response in this case. (Note: This case should not happen
between a correctly implemented server and client without any
active attacks; such a scenario could be caused by either a
man-in-the-middle attack or incorrect implementation.)
2.3. Alternative Flows
As shown above, the typical flow for a first authentication request
requires three request-response pairs. To reduce protocol overhead,
the protocol enables several shortcut flows that require fewer
messages.
o Case A: If the client knows that the resource is likely to require
authentication, the client MAY omit the first unauthenticated
request (1) and immediately send a key exchange (req-KEX-C1)
message. This will reduce the number of round trips by one.
o Case B: If both the client and the server previously shared a
session secret associated with a valid sid, the client MAY
directly send a req-VFY-C message using the existing sid and
corresponding session secret. This will further reduce the number
of round trips by one.
The server MAY have thrown out the corresponding session from the
session table. If so, the server will respond with a 401-STALE
message, indicating that a new key exchange is required. The
client SHOULD try again to construct a req-KEX-C1 message in
this case.
Figure 2 depicts the shortcut flows described above. When using appropriate settings and implementations, most of the requests to resources are expected to meet both criteria; thus, only one round trip of request/response will be required. Case A: Omit first request (2 round trips) Client Server | | | --- req-KEX-C1 ----> | | | | <---- 401-KEX-S1 --- | | | | ---- req-VFY-C ----> | | | | <----- 200-VFY-S --- | | | Case B: Reuse session secret (re-authentication) (B-1) key available (B-2) key expired (1 round trip) (3 round trips) Client Server Client Server | | | | | ---- req-VFY-C ----> | | --- req-VFY-C -------> | | | | | | <----- 200-VFY-S --- | | <------- 401-STALE --- | | | | | | --- req-KEX-C1 ------> | | | | <------ 401-KEX-S1 --- | | | | --- req-VFY-C -------> | | | | <------- 200-VFY-S --- | | | Figure 2: Several Alternative Protocol Flows For more details, see Sections 10 and 11.
3. Message Syntax
Throughout this specification, the syntax is denoted in the extended augmented BNF syntax as defined in [RFC7230] and [RFC5234]. The following elements are used in this document per [RFC5234], [RFC7230], and [RFC7235]: DIGIT, ALPHA, SP, auth-scheme, quoted-string, auth-param, header-field, token, challenge, and credentials. The Mutual authentication protocol uses three headers: WWW-Authenticate (usually in responses with a 401 status code), Authorization (in requests), and Authentication-Info (in responses other than a 401 status code). These headers follow the frameworks described in [RFC7235] and [RFC7615]. See Section 4 for more details regarding these headers. The framework in [RFC7235] defines the syntax for the headers WWW-Authenticate and Authorization as the syntax elements "challenge" and "credentials", respectively. The auth-scheme element contained in those headers MUST be set to "Mutual" when using the protocol specified in this document. The syntax for "challenge" and "credentials" to be used with the "Mutual" auth-scheme SHALL be name-value pairs (#auth-param), not the "token68" parameter defined in [RFC7235]. The Authentication-Info header used in this protocol SHALL follow the syntax defined in [RFC7615]. In HTTP, the WWW-Authenticate header may contain two or more challenges. Client implementations SHOULD be aware of, and be capable of correctly handling, those cases.3.1. Non-ASCII Extended Header Parameters
All of the parameters contained in the above three headers, except for the "realm" field, MAY be extended to ISO 10646-1 values using the framework described in [RFC5987]. All servers and clients MUST be capable of receiving and sending values encoded per the syntax specified in [RFC5987]. If a value to be sent contains only ASCII characters, the field MUST be sent using plain syntax as defined in RFC 7235. The syntax as extended by RFC 5987 MUST NOT be used in this case. If a value (except for the "realm" header) contains one or more non-ASCII characters, the parameter SHOULD be sent using the syntax defined in Section 3.2 of [RFC5987] as "ext-parameter". Such a parameter MUST have a charset value of "UTF-8", and the language
value MUST always be omitted (have an empty value). The same parameter MUST NOT be sent more than once, regardless of the syntax used. For example, a parameter "user" with the value "Renee of France" SHOULD be sent as < user="Renee of France" >. If the value is "Ren<e acute>e of France", it SHOULD be sent as < user*=UTF-8''Ren%C3%89e%20of%20France > instead. [RFC7235] requires that the "realm" parameter be in its plain form (not as an extended "realm*" parameter), so the syntax specified in RFC 5987 MUST NOT be used for this parameter.3.2. Values
The parameter values contained in challenges or credentials MUST be parsed in strict conformance with HTTP semantics (especially the unquoting of string parameter values). In this protocol, those values are further categorized into the following value types: tokens (bare-token and extensive-token), string, integer, hex-fixed-number, and base64-fixed-number. For clarity, it is RECOMMENDED that implementations use the canonical representations specified in the following subsections for sending values. However, recipients MUST accept both quoted and unquoted representations interchangeably, as specified in HTTP.3.2.1. Tokens
For sustaining both security and extensibility at the same time, this protocol defines a stricter sub-syntax for the "token" to be used. Extensive-token values SHOULD use the following syntax (after the parsing of HTTP values): bare-token = bare-token-lead-char *bare-token-char bare-token-lead-char = %x30-39 / %x41-5A / %x61-7A bare-token-char = %x30-39 / %x41-5A / %x61-7A / "-" / "_" extension-token = "-" bare-token 1*("." bare-token) extensive-token = bare-token / extension-token Figure 3: BNF Syntax for Token Values The tokens (bare-token and extension-token) are case insensitive. Senders SHOULD send these in lower case, and receivers MUST accept both upper and lower cases. When tokens are used as (partial) inputs to any hash functions or other mathematical functions, they MUST always be used in lower case.
Extensive-tokens are used in this protocol where the set of acceptable tokens may include non-standard extensions. Any extension of this protocol MAY use either the bare-tokens allocated by IANA (see the procedure described in Section 16) or extension-tokens with the format "-<bare-token>.<domain-name>", where <domain-name> is a valid (sub)domain name on the Internet owned by the party who defines the extension. Bare-tokens and extensive-tokens are also used for parameter names, in the unquoted form. Requirements for using the extension-token for the parameter names are the same as those described in the previous paragraph. The canonical format for bare-tokens and extensive-tokens is the unquoted representation.3.2.2. Strings
All character strings MUST be encoded to octet strings using UTF-8 encoding [RFC3629] for the Unicode character set [Unicode]. Such strings MUST NOT contain any leading Byte Order Marks (BOMs) (also known as ZERO WIDTH NO-BREAK SPACE, U+FEFF, or EF BB BF). It is RECOMMENDED that both peers reject any invalid UTF-8 sequences that might cause decoding ambiguities (e.g., containing <"> in the second or subsequent bytes of the UTF-8 encoded characters). If strings represent a domain name or URI that contains non-ASCII characters, the host parts SHOULD be encoded as they (the parts) are used in the HTTP protocol layer (e.g., in a Host: header); per current standards, the A-label as defined in [RFC5890] will be used. Lowercase ASCII characters SHOULD be used. The canonical format for strings is quoted-string (as it may contain equals signs ("="), plus signs ("+"), and slashes ("/")), unless the parameter containing the string value will use extended syntax as defined in [RFC5987]. (Per [RFC5987], an extended parameter will have an unquoted encoded value.)3.2.3. Numbers
The following syntax definitions provide a syntax for numeric values: integer = "0" / (%x31-39 *DIGIT) ; no leading zeros hex-fixed-number = 1*(2(DIGIT / %x41-46 / %x61-66)) base64-fixed-number = 1*( ALPHA / DIGIT / "+" / "/" ) 0*2"=" Figure 4: BNF Syntax for Numbers
The syntax definition of the integers only allows representations that do not contain leading zeros. A number represented as a hex-fixed-number MUST include an even number of hexadecimal digits (i.e., multiples of eight bits). Those values are case insensitive and SHOULD be sent in lower case. When these values are generated from any cryptographic values, they MUST have their "natural length"; if they are generated from a hash function, their lengths correspond to the hash size; if they represent elements of a mathematical set (or group), their lengths SHALL be the shortest lengths that represent all the elements in the set. For example, the results of the SHA-256 hash function will be represented by 64 digits, and any elements in a 2048-bit prime field (modulo a 2048-bit integer) will be represented by 512 digits, regardless of how many zeros appear in front of such representations. Session identifiers and other non-cryptographically generated values are represented in any (even) length determined by the side that generates it first, and the same length MUST be used in all communications by both peers. The numbers represented as base64-fixed-number SHALL be generated as follows: first, the number is converted to a big-endian radix-256 binary representation as an octet string. The length of the representation is determined in the same way as the technique mentioned above. Then, the string is encoded using base64 encoding (described in Section 4 of [RFC4648]) without any spaces and newlines. Implementations decoding base64-fixed-number SHOULD reject any input data with invalid characters, excess or insufficient padding, or non-canonical pad bits (see Sections 3.1 through 3.5 of [RFC4648]). The canonical format for integer and hex-fixed-number is unquoted tokens, and the canonical format for base64-fixed-number is quoted-string.
(page 15 continued on part 2)