Mutual Authentication Protocol for HTTP

If the client's authentication value was correct, it means that the client definitely owns the credential based on the expected password (ie, the client's authentication succeeded.) The server will respond with a success message (200-VFY-S) (7 ). The client MUST first verify the validity of the server-side authentication value contained in message (7).

Figure 2 depicts the shortcut flows described above. Under the appropriate settings and implementations, most of the requests to resources are expected to meet both the criteria, and thus only one round-trip of request/responses will be required in most ca

The header MUST contain the same parameters as in 401-INIT, except that the deprecated parameter contains token 1. The header MUST contain parameters with the following keys:. required, extensive-token) must be "-draft10" token in this specification. It MUST be the same value as received from the server. required, string) is the username encoded in UTF-8. If this name comes from user input, the client software MUST prepare the string using SASLprep [RFC4013] before encoding it to UTF-8. required, determined by the algorithm) is the value of the client-side key exchange Kc1 determined by the algorithm used.

The header SHALL contain the parameters with the following keys:. mandatory, extended-token) must be the token "-draft10" in this specification. MUST be the same value as received from the client. mandatory, hex-fixed-number) MUST be a session identifier, which is a random integer. The value of the nc-window parameter is RECOMMENDED to be 32 or more. mandatory, integer) represents the suggested time (in seconds) that the client can reuse the session represented by the sid.

The value of this parameter is not directly related to the duration that the server monitors for the session represented by the page. optional, string) specifies which path in the URI space the same authentication should be applied to. All path elements contained in the parameter MUST be within the specified author domain: if not, clients MUST ignore such elements. required, determined by the algorithm) is the VKc client-side authentication value determined by the algorithm. The parameters in the header are as follows:. required, extensive-token) must be "-draft10" token in this specification.

The behavior is undefined when other values are specified. mandatory, fixed hex number) MUST be the value received from the client. mandatory, determined by the algorithm) is the VKs value of the server-side authentication check, which is specified by the algorithm. optional, integer) is the number of seconds after which the client must re-validate the user's password for the current authentication realm. A value of 0 means that the client SHOULD automatically forget the user-entered password for the current authentication realm and return to the unauthenticated state (ie, server-initiated logout). However, this does not mean that long-term password reminders (such as password reminders and autofills) should be removed.

Authentication Realms

Resolving Ambiguities

Depending on the "path" parameters given in the "401-KEX-S1" message (see Section 4), there may be several candidates when the client is going to send a request, including an authentication token (Step 3 and 4 of the decision) procedure presented in Section 9). If the client has previously sent a request to the same URI, and if it remembers the authentication realm requested by 401-INIT messages at that time, use that realm. From the list of possible domain specifications shown above, each one takes precedence over those described next.

If there are multiple choices with different domain postfix specifications, the one with the longest domain postfix takes priority over the one with a shorter domain postfix. If there are domains with the same authentication domain, there is no defined priority: the client CAN choose one of the possible choices. Whenever possible, server operators are encouraged to avoid such ambiguities by setting the "path" correctly.

Session Management

Servers SHOULD check for duplicate nonces received, and if any duplicates are detected, the server SHOULD drop the session and respond with a 401-STALE message, as described in Section 10. The server MAY also reject other invalid nonce values (such as those above the nc-max limit) by sending a 401-STALE message. Nonce values and any non-CE related values MUST always be treated as natural numbers within an infinite range.

Implementations using fixed-width integers or fixed-precision floats MUST handle integer overflows correctly and carefully. Such implementations are RECOMMENDED to accept any larger values that cannot be represented in fixed-width integer representations, unless other constraints such as internal header length constraints are included. The protocol is carefully designed so that both clients and servers can implement the protocol using only fixed-width integers by rounding any overflow values to the largest possible value.

Validation Methods

