US-12621300-B2 - Digest access authentication for a client device

US12621300B2US 12621300 B2US12621300 B2US 12621300B2US-12621300-B2

Abstract

A method comprising a client device performing digest access authentication with a server device. The digest access authentication comprises sending a first request towards the server device for accessing a resource. The digest access authentication comprises receiving a first response from the server device. The first response comprises at least two challenges and indications of as many different digest algorithms, one digest algorithm is associated with each challenge. The digest access authentication comprises calculating a response to one of the challenges using the digest algorithm associated with said one of the challenges. The response to said one of the challenges is indicative of all of the different digest algorithms. The digest access authentication comprises sending a second request towards the server device for accessing the resource. The second request comprises the response to said one of the challenges. The digest access authentication comprises receiving a second response from the server device. The second response indicates successful digest access authentication with the server device.

Inventors

Vesa Lehtovirta
Jari Arkko
Mohit Sethi
John Mattsson

Assignees

TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)

Dates

Publication Date: 20260505
Application Date: 20210616

Claims (16)

1 . A method for digest access authentication, the method being performed by a client device and comprising: performing digest access authentication with a server device, wherein performing the digest access authentication comprises: sending a first request towards the server device for accessing a resource; receiving a first response from the server device, wherein the first response comprises at least two challenges, and indications of as many different digest algorithms, one digest algorithm being associated with each challenge; calculating a response to a selected one of the challenges using a selected one the digest algorithm associated with the selected one of the challenges, wherein a list of the different digest algorithms is used as an input in calculating the response by the selected one of the digest algorithms; sending a second request towards the server device for accessing the resource, wherein the second request comprises the response to the one of the challenges; and receiving a second response from the server device, wherein the second response indicates successful digest access authentication with the server device.
2 . The method according to claim 1 , wherein, in the first response, each of the indications of the different digest algorithms is provided in its own WWW-Authenticate header field or its own Proxy-Authenticate header field.
3 . The method according to claim 1 , wherein each of the challenges comprises a nonce, and wherein the response to the one of the challenges is calculated as a function of the nonce for the one of the challenges.
4 . The method according to claim 1 , wherein the second request further comprises an indication of the digest algorithm used for calculating the response to the one of the challenges.
5 . The method according to claim 1 , wherein the second request comprises an authorization header, and wherein the response to the one of the challenges is provided in the authorization header.
6 . The method according to claim 1 , wherein the second response further comprises the resource.
7 . The method according to claim 1 , wherein the digest access authentication is any of: Hypertext Transfer Protocol (HTTP); digest authentication; Authentication and Key Agreement (AKA); digest access authentication; Session Initiation Protocol (SIP); and digest authentication.
8 . The method according to claim 1 , wherein calculating the response to the one of the challenges comprises calculating a cryptographic hash function output using a cryptographic hash function, and wherein the cryptographic hash function differs between the different digest algorithms.
9 . The method according to claim 1 , wherein the indications of the different digest algorithms are provided in plaintext in the first response.
10 . The method according to claim 9 , wherein calculating the response to the one of the challenges comprises calculating a cryptographic hash function, wherein the cryptographic hash function is calculated for a string of characters, and wherein the string of characters comprises a concatenation of the indications.
11 . The method according to claim 1 , wherein the indications of the different digest algorithms are protected in the first response.
12 . The method according to claim 11 , wherein the indications are in the first response provided by means of a hash-based message authentication code calculated for the indications.
13 . The method according to claim 11 , wherein the method further comprises: verifying the indications of the different digest algorithms before calculating the response to the one of the challenges.
14 . The method according to claim 13 , wherein calculating the response to the one of the challenges comprises calculating a cryptographic hash function, wherein the cryptographic hash function is calculated for a string of characters, and wherein the string of characters comprises the indications.
15 . A client device for digest access authentication, the client device comprising: processing circuitry; and memory operatively coupled to the processing circuitry and comprising instructions that, when executed by the processing circuitry, configure the client device to: perform digest access authentication with a server device; and as part of performing the digest access authentication: send a first request towards the server device for accessing a resource; receive a first response from the server device, wherein the first response comprises at least two challenges, and indications of as many different digest algorithms, one digest algorithm being associated with each challenge; calculate a response to a selected one of the challenges using a selected one the digest algorithm associated with the selected one of the challenges, wherein a list of the different digest algorithms is used as an input in calculating the response by the selected one of the digest algorithms; send a second request towards the server device for accessing the resource, wherein the second request comprises the response to the one of the challenges; and receive a second response from the server device, wherein the second response indicates successful digest access authentication with the server device.
16 . A non-transitory computer-readable medium having a computer program for digest access authentication stored thereon that, when executed by processing circuitry of a client device, causes the client device to: perform digest access authentication with a server device by: sending a first request towards the server device for accessing a resource; receiving a first response from the server device, wherein the first response comprises at least two challenges, and indications of as many different digest algorithms, one digest algorithm being associated with each challenge; calculating a response to a selected one of the challenges using a selected one the digest algorithm associated with the selected one of the challenges, wherein a list of the different digest algorithms is used as an input in calculating the response by the selected one of the digest algorithms; sending a second request towards the server device for accessing the resource, wherein the second request comprises the response to the one of the challenges; and receiving a second response from the server device, wherein the second response indicates successful digest access authentication with the server device.

