tech-invite   World Map
3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search     Home

RFC 8120

 
 
 

Mutual Authentication Protocol for HTTP

Part 3 of 3, p. 36 to 53
Prev Section

 


prevText      Top      ToC       Page 36 
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.

Top      Up      ToC       Page 37 
   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.

Top      Up      ToC       Page 38 
      *  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.

Top      Up      ToC       Page 39 
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".

Top      Up      ToC       Page 40 
   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.)

Top      Up      ToC       Page 41 
   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)))

Top      Up      ToC       Page 42 
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,

Top      Up      ToC       Page 43 
   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.

Top      Up      ToC       Page 44 
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 8120

16.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.

Top      Up      ToC       Page 45 
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      |
   +----------------------+------------------------+----------------+

Top      Up      ToC       Page 46 
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.

Top      Up      ToC       Page 47 
   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.

Top      Up      ToC       Page 48 
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.

Top      Up      ToC       Page 49 
   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>.

Top      Up      ToC       Page 50 
   [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/>.

Top      Up      ToC       Page 51 
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>.

Top      Up      ToC       Page 52 
   [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>.

Top      Up      ToC       Page 53 
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