WO2013090308A2

WO2013090308A2 - Method and apparatus for authenticating a message

Info

Publication number: WO2013090308A2
Application number: PCT/US2012/069053
Authority: WO
Inventors: Pai MADHUSUDAN
Original assignee: Motorola Solutions, Inc.
Priority date: 2011-12-13
Filing date: 2012-12-12
Publication date: 2013-06-20
Also published as: WO2013090308A4; WO2013090308A3

Abstract

A method for transmitting and receiving authenticatable messages in a network communication system uses a NEXT-NONCE-COUNT along with the NONCE in a challenge transmitted from a client to a server. In addition, the client maintains a NONCE-COUNT value that is initialized to the NEXT-NONCE-COUNT in the challenge and thereafter incremented after every request is transmitted to the server. Each request includes the NONCE, a present value of the NONCE-COUNT value, and a signed response (SRES) that is a cryptographic hash of the NONCE, the present NONCE-COUNT value, and a shared secret user credential. The server, upon receiving a request, determines if the NONCE-COUNT value is sufficiently high compared to its server-maintained NONCE-COUNT value. When the received NONCE-COUNT value is sufficiently high compared to the server stored NONCE-COUNT value, and the received SRES is determined to be correct, the server increments its NONCE-COUNT value it maintains in association with the NONCE.

Description

METHOD AND APPARATUS FOR AUTHENTICATING A MESSAGE

FIELD OF THE DISCLOSURE

[0001] The present disclosure relates generally to client-server communication, and more particularly to methods for authenticating messages sent between a client and a server such that the message can be authenticated by the receiving entity in a way that the receiving entity does not have to challenge the sender in response to receiving each message.

BACKGROUND

[0002] Communications across networks between computers are susceptible to being intercepted or otherwise seen by people other than whom the communication was intended. Often such people can have malicious intent and seek to exploit information obtained from such communications for various purposes, including illegal activity. Consequently, network communications have long used

authentication and cryptographic techniques to mitigate the ability of unintended parties to obtain and exploit information from intercepted network communications.

[0003] Password authentication is one technique used in network communication as a common security measure. The password is a "secret" known to the parties (client or client user, and the server), but it is not directly communicated messages between the parties. Rather, the password is encrypted using, for example, a hash function.

Particular hash algorithms have t been standardized for network communication, and are referred to as Secure Hash Algorithms (SHA). One of the more common SHA standards is referred to as SHA-1 which was designed by the United States National Security Agency and has been published as a Federal Information Processing

Standard. Thus, SHA-1 is a widely used standard in network communication. SHA-2 is a more recent standard that has also been published and adopted in the network communications industry. [0004] However, merely hashing a password, alone, is not sufficient to ensure authenticity of the sender since a third party can merely copy the hashed password and re-send it, posing as the original transmitting party. Accordingly, further authentication techniques are needed. One commonly used authentication technique is known as digest authentication. The Internet Engineering Task Force (IETF) has standardized various digest authentication protocols. One commonly used digest authentication standard is known as RFC 2617 and has been published by the IETF. RFC 2617 describes an authentication protocol and describes the issuance of a challenge when authentication is in question. In digest authentication, the parties, such as a client and a server, each have a copy of a long-term user credential, such as a username and password. In this context, the client includes a user who is using a client machine to access the server. The user may use various different machines to access the server at different times using the same credentials. Upon requesting access, the server issues a challenge that includes a NONCE. The term NONCE refers to a word or number used once and is derived from the literary term "nonce word," referring to a made-up word for a usage that is not expected to recur. Upon receiving the NONCE from the server, the client uses the NONCE to generate a signed response (SRES) by hashing the NONCE with the user's password. The client then transmits a response including the SRES and the NONCE. The server computes an expected response (XRES), also based on the NONCE and the user's password using the same hash function/algorithm as the client uses to generate the SRES. The server compares the XRES to the received SRES. The SRES/XRES comparison authenticates the user (assuming they match), and the NONCE ensures that the SRES is only valid once, so attackers cannot replay the SRES to gain access to the server. However, attackers not interested in gaining access and are instead just interested in overwhelming the server can replay a stale SRES and NONCE, forcing the server to attempt the authenticate the attack message, using up server resources. Furthermore, the conventional NONCE approach prevents an authentic client from "pipelining" messages. Pipelining involves transmitting several messages to the server before the server has a chance to authenticate and respond to subsequent requests from the client since, conventionally, each request is challenged with a new NONCE. Another disadvantage of the one-time NONCE approach is that every request from the client is challenged, thereby resulting in a delay in granting service equal to the challenge round trip time.