Description

TECHNICAL FIELD Embodiments presented herein relate to methods, a client device, a server device, computer programs, and a computer program product for digest access authentication. BACKGROUND In general terms, in computer security, challenge-response authentication is a family of protocols in which one party presents a question (a “challenge”) and another party must provide a valid answer (a “response”) to be authenticated. The simplest example of a challenge-response protocol is password authentication, where the challenge is asking for the password and the valid response is based on the correct password. So-called HTTP Digest Access Authentication, as defined in RFC 7616, defines a simple challenge-response authentication method for the Hypertext Transfer Protocol (HTTP). When a client device using HTTP tries to access a protected resource at a server device, the server device can send a challenge and authenticate the client device before allowing access to the protected resource. HTTP Digest authentication provides better security when compared to the basic HTTP authentication scheme defined in RFC 7617. An example message exchange between a client device and a server device for HTTP digest is shown in FIG. 1. Step S1: The client device sends an HTTP request (shown as GET) to access a protected resource at the server device. Step S2: The server device sends an HTTP response with the status code 401 unauthorized. This message includes a WWW-Authenticate header (where WWW is short for world wide web). The header value includes parameters such as realm, nonce, algorithm, qop, etc. The realm is a string that contains information about the entity (server) performing authentication. It can be of the form somename@example.org. The nonce is a unique string generated by the server device for each 401 response with the WWW-Authenticate header. The nonce ensures freshness during authentication and prevents replay attacks. The algorithm is a string indicating the algorithm which the client device should use for preparing the digest response. The algorithms can be MD5, SHA256, etc. or MD5-sess, SHA-256-sess, etc. The ‘sess’ denotes the session variant of digest authentication and use slightly different calculations for generating the correct digest response. The session variant creates a session key for the authentication of subsequent requests and responses. The qop defines the quality of protection parameter and can be “auth” for authentication and “auth-int” for authentication with integrity protection. These parameters comprise a challenge for the client device that the client device must successfully respond to before being allowed to access the protected resource. Step S3: The client device sends another HTTP request (shown as GET) with an Authorization header. The Authorization header includes parameters such as username, qop, response, uri etc. The username is the name of user of the server device. The qop defines the quality of protection selected by the client device. It is one of the qop offered by the server device. The response is a string of (hexadecimal) digits that is calculated based on the challenge and it proves the client device's knowledge of the password. The uri is the requested uniform resource identifier. In the example shown in FIG. 1, the requested uri is “/resource/protected”. The client device uses the specified algorithm to compute the response based on the challenge. One example of how the response can be calculated will be described in the following. response=H(H(A1):nonce:nc:cnonce:qop:H(A2)), whereH(x) is a cryptographic hash function operating on the variable x,A1=username:realm:passwd, if the algorithm used is MD5, SHA256 etc., orA1=H(username:realm:passwd:nonce-prime:cnonce-prime), if the algorithm uses is the session variant, i.e., MD5-sess, SHA-256-sess. Here nonce-prime is the nonce sent by the server in the WWW-Authenticate header and cnonce-prime is the cnonce included by the client in the response, andA2=method:request-uri, if the qop used is auth, orA2=method:request-uri: H(entity-body), if the qop used is auth-int. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied. The method depends on the request HTTP method (for example: GET, PUT, POST etc.). Step S4: The server device verifies the response from the client device. If the response is correct, the server device sends a HTTP response with status code 200 OK to the client device. The response can also include an Authentication-Info header to optionally support mutual authentication, whereby, the server device also proves its knowledge of the password in the parameter rspauth of the Authentication-Info header. The server knowledge of password in the Authentication-Info header is calculated similarly as the response is calculated by the client device, except with the following differences: A2=request-uri, if qop used is auth, andA2=request-uri “:” H(entity-body).