If the "tls-cert" verification type is used, the server certificate provided on the TLS connection SHOULD be checked to ensure that the server actually possesses the corresponding secret key. However, if the client is a web browser with any scripting capability, the underlying TLS channel used with HTTP/TLS MUST provide server identity verification. This means (1) that an anonymous Diffie-Hellman key exchange cipher suite MUST NOT be used, and (2) that server-supplied server certificate verification MUST be performed.

For other systems, when the underlying TLS channel used with HTTP/TLS does not perform server identity verification, the client MUST ensure that all responses are validated using the mutual authentication protocol regardless of the existence of the 401 -INIT answers. When TLS accelerating proxies are used, it is difficult for the authenticating server to obtain the TLS key information used between the client and the proxy.

Authentication Extensions

Decision Procedure for Clients

If the client software needs to access a new web resource, check whether the resource is expected to be in an authentication realm for which the user has already been authenticated by a mutual authentication scheme. If you receive a 200-Optional-INIT message with a different authentication realm than expected, go to step 6. If you receive a 401-INIT message with the same authentication realm, go to step 13 (see Note 1).

The client will be in the "AUTH-REQUESTED" status, and is RECOMMENDED to process the content sent from the server, and to prompt user for a username and a password. If a user explicitly requests to log out (via user interfaces), the client MUST forget the user's password, go to step 5, and reload the current resource without an authentication header. Any kind of response (including a normal response) other than that shown in the above procedure SHOULD be interpreted as a fatal communication error, and in such cases the clients MUST NOT accept any data (response body and other content-related headers) sent from be processed. the server.

Decision Procedure for Servers

Please note that the server MUST NOT send a 401-INIT response in this case, as it will leak the information to the client that the specified user will not be accepted. If the authentication domain specified in the req-VFY-C request is not the expected one, send a 401-INIT or a 200-Optional-INIT response. If none of the above is true, the server will look up the session corresponding to the receiving side and the authentication domain.

If the session corresponding to the received sid could not be found, or it is in the "inactive". If the session is in the "authenticated" state, and the request has an nc value previously received from the client, send a 401-STALE message. If the session is in the "key exchange" state, it MUST be changed to the.

Authentication Algorithms

Support Functions and Notations

The "exchange key" status entries MUST be retained unless there is an emergency situation such as a server restart or table capacity overflow. Editor's Note: Unlike the colon-separated concept used in the Basic/Digest HTTP authentication scheme, 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 OCTETS function converts an integer to the corresponding radix-256 big-endian octet string with its natural length: See section 3.2 for the definition of "natural length".

Default Functions for Algorithms

Application Channel Binding

Application for Proxy Authentication

Methods to Extend This Protocol

IANA Considerations

Security Considerations

Security Properties
Denial-of-service Attacks to Servers
Implementation Considerations
Usage Considerations

However, in terms of resource consumption, a situation with the mutual authentication method is slightly better than Digest, because HTTP requests without any kind of authentication requests will not generate any kind of sessions. To implement the protocol securely, the Authentication-Info headers in the 200-VFY-S messages MUST always be validated by the client. The authentication status on the client side MUST be visible to the client's users.

It is recommended that the server-side storage of user passwords contain the values encoded by the one-way function J(pi), rather than the real passwords, which have been hashed by ph or pi. This means that when the host type auth domain is used for authentication on an HTTPS site, and when an HTTP server on the same host requests mutual authentication within the same domain, the client will send the username in clear text. If values other than 'none' are used, you MUST ensure that the hash values of the passwords are not made public.

Notice on Intellectual Properties

Normative References

Informative References

Appendix A. (Informative) Generic Syntax of Headers

If it does not contain an authorization header, or contains an authorization header with a scheme other than reciprocal, it is a normal request.

Appendix B. (Informative) Draft Remarks from Authors

Changes in Revision 09

Implementations MAY perform more stringent checks than the above procedure, as defined in Section 3. VKc, VKs oa, ob client/server key verifiers vkc, vks oa, ob parameter names for those. To simplify the entire specification, the type of parameters associated with the nonce-counter change from a hex integer to an integer.

Authors’ Addresses