[0005] One solution to address the problems associated with requiring the client to force the server to issue a new NONCE with every request is for the server to transmit a next NONCE in responses so that the client will have the next NONCE to be used in a subsequent request and avoid a step of the challenge process. This method, however, still has the problem of preventing pipelining. Furthermore, it tends to be adverse to messaging protocols that use small message size since the NONCE and next NONCE will use a significant number of bits in a message.

[0006] One solution to address the above problems with one-time NONCE and next NONCE is presented in RFC 2617. This solution uses a NONCE-COUNT in addition to the NONCE for digest generation. If a hacker replays a response, the server rejects the same due to stale NONCE-COUNT. However, this scheme requires the server to generate a fresh NONCE for each challenge to a hacker. This is because if a previous NONCE is sent in a challenge, the hacker who would have seen the SRES for the previous {NONCE & NONCE-COUNT}pair could replay this SRES and gain access to the service.

[0007] It may also be noted that generation of the NONCE and storing NONCE states (with authenticated NONCE COUNT) consumes CPU and Memory resources at the server. A hacker could exploit this resource consumption to generate several requests that solicit a challenge from the server, thereby causing a denial of service attack due to either CPU or Memory or both resources being consumed by the attack and hence not being available to valid users. A similar aspect of hacking may be to cause the server to forget the NONCE state for a given authenticated user. The next request carrying a valid SRES from the user would result in a challenge due to stale NONCE and thereby delay access to the service.

[0008] Accordingly, there is a need for a method and apparatus for authenticating a message that avoid these, and other problems associated with the prior art. BRIEF DESCRIPTION OF THE FIGURES

[0009] The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views, together with the detailed description below, are incorporated in and form part of the specification, and serve to further illustrate embodiments of concepts that include the claimed invention, and explain various principles and advantages of those embodiments.

[0010] FIG. 1 shows a system diagram of a network communication system using an authentication protocol in accordance with some embodiments;

[0011] FIG. 2 shows a message transaction diagram of an authentication protocol in accordance with some embodiments;

[0012] FIG. 3 shows a message transaction diagram of an authentication protocol in accordance with some embodiments; and

[0013] FIG. 4 shows a flow chart diagram of a method of performing authentication in accordance with some embodiments.

[0014] Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.

[0015] The apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

DETAILED DESCRIPTION

[0016] Embodiments disclosed herein solve the problems associated with the prior art, and include, in some embodiments, a method for authenticating requests between a client and server that includes receiving an initial request at the server from the client, and transmitting from the server to the client a NONCE and the next expected NONCE-COUNT in response to the initial request. The NONCE can have a validity period. The method further includes receiving from the client at the server an authentication response including the NONCE, a NONCE-COUNT value associated with the NONCE, and an SRES based on the NONCE, the NONCE-COUNT value, and a shared secret credential. The server can then commence authenticating the authentication response at the server by evaluating the SRES against an expected value for the SRES that is determined by the server. The method, responsive to authenticating the authentication response, can provide the service requested in the request and set a server NONCE-COUNT value associated with the NONCE to the NONCE-COUNT value sent by the client in the successfully authenticated request. Subsequent to authenticating the response, the method commences upon receiving a subsequent request at the server including the NONCE, an SRES, and a NONCE- COUNT value. When the received NONCE-COUNT value of the subsequent request is not greater than the server NONCE-COUNT value, the subsequent request is not treated as authentic. When the NONCE-COUNT value of the subsequent request is greater than the server NONCE-COUNT value the method commences by

determining that the SRES of the subsequent request is equal to an expected value for the SRES using the NONCE-COUNT value of the subsequent response, and setting the server NONCE-COUNT value to the NONCE-COUNT value in the subsequent successfully authenticated response. .

[0017] FIG. 1 shows a system diagram of a network communication system 100 using an authentication protocol in accordance with some embodiments. Network communications can include both client/server systems and peer to peer systems, with appropriate differences in communication protocols. The present system 100 illustrates a client/server system where, for example, a client 102 communicates with a server 104 via a network 112. The system disclosed here provides an overview of embodiments which will be discussed in further detail in subsequent figures and accompanying text. It may be noted that the client and server terminology in this disclosure refers to the entity being authenticated and the entity granting the service. This disclosure also applies to the authentication of the server by the client using client's CNONCE and server's CNONCE-COUNT.

[0018] The server 104 contains or controls resources that the client 102 can access and use, and can include information that can be transmitted to the client 102. In some embodiment the server 104 can perform services at the request of the client 102 and transmit the results of processing in response to a request to the client 102. The client 102 can transmit various requests to the server 104 over the network 112 using known or otherwise agreed upon network communication protocols. Examples of such protocols include hypertext transfer protocol (HTTP) and session initiation protocol (SIP), among others. Thus, client 102 can send an HTTP request 114 to server 104 via network 112. The request 114 can be formatted according to HTTP, and include a universal resource indicator (URI), a signed response (SRES), a

NONCE, and a NONCE count (NONCE-COUNT). The URI indicates a resource controlled or accessible by the server 104 which the client 102 is attempting to access. The SRES is a hash of the client'sl02 user's password, the NONCE, and the COUNT. The SRES can be produced using known hash functions such as, for example, the SHA functions using the password, NONCE, and NONCE-COUNT as inputs. The server 104, which knows the client 102 user's password, can produce an expected response (XRES) also using the password, NONCE, and NONCE-COUNT as inputs in the same hash functions at the server 104. The request 114 represents a request made after the client 102 and server have engaged in an initial transaction where the server has assigned the NONCE to the client 102. The NONCE is generally unique to the client 102 and is not used with other clients. The NONCE can be a number, a string, or a combination of the two, and it has a validity period. That is, the NONCE is valid for more than one request, and can be valid for the duration of the validity period. The validity period can be on the order of seconds to hours to days, or more, and can be of a fixed duration or an extendible duration. The NONCE-COUNT is a value that is incremented every time the client 102 uses the NONCE for generating an SRES to make a request of the server 104. The server 104 maintains a count as well and increments its count every time the server 104 receives a valid request 114. If the server receives a request having a NONCE-COUNT value that is not greater than the value for the count maintained by server for the particular NONCE, the server does not treat the request as authentic, and can challenge to the requesting client or ignore the request or return an authentication failure response.

[0019] Client 102 can access server 104 using, for example, a web browser to communicate HTTP formatted requests to the server 104 where server 104 is a web server. Other types of clients can likewise access the server 104. In some

embodiments server 104 can provide additional or different functions. For example, server 104 can be a communications server for supporting communications between wireless clients 106 and 108. The wireless clients 106, 108 can be, for example, cellular telephones, wireless personal digital assistants, two-way radios, and so on. The wireless clients 106, 108 communicate with one or more base stations 110 via an air interface that operates according to a known radio protocol. In some embodiments the wireless clients 106, 108 can have "push to talk" functionality for establishing dispatch communication between them, and other similar units. Dispatch calling refers generally to a half duplex mode of communication where a talking user presses and holds a button while talking. Dispatch communication is common among public safety entities using two way radio systems. Thus, the wireless clients 106, 108 can establish a communication link 120 between them through the base station 110, as serviced by the server 104. To initiate a dispatch call, for example, a wireless client can send a request 116 that uses a SIP messaging format to the server 104. The SIP request shall include URI, SRES, NONCE, and NONCE-COUNT information and is sent subsequent to an initial registration transaction where the server assigns the particular NONCE and provides the NONCE and a NEXT-NONCE-COUNT to the wireless client, either 106 or 108. The server 104 can be a server of a communication system that provided communication service to wireless clients, such as clients 106, 108, though base stations such as base station 110. The NONCE of request 116 is assigned to the requesting wireless client in an initial transaction, and as with the HTTP request, the wireless client maintains a NONCE-COUNT value that can be incremented with every request. The SRES of request 116 likewise is a hash of a shared secret password known to the wireless client and the server 104, the NONCE and the NONCE-COUNT. The server 104 computes an XRES to authenticate the request only when the NONCE-COUNT value in the request exceeds the NONCE- COUNT value stored by the server 104. When the request is successfully

authenticated, the server 104 increments its value of the NONCE-COUNT. Similarly, a landline-based SIP calling device 122 can use the SIP protocol to access calling services that can be established by a communications server.

[0020] The server 104 maintains records 118 for all assigned NONCEs. Each record can include a NONCE, its present NONCE-COUNT value, and a validity period (PERIOD). The NONCE can be cross referenced with a record for the particular client to which the NONCE has been assigned so that the server 104 can access the client's or the client user's password, among other information. Each NONCE is unique and assigned to a particular client during an initial transaction, or upon the client responding successfully to a subsequent challenge by the server. The NONCE- COUNT value is set to an initial value and only incremented when an authenticated request is received from the client to which the corresponding NONCE has been assigned. The validity PERIOD indicates the time during which the NONCE is valid. If a request is received after the expiration of the PERIOD, the requesting client will be challenged, re-authenticated, and new NONCE assigned, regardless of whether the NONCE-COUNT is a valid value.

[0021] FIG. 2 shows a message transaction diagram 200 of an authentication protocol in accordance with some embodiments. The diagram 200 shows messaging between a client 202 and a server 204. The client 202 can represent, for example, and of clients 102, 106, 108, or 122 of FIG. 1, or any other client operating according to embodiments taught herein. Initially the client and server have not established any means of authenticated communication, other than having a shared secret, i.e. a password or other secret code known to both the client 202, or a user of the client 202, and the server 202. Thus, the client 202 must engage in an initial transaction sequence to obtain a NONCE and establish a NONCE-COUNT.

[0022] To commence the authenticated communication, the client 202 first transmits an initial request 206 to the server 204. The request can contain a URI of desired resource controlled by, or accessible via, the server 204. Since the client 202 at this point is not authenticated, the server transmits a challenge 208. The challenge can include a NONCE selected by the server 204 for the client 202 to use in subsequent authenticated communications. The challenge 208 can further include an initial NONCE-COUNT value (NONCE-COUNTi), which can be a higher value than that stored by the server 204 for a corresponding NONCE-COUNT value corresponding to the particular NONCE. After issuing the challenge 208, the client 202 can set 212 its NONCE-COUNT to the indicated initial value of NONCE-COUNTi. The client 202 also produces an SRES that is a hash of the password, the NONCE, and the NONCE- COUNT value (which will be the initial count value, NONCE-COUNTi). The client 202 can then transmit a request 214 that includes the desired resource URI, SRES, NONCE, and NONCE-COUNT value to the server 204. The server will have prior, or in response to receiving the request 214, determine an expected response, XRES 210. Upon receiving the request 214, the server 204 compares the receiving SRES with the determined XRES 216 if the received NONCE-COUNT value of the request 214 is greater than the NONCE-COUNT value for the NONCE stored at the server (received count value, COUNTr, being greater than the stored count value, COUNTs). Upon both the received NONCE-COUNT value of request 214 being greater than the stored NONCE-COUNT value at the server for the NONCE, and the XRES comparing successfully with the received SRES, the server 204 will issue a requested response 218 to the client 202. Either upon transmitting the request 214, or upon receiving the response 218, the client 202 increments its NONCE-COUNT value 219. Likewise, upon successfully authenticating 216 the request 214, the server increments its stored NONCE-COUNT value as indicated by INC_COUNT at process 216.

[0023] For a subsequent request 220, the client 202 transmits a URI, SRES, NONCE, and the incremented NONCE-COUNT value (NONCE-COUNTi+1). The SRES of subsequent request 220 is created using the client's or client user's password,

NONCE and the incremented NONCE-COUNT value (NONCE-COUNTi+1). The server 204 determines if received NONCE-COUNT value (NONCE-COUNTi+1) is greater than the stored NONCE-COUNT value at the server 204 corresponding to the particular NONCE, which will be at NONCE-COUNTi. Upon determining that the received NONCE-COUNT value of request 220 is greater than the stored NONCE- COUNT value at the server for the particular NONCE, the server 204 then determines an XRES (XRESi+1) using the received NONCE-COUNT value, NONCE, and password, and compares the XRES to the received SRES at process 222. If the received SRES compares properly with the determined XRES, the server 204 can then increment its stored NONCE-COUNT value as part of process 222.

[0024] Thus, embodiments allow the client 202 to pipeline several requests without having to wait for a response, obtain a new or next NONCE, or respond to a challenge for every request. For example, the client can send multiple requests 228, 230, 232, incrementing its NONCE-COUNT value each time. Each request includes a URI, which can vary for each request 228, 230, 232, an SRES produced using the password, the NONCE, and the present NONCE-COUNT value at each request, the NONCE, and the present NONCE-COUNT value. After sending all three requests, the server 204, which can buffer requests, commences processing request 228 at process 234. The NONCE-COUNT value of request 228 is compared to the stored NONCE- COUNT value maintained at the server for the corresponding NONCE, and if the received NONCE-COUNT value is greater, the server 204 then authenticates the request by comparing the determined XRES with the received SRES for the NONCE- COUNT value of request 228. Once the request has been successfully authenticated, the server 204 increments its NONCE-COUNT value, and provides a response 236 corresponding to request 228. Requests 230 and 232 can likewise be processed and authenticated in turn, incrementing the server's NONCE-COUNT value

corresponding to the particular NONCE. It may be noted by those well versed in the art that messages delivered out of sequence at the server due to unreliable transport shall be handled according to the stale NONCE-COUNT use case for such messages alone.

[0025] FIG. 3 shows a message transaction diagram 300 of an authentication protocol in accordance with some embodiments. The client 202 and server 204 commence an initial set up 302 where the client receives a NONCE and next NONCE-COUNT from the server 204, following the process of request 206, and challenge 208 of FIG. 2. At that point the client 202 can commence authenticated messaging to the server 204. At some arbitrary request "m" 304, the client 202 transmits to the server 204, the server's stored NONCE-COUNT will be at m-1. The server then commences the authentication process 308 which compares the received NONCE-COUNT value with stored NONCE-COUNT value at the server to ensure that the received NONCE- COUNT value is greater, and the received SRES is compared with an appropriately determined XRES for the present NONCE-COUNT value of the request 304. Upon a successful authentication, the server increments its NONCE-COUNT value.

[0026] An attacker 312 can try and replay the request 304 by transmitting false request 314 which includes at least some of the same contents of request 304, including a URI, SRES, NONCE, and NONCE-COUNT value which can be copied from request 304. When the server 204 undertakes an authentication process 316, the server will determine that the received NONCE-COUNT value does not exceed the stored NONCE-COUNT value at the server corresponding to the particular NONCE since the stored NONCE-COUNT value had been incremented in process 308. Of course, the attacker 312 may have anticipated that the NONCE-COUNT value would not be correct, and can try a higher NONCE-COUNT value. In that case, however, the SRES still will not compare with a server determined XRES because the attacker will not have the client 202 password to produce an SRES that compares with the XRES. Thus, in authentication process 316, the NONCE-COUNT may not evaluate properly or the SRES may not compare properly to the server's XRES, and the server 204 does not increment the stored NONCE-COUNT value (NULL INC). The server 204 can then ignore the false request 314, or issue a challenge 318. The attacker, however, without the password used by the client 202, cannot successfully produce a response than can be successfully authenticated. Subsequent to the attack, the client 202 can transmit a subsequent request 320, using NONCE-COUNT value "n." The NONCE-COUNT value will then be greater than the stored NONCE-COUNT value at the server 204, which will be at value of "m." The subsequent request 320 also includes an SRES that will compare properly with the server determined XRES for the received NONCE-COUNT value in authentication process 322, and as a result the server will increment its stored NONCE-COUNT value corresponding to the particular NONCE used in the request 320.

[0027] FIG. 4 shows a flow chart diagram of a method 400 of performing

authentication in accordance with some embodiments. The method is particularly reflective of operations performed by a server, but the client operations are easily discernible in the description. In the diagram the various boxes or blocks represent a process or a group of related processes performed in accordance with some embodiments. As an initial process 402, the server receives an initial request from a client and the server selects a NONCE and transmits the NONCE to the requesting client. The server can assign a particular starting value for the NONCE-COUNT to be used by the client, or the value can be implicit or always started at a particular value, such as 1. The server can then receive a subsequent request 404 that includes a URI, SRES, NONCE, and NONCE-COUNT value. The server can first check to see if the NONCE is still within its validity period 406. Likewise, if the client knows when the NONCE expires, the client, prior to transmitting the request, can determine if the NONCE is still valid, and commence sending the response only if the NONCE is presently valid, otherwise the client can obtain a new NONCE. If the NONCE received by the server is stale, meaning its validity period has expired, the server can then treat the subsequent request as an initial request, and assign a new NONCE, returning to process 402. When the NONCE received in the request is within its valid period, the server can then check to determine whether the received NONCE-COUNT value is greater than the stored NONCE-COUNT value at the server at process 408. If the received NONCE-COUNT value is greater than the stored NONCE-COUNT value, the server can then proceed to determine whether the request can be authenticated 410. In authenticating the request, the received SRES is compared with an XRES determined by the server with the NONCE-COUNT value received in the request. Only when the received NONCE-COUNT value is greater than the stored NONCE-COUNT value, and the request can be authenticated does the server increment its server NONCE-COUNT value and respond to the request 412.

[0028] If the server determines that the received NONCE-COUNT value is not in an appropriate range, i.e. less than or equal to the stored NONCE-COUNT value at the server corresponding to the particular NONCE, the server can issue a challenge 414. The challenge can include the same NONCE and NEXT-NONCE-COUNT value set to a value higher than the server NONCE-COUNT stored at the server. Upon receiving the challenge, a valid client can set its client NONCE-COUNT to the NEXT-NONCE-COUNT received in the challenge, and re-transmit a request that includes the NONCE, an updated client NONCE-COUNT based on the received NEXT-NONCE-COUNT, and an SRES that is a hash of the NONCE, the updated client NONCE-COUNT, and the shared secret credential. This means that the server re-uses the NONCE during the validity period even for issuing challenges. The method can then return to waiting for a response at 404. If a response to the challenge is received at the server, the server can determine if the client successfully responded to the challenge at 406 and 408. The client successfully responds to the challenge by transmitting a properly hashed SRES that matches an XRES produced by the server. If the challenge response is successfully authenticated, the server sets its copy of the NONCE-COUNT for the given NONCE to the NONCE-COUNT in the successfully authenticated request. . If the challenge response is not successful, as determined at 410, the server can issue an authentication failed message 416. Alternatively, the server can ignore the response and return to waiting for a subsequent response 404.

[0029] Thus, when the client does not respond to a challenge or a hacker replays a request requiring a challenge (stale NONCE or NONCE-COUNT) or hacker sends a request with incorrect SRES or any other request that is not successfully authenticated by the server, the NONCE state at the server for the given client is unaffected. In other words, a client once authenticated with a given NONCE and NONCE-COUNT is never challenged for the lifetime of the NONCE, so long as the NONCE-COUNT and SRES of each subsequent message is valid. The same NONCE can be used by the client and server despite any form of replay attack, including for challenges issued during the validity period of the NONCE. This allows NONCE lifetime to be set to a large duration. Those well versed in the art may note that a new NONCE shall also be setup when the NONCE-COUNT wraps around.

[0030] In the foregoing specification, specific embodiments have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present teachings. [0031] The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims as issued.

[0032] Moreover in this document, relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms "comprises," "comprising," "has", "having," "includes", "including," "contains", "containing" or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises ...a", "has ...a", "includes ...a", "contains ...a" does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, contains the element. The terms "a" and "an" are defined as one or more unless explicitly stated otherwise herein. The terms "substantially", "essentially", "approximately", "about" or any other version thereof, are defined as being close to as understood by one of ordinary skill in the art, and in one non-limiting embodiment the term is defined to be within 10%, in another embodiment within 5%, in another embodiment within 1% and in another embodiment within 0.5%. The term "coupled" as used herein is defined as connected, although not necessarily directly and not necessarily

mechanically. A device or structure that is "configured" in a certain way is configured in at least that way, but may also be configured in ways that are not listed.

[0033] It will be appreciated that some embodiments may be comprised of one or more generic or specialized processors (or "processing devices") such as

microprocessors, digital signal processors, customized processors and field programmable gate arrays (FPGAs) and unique stored program instructions (including both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the method and/or apparatus described herein. Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches could be used.

[0034] Moreover, an embodiment can be implemented as a computer-readable storage medium having computer readable code stored thereon for programming a computer (e.g., comprising a processor) to perform a method as described and claimed herein. Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory) and a Flash memory. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation.

[0035] The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.

Claims

Claims We claim:

1. A method for authenticating requests, comprising:

receiving an initial request at a server from a client;

transmitting from the server to the client a NONCE in response to the initial request, wherein the NONCE has a validity period;

receiving from the client an authentication response including the NONCE, a NONCE-COUNT value associated with the NONCE, and an SRES based on the NONCE, the NONCE-COUNT value, and a shared secret credential;

authenticating the authentication response at the server by evaluating the SRES against an expected value for the SRES determined by the server;

responsive to authenticating the authentication response, providing the service requested by the request and setting a server NONCE-COUNT value associated with the NONCE to the NONCE-COUNT value received in the request;

subsequent to authenticating the response, receiving a subsequent request at the server including the NONCE, an SRES, and a NONCE-COUNT value;

when the received NONCE-COUNT value of the subsequent request is not greater than the server NONCE-COUNT value the subsequent request is not treated as authentic; and

when the NONCE-COUNT value of the subsequent request is greater than the server value determining the SRES of the subsequent request is equal to an expected value for the SRES using the COUNT NONCE-COUNT value of the subsequent response and incrementing the server NONCE-COUNT value.

2. The method of claim 1, wherein the server further determines whether the NONCE received in the subsequent request is valid based on the validity period.

3. The method of claim 1, wherein the initial request, authentication request, and subsequent request are received using one or more of:

a digest authentication scheme;

a session initiation protocol (SIP); and

a hypertext transfer protocol (HTTP).

4. The method of claim 1, wherein the initial request, authentication request, and subsequent request are for a push to talk dispatch communication.

5. The method of claim 1, wherein, when the subsequent request is treated as authentic, the validity period of the NONCE is extended.

6. The method of claim 1, wherein when the subsequent request is not treated as authentic, the method further comprises transmitting a challenge to the client that transmitted the subsequent request, wherein the challenge includes the NONCE and a NEXT-NONCE-COUNT that is greater than a present value of the server NONCE- COUNT.

7. The method of claim 1, further comprising further requests from the client at the server after the subsequent response, wherein each further request is treated as authentic during the validity period of the NONCE when each further request contains the NONCE, a NONCE-COUNT that is higher than the server's NONCE-COUNT for the NONCE, and an SRES based on the NONCE, NONCE-COUNT, and the shared secret credential; and

wherein, in response to receiving each further authenticated request the server sets the server NONCE-COUNT value to the NONCE-COUNT value of the further authenticated request.

8. A method for transmitting requests from a client to a server, comprising:

receiving at the client from the server, a NONCE;

maintaining at the client a NONCE-COUNT value associated with the NONCE;

generating an SRES hash at the client using the NONCE, a present value of the maintained NONCE-COUNT value associated with the NONCE, and a shared secret credential;

transmitting a request to the server from the client that includes the SRES, NONCE, and NONCE-COUNT value; and

responsive to transmitting the request, incrementing the NONCE-COUNT value at the client.

9. The method of claim 8, wherein transmitting the request is performed using one or more of:

a session initiation protocol (SIP);

a hypertext transfer protocol (HTTP); and

a digest authentication scheme.

10. The method of claim 8, further comprising, subsequent to transmitting the request to the server from the client that includes the SRES, NONCE, and NONCE-COUNT value, transmitting a subsequent request that fails authentication at the server;

receiving from the server a challenge including the NONCE, and a NEXT- NONCE-COUNT that is greater than a present value of the server NONCE-COUNT; updating the client NONCE-COUNT to the NEXT-NONCE-COUNT to produce an updated client NONCE-COUNT, responsive to receiving the challenge; and

re-transmitting the request including the NONCE, the updated client NONCE- COUNT, and an SRES based on the NONCE, updated client NONCE-COUNT, and the shared secret credential.

11. The method of claim 8, wherein transmitting the request comprises transmitting a request for a push to talk dispatch communication.

12. A method for authenticated communication between a server and a client, comprising:

generating a NONCE to be included in each request sent by the client to the server during a validity period of the NONCE;

maintaining a client NONCE-COUNT at the client and a server NONCE- COUNT at the server for the NONCE;

incrementing the client NONCE-COUNT with each request sent by the client to the server, wherein each request includes the NONCE, a present value of the client NONCE-COUNT, and an SRES based on the NONCE, the present value of the NONCE-COUNT, and a shared secret credential known to the client and the server; and

incrementing the server NONCE-COUNT for the NONCE when a request received at the server from the client includes the NONCE, a NONCE-COUNT having a value greater than the server NONCE-COUNT for the NONCE, and a valid SRES.

13. The method of claim 12, wherein when a request is received at the server that includes the NONCE, a NONCE-COUNT having a value greater than the server NONCE-COUNT for the NONCE, and a valid SRES the server services the request without challenging the client.

14. The method of claim 12, wherein at least one request sent from the client to the server is performed using one or more of:

a digest authentication scheme;

a hypertext transfer protocol; and

a session initiation protocol.

15. The method of claim 12, further comprising:

receiving at the server from the client, a request that fails an authentication; transmitting from the server to the client a challenge including the NONCE, and a NEXT -NONCE-COUNT that is greater than a present value of the server NONCE-COUNT for the NONCE;

updating the client NONCE-COUNT to the NEXT-NONCE-COUNT to produce an updated client NONCE-COUNT, responsive to receiving the challenge; and

re-transmitting the request from the client including the NONCE, the updated client NONCE-COUNT, and an SRES based on the NONCE, updated client NONCE- COUNT, and the shared secret credential.