RFC 8120
Mutual Authentication Protocol for HTTP
Pages: 53
Experimental
Experimental
Part 3 of 3 – Pages 36 to 53
11. Decision Procedure for Servers
Each server SHOULD have a table of session states. This table need not be persistent over the long term; it MAY be cleared upon server restart, reboot, or for other reasons. Each entry in the table SHOULD contain at least the following information: o The session identifier, which is the value of the "sid" parameter. o The algorithm used. o The authentication realm. o The state of the protocol: one of "key exchanging", "authenticated", "rejected", or "inactive". o The username received from the client. o A boolean flag indicating whether or not the session is fake. o When the state is "key exchanging", the values of K_c1 and S_s1. o When the state is "authenticated", the following information: * The value of the session secret (z). * The largest nc received from the client (largest-nc). * For each possible nc value between (largest-nc - nc-window + 1) and max_nc, a boolean flag indicating whether or not a request with the corresponding nc has been received. The table MAY contain other information. Servers SHOULD respond to the client requests according to the following procedure (see Note 1 below regarding 401-INIT messages with a plus sign): o When the server receives a "normal request": * If the requested resource is not protected by the Mutual authentication, send a "normal response". * If the resource is protected by the Mutual authentication, send a 401-INIT response.
o When the server receives a req-KEX-C1 request:
* If the requested resource is not protected by the Mutual
authentication, send a "normal response".
* If the authentication realm specified in the req-KEX-C1 request
is not the expected realm, send a 401-INIT response.
* If the server cannot validate the parameter "kc1", send a
401-INIT (+) response.
* If the received username is either invalid, unknown, or
unacceptable, create a new session, mark it as a "fake"
session, compute a random value as K_s1, and send a fake
401-KEX-S1 response (see Note 2).
* Otherwise, create a new session, compute K_s1, and send a
401-KEX-S1 response. The created session is marked as not
fake, and its largest-nc value is initialized to zero.
The created session is in the "key exchanging" state.
o When the server receives a req-VFY-C request:
* If the requested resource is not protected by the Mutual
authentication, send a "normal response".
* If the authentication realm specified in the req-VFY-C request
is not the expected realm, send a 401-INIT response.
If none of the above holds true, the server will look up the
session corresponding to the received sid and the authentication
realm.
* If the session corresponding to the received sid could not be
found or it is in the "inactive" state, send a 401-STALE
response.
* If the session is in the "rejected" state, send either a
401-INIT (+) response or a 401-STALE message.
* If the nc value in the request is larger than the "nc-max"
parameter sent from the server or it is not larger than
(largest-nc - nc-window) (when in the "authenticated" state),
the server MAY (but is not REQUIRED to; see Note 3) send a
401-STALE message. The session is changed to the "inactive"
state if the 401-STALE message was sent.
* If the session is in the "authenticated" state and the request
has an nc value that was previously received from the client,
send a 401-STALE message. The session is changed to the
"inactive" state.
* If the session is a "fake" session or the received vkc is
incorrect, then send a 401-INIT (+) response. If the session
is in the "key exchanging" state, it MUST be changed to the
"rejected" state; otherwise, it MAY be either changed to the
"rejected" state or kept in the previous state.
* Otherwise, send a 200-VFY-S response. If the session was in
the "key exchanging" state, the session SHOULD be changed to
the "authenticated" state. The maximum nc and nc flags of the
state MUST be updated appropriately.
At any time, the server MAY change any state entries with both the
"rejected" and "authenticated" states to the "inactive" state and MAY
discard any "inactive" states from the table. Entries with the "key
exchanging" state SHOULD be kept unless there is an emergency
situation such as a server reboot or a table capacity overflow.
Note 1: In relation to, and following the specification of, the
optional authentication defined in [RFC8053], the 401-INIT messages
marked with plus signs cannot be replaced with a successful response
with an Optional-WWW-Authenticate header. Every other 401-INIT can
be a response with an Optional-WWW-Authenticate header.
Note 2: The server SHOULD NOT send a 401-INIT response in this case,
because it will leak the information to the client that the specified
username will not be accepted. Instead, postpone it until the
response to the next req-VFY-C request.
Note 3: If the request is not rejected in this clause, the server
will be required, in the next step, to determine whether the same nc
value was previously received from the client. If that is
impossible, the server MUST send a 401-STALE response in this step.
If the server does not remember the whole history of the nc values
received from the client, the server MUST send a 401-STALE message in
this clause.
12. Authentication Algorithms
Cryptographic authentication algorithms that are used with this protocol will be defined separately. The algorithm definition MUST at least provide definitions for the following functions: o The server-side authentication credential J, derived from the client-side authentication credential pi. o Key exchange values K_c1, K_s1 (exchanged on the wire) and S_c1, S_s1 (kept secret in each peer). o Shared session secret (z), to be computed by both server and client. o A hash function H to be used with the protocol, along with its output size hSize. o The value nIterPi, the number of iterations for the key derivation operation. Specifications for cryptographic algorithms used with this framework MUST specify whether those algorithms will (1) use the default functions defined below for values pi, VK_c, and VK_s or (2) define their own comparable functions. All algorithms used with this protocol SHOULD provide secure mutual authentication between clients and servers and generate a cryptographically strong shared secret value (z) that is equally strong or stronger than the hash function H. If any passwords (or passphrases or any equivalents, i.e., weak secrets) are involved, these SHOULD NOT be guessable from any data transmitted in the protocol, even if an attacker (either an eavesdropper or an active server) knows the possible thoroughly searchable candidate list of passwords. Furthermore, it is RECOMMENDED that the function J for deriving the server-side authentication credential J(pi) be one-way, if possible, so that pi cannot be easily computed from J(pi).12.1. Support Functions and Notations
In this section, we define several support functions and notations to be shared by several algorithm definitions. The integers in the specification are in decimal, or in hexadecimal when prefixed with "0x".
The function octet(i) generates an octet string containing a single octet of value i. The operator "|", when applied to octet strings, denotes the concatenation of two operands. The function VI encodes natural numbers into octet strings in the following manner: numbers are represented as big-endian radix-128 strings, where each digit is represented by an octet within the range 0x80-0xff, except for the last digit, which is represented by an octet within the range 0x00-0x7f. The first octet MUST NOT be 0x80. For example, VI(i) = octet(i) for i < 128, and VI(i) = octet(0x80 + (i >> 7)) | octet(i & 127) for 128 <= i < 16384. This encoding is the same as the encoding used for the subcomponents of object identifiers in ASN.1 encoding [ITU.X690.2015] and is available as a "w" conversion in the "pack" function of several scripting languages. The function VS encodes a variable-length octet string into a uniquely decoded, self-delimited octet string in the following manner: VS(s) = VI(length(s)) | s where length(s) is a number of octets (not characters) in s. Some examples: VI(0) = "\000" (in C string notation) VI(100) = "d" VI(10000) = "\316\020" VI(1000000) = "\275\204@" VS("") = "\000" VS("Tea") = "\003Tea" VS("Caf<e acute>" [in UTF-8]) = "\005Caf\303\251" VS([10000 "a"s]) = "\316\020aaaaa..." (10002 octets) (Note: Unlike the colon-separated format used in the Basic and Digest HTTP authentication schemes, the string generated by a concatenation of the VS-encoded strings will be unique, regardless of the characters included in the strings to be encoded.)
The function OCTETS converts an integer into the corresponding radix-256 big-endian octet string having its natural length. See Section 3.2.3 for the definition of "natural length". The function INT converts an octet string into a natural number, where the input string is treated as being in radix-256 big-endian notation. The identity INT(OCTETS(n)) = n always holds for any natural number n.12.2. Default Functions for Algorithms
The functions defined in this section are common default functions among authentication algorithms. The client-side password-based (credential) pi used by this authentication is a natural number derived in the following manner: pi = INT(PBKDF2(HMAC_H, password, VS(algorithm) | VS(auth-scope) | VS(realm) | VS(username), nIterPi, hSize / 8)) where o PBKDF2 is the password-based key derivation function defined in [RFC8018], o HMAC_H is the Hashed Message Authentication Code (HMAC) function, defined in [RFC2104], composed from the hash function H, and o hSize is the output size of hash H in bits. The values of algorithm, realm, and auth-scope are taken from the values contained in the 401-INIT message. If the password comes from user input, it SHOULD first be prepared according to the method presented in Section 9. Then, the password SHALL be encoded as a UTF-8 string. The values VK_c and VK_s are derived via the following equations: VK_c = INT(H(octet(4) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | VI(nc) | VS(vh))) VK_s = INT(H(octet(3) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | VI(nc) | VS(vh)))
13. Application Channel Binding
Applications and upper-layer communication protocols may need authentication binding to the HTTP-layer authenticated user. Such applications MAY use the following values as a standard shared secret. These values are parameterized with an optional octet string (t), which may be arbitrarily chosen by each application or protocol. If there is no appropriate value to be specified, use an empty string for t. For applications requiring binding to either an authenticated user or a shared-key session (to ensure that the requesting client is authenticated), the following value b_1 MAY be used: b_1 = H(H(octet(6) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | VI(0) | VS(vh)) | VS(t)) For applications requiring binding to a specific request (to ensure that the payload data is generated for the exact HTTP request), the following value b_2 MAY be used: b_2 = H(H(octet(7) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | VI(nc) | VS(vh)) | VS(t)) Note: Channel bindings to lower-layer transports (TCP and TLS) are defined in Section 7.14. Application for Proxy Authentication
The authentication scheme defined in the previous sections can be applied (with modifications) to proxy authentication. In such cases, the following alterations MUST be applied: o The 407 (Proxy Authentication Required) status code is to be sent and recognized in places where the 401 status code is used, o The Proxy-Authenticate header is to be used in places where the WWW-Authenticate header is used, o The Proxy-Authorization header is to be used in places where the Authorization header is used, o The Proxy-Authentication-Info header is to be used in places where the Authentication-Info header is used,
o The "auth-scope" parameter is fixed to the hostname of the proxy,
which means that it covers all requests processed by the specific
proxy,
o The limitation for the paths contained in the "path" parameter of
401-KEX-S1 messages is disregarded,
o The omission of the "path" parameter of 401-KEX-S1 messages means
that the authentication realm will potentially cover all requests
processed by the proxy,
o The scheme, hostname, and port of the proxy are used for host
validation tokens, and
o Authentication extensions defined in [RFC8053] are not applicable.
15. Methods to Extend This Protocol
If a private extension to this protocol is implemented, it MUST use
the extension-tokens defined in Section 3 to avoid conflicts with
this protocol and other extensions. (Standardized extensions, as
well as extensions that are in the process of being standardized, MAY
use either bare-tokens or extension-tokens.)
Specifications defining authentication algorithms MAY use other
representations for the parameters "kc1", "ks1", "vkc", and "vks";
replace those parameter names; and/or add parameters to the messages
containing those parameters in supplemental specifications, provided
that syntactic and semantic requirements in Section 3 of this
document, [RFC7230], and [RFC7235] are satisfied. Any parameters
starting with "kc", "ks", "vkc", or "vks" and followed by decimal
natural numbers (e.g., kc2, ks0, vkc1, vks3) are reserved for this
purpose. If those specifications use names other than those
mentioned above, it is RECOMMENDED that extension-tokens be used to
avoid any parameter-name conflicts with future extensions to this
protocol.
Extension-tokens MAY be freely used for any non-standard, private,
and/or experimental uses for those parameters provided that the
domain part in the token is used in the manner defined in Section 3.
16. IANA Considerations
16.1. Addition to HTTP Authentication Schemes Registry
IANA has added the following entry to the "HTTP Authentication Schemes" registry: o Authentication Scheme Name: Mutual o Reference: RFC 812016.2. Registry for Authentication Algorithms
This document establishes the "HTTP Mutual Authentication Algorithms" registry. The registry manages case-insensitive ASCII strings. The strings MUST follow the extensive-token syntax defined in Section 3. When bare-tokens are used for the authentication-algorithm parameter, they MUST be allocated by IANA. To acquire registered tokens, the usage of such tokens MUST be reviewed by a Designated Expert, as outlined in [RFC5226]. Registrations for an authentication algorithm are required to include descriptions of the authentication algorithms. Reviewers assigned by the IESG are advised to examine minimum security requirements and consistency of the key exchange algorithm descriptions. It is advised that new registrations provide the following information: o Token: A token used in HTTP headers for identifying the algorithm. o Description: A brief description of the algorithm. o Specification: A reference for a specification defining the algorithm. [RFC8121] defines the initial contents of this registry.
16.3. Registry for Validation Methods
This document establishes the "HTTP Mutual Authentication Host Validation Methods" registry. The registry manages case-insensitive ASCII strings. The strings MUST follow the extensive-token syntax defined in Section 3. When bare-tokens are used for the validation parameter, they MUST be allocated by IANA. To acquire registered tokens, the usage of such tokens MUST be reviewed by a Designated Expert, as outlined in [RFC5226]. Registrations for a validation method are required to include a description of the validation method. Reviewers assigned by the IESG are advised to examine its use-case requirements and any security consequences related to its introduction. It is advised that new registrations provide the following information: o Token: A token used in HTTP headers for identifying the method. o Description: A brief description of the method. o Specification: A reference for a specification defining the method. The initial contents of this registry are as follows: +----------------------+------------------------+----------------+ | Token | Description | Reference | +----------------------+------------------------+----------------+ | host | Hostname verification | RFC 8120, | | | only | Section 7 | | | | | | tls-server-end-point | TLS certificate-based | RFC 8120, | | | | Section 7 | | | | | | tls-unique | TLS unique key-based | RFC 8120, | | | | Section 7 | +----------------------+------------------------+----------------+
17. Security Considerations
17.1. Security Properties
o The protocol is secure against passive eavesdropping and replay attacks. However, the protocol relies on transport security (including DNS integrity) for data secrecy and integrity. HTTP/TLS SHOULD be used where transport security is not assured and/or data confidentiality is important. o When used with HTTP/TLS, if TLS server certificates are reliably verified, the protocol provides true protection against active man-in-the-middle attacks. o Even if the server certificate is not used or is unreliable, the protocol provides protection against active man-in-the-middle attacks for each HTTP request/response pair. However, in such cases, JavaScript or similar scripts that are not authenticated by this authentication mechanism can affect mutually authenticated contents to circumvent the protection. This is why this protocol stipulates that valid TLS server certificates MUST be shown from the server to the client (Section 7).17.2. Secrecy of Credentials
The client-side password credential MUST always be kept secret and SHOULD NOT be used for any other (possibly insecure) authentication purposes. Loss of control of the credential will directly affect the control of the corresponding server-side account. The use of a client-side credential with THIS authentication scheme is always safe, even if the connected server peer is not trustworthy (e.g., a phishing scenario). However, if it is used with other authentication schemes (such as Web forms) and the recipient is rogue, the result will be obvious. It is also important that the server-side password credential (J) be kept secret. If it is stolen and the client's choice of password is not strong, anyone who is aware of the server-side password credential can employ an offline dictionary attack to search for the client's password. However, if the client has chosen a strong password so that an attacker cannot guess the client's password from dictionary candidates, the client is still well protected from any attacks.
The shared session secret (z) MUST be kept secret inside the server/client software; if it is lost and the session is still active, session hijacking will result. After the session expires, the key is of no value to attackers.17.3. Denial-of-Service Attacks on Servers
The protocol requires a server-side table of active sessions, which may become a critical point for server resource consumption. For proper operation, the protocol requires that at least one key verification request be processed for each session identifier. After that, servers MAY discard sessions internally at any time without causing any operational problems for clients. Clients will then silently re-establish a new session. However, if a malicious client sends too many requests for key exchanges (req-KEX-C1 messages) only, resource starvation might occur. In such critical situations, servers MAY discard any kind of existing sessions, regardless of their statuses. One way to mitigate such attacks is that servers MAY set number and time limits for unverified, pending key exchange requests (in the "key exchanging" state). This is a common weakness of authentication protocols with almost any kind of negotiations or states, including the Digest authentication scheme and most cookie-based authentication implementations. However, regarding resource consumption, the situation for the Mutual authentication scheme is slightly better than that for Digest, because HTTP requests without any kind of authentication requests will not generate any kind of sessions. Session identifiers are only generated after a client starts a key negotiation, so that simple clients such as Web crawlers will not accidentally consume server-side resources for session management.17.3.1. Online Active Password Attacks
Although the protocol provides very strong protection against offline dictionary attacks from eavesdropped traffic, the protocol, by its nature, cannot prevent active password attacks in which an attacker sends so many authentication trial requests for every possible password. Possible countermeasures for preventing such attacks may be the rate-limiting of password authentication trials, statistics-based intrusion-detection measures, or similar protection schemes. If the server operators assume that the passwords of users are not strong enough, it may be desirable to introduce such ad hoc countermeasures.
17.4. Communicating the Status of Mutual Authentication with Users
This protocol is designed with two goals in mind. The first goal is simply to provide a secure alternative to existing Basic and Digest authentication schemes. The second goal is to provide users with a way to detect forged rogue servers imitating (e.g., via a phishing attack) a user's registered account on a server. For this protocol to effectively work as a countermeasure against such attacks, it is very important that end users of clients be notified of the result of mutual authentication performed by this protocol, especially the three states "AUTH-SUCCEED", "AUTH-REQUIRED", and "UNAUTHENTICATED" as defined in Section 10. The design of secure user interfaces for HTTP interactive clients is out of scope for this document, but if possible, having some kind of UI indication for the three states above will be desirable from the standpoint of providing user security. Of course, in such cases, the user interfaces for requesting passwords for this authentication shall be protected against imitation (for example, by other insecure password input fields, such as forms). If the passwords are known to malicious attackers outside of the protocol, the protocol cannot work as an effective security measure.17.5. Implementation Considerations
o To securely implement the protocol, the Authentication-Info headers in the 200-VFY-S messages MUST always be validated by the client. If the validation fails, the client MUST NOT process any content sent with the message, including other headers and the body part. Non-compliance with this requirement will allow phishing attacks. o For HTTP/TLS communications, when a Web form is submitted from mutually authenticated pages via the "tls-server-end-point" validation method to a URI that is protected by the same realm (so indicated by the "path" parameter), if the server certificate has been changed since the pages were received, it is RECOMMENDED that the peer be revalidated using a req-KEX-C1 message with an "Expect: 100-continue" header. The same applies when the page is received via the "tls-unique" validation method and when the TLS session has expired. o For better protection against possible password database stealing, server-side storage of user passwords should contain the values encrypted by the one-way function J(pi) instead of the real passwords or those hashed by pi.
o If TLS 1.2 [RFC5246] is used for underlying HTTP/TLS communications, follow the best practices specified in [RFC7525].17.6. Usage Considerations
o The usernames inputted by a user may be sent automatically to any servers sharing the same auth-scope. This means that when a host-type auth-scope is used for authentication on an HTTPS site and an HTTP server on the same host requests the Mutual authentication scheme within the same realm, the client will send the username in clear text. If usernames have to be kept secret (protected from eavesdroppers), the server must use the full-scheme-type "auth-scope" parameter and HTTPS. Passwords, on the other hand, are not exposed to eavesdroppers, even in HTTP requests. o If the server provides several ways to store server-side password secrets in the password database, it is desirable, for purposes of better security, to store the values encrypted by using the one-way function J(pi) instead of the real passwords or those hashed by pi.18. References
18.1. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <http://www.rfc-editor.org/info/rfc2104>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, 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, DOI 10.17487/RFC5234, 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, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>. [RFC5987] Reschke, J., "Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters", RFC 5987, DOI 10.17487/RFC5987, August 2010, <http://www.rfc-editor.org/info/rfc5987>. [RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>. [RFC7235] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>. [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 7613, DOI 10.17487/RFC7613, August 2015, <http://www.rfc-editor.org/info/rfc7613>. [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields", RFC 7615, DOI 10.17487/RFC7615, September 2015, <http://www.rfc-editor.org/info/rfc7615>. [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: Password-Based Cryptography Specification Version 2.1", RFC 8018, DOI 10.17487/RFC8018, January 2017, <http://www.rfc-editor.org/info/rfc8018>. [RFC8053] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, T., and Y. Ioku, "HTTP Authentication Extensions for Interactive Clients", RFC 8053, DOI 10.17487/RFC8053, January 2017, <http://www.rfc-editor.org/info/rfc8053>. [Unicode] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
18.2. Informative References
[ITU.X690.2015] International Telecommunication Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015, <https://www.itu.int/rec/T-REC-X.690/>. [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, <http://www.rfc-editor.org/info/rfc1939>. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>. [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, <http://www.rfc-editor.org/info/rfc5929>. [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>. [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <http://www.rfc-editor.org/info/rfc6454>. [RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7486] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin-Bound Authentication (HOBA)", RFC 7486, DOI 10.17487/RFC7486, March 2015, <http://www.rfc-editor.org/info/rfc7486>. [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>. [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <http://www.rfc-editor.org/info/rfc7616>. [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015, <http://www.rfc-editor.org/info/rfc7627>. [RFC8121] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, T., and Y. Ioku, "Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3)", RFC 8121, DOI 10.17487/RFC8121, April 2017, <http://www.rfc-editor.org/info/rfc8121>.
Authors' Addresses
Yutaka Oiwa National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan Email: y.oiwa@aist.go.jp Hajime Watanabe National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan Email: h-watanabe@aist.go.jp Hiromitsu Takagi National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan Email: takagi.hiromitsu@aist.go.jp Kaoru Maeda Individual Contributor Email: kaorumaeda.ml@gmail.com Tatsuya Hayashi Lepidum Co. Ltd. Village Sasazuka 3, Suite #602 1-30-3 Sasazuka Shibuya-ku, Tokyo Japan Email: hayashi@lepidum.co.jp Yuichi Ioku Individual Contributor Email: mutual-work@ioku.org