Patent Application
20160344744
Embodiments of the invention relate to the Generic Bootstrapping Architecture (GBA).
In the Generic Bootstrapping Architecture (GBA) defined in the 3rd Generation Partnership Project (3GPP) TS 33.220, a device with 3GPP credentials (e.g., a Subscriber Identity Module (SIM) card) can authenticate itself to a service using those credentials. The device first bootstraps with a Bootstrapping Server Function (BSF), which is located in the 3GPP operator network. This bootstrapping is performed using the Authentication and Key Agreement (AKA) procedure in which the device and the network are mutually authenticated. As a result of the mutual authentication, the device and the BSF generate a GBA master key (Ks) from the 3GPP credentials, and the BSF provides the device with a bootstrapping transaction identifier (B-TID) for the bootstrapping context.
When the device wants to use a GBA enabled application service (which is called the Network Application Function (NAF) in GBA), the device is requested by the NAF to authenticate itself. The device provides the NAF with the B-TID and authentication information (e.g., a Hypertext Transfer Protocol (HTTP) digest as defined in RFC 2617). The NAF then queries the BSF for a session key between itself and the device, and receives from the BSF a NAF specific session key (KsNAF). The device and the BSF can both generate KsNAF from the GBA master key and NAF_ID, which is based on the NAF's Fully Qualified Domain Name (FQDN). After the NAF receives KsNAF from the BSF, the NAF can use the key for authenticating the device by verifying the digest. Now the device has authenticated itself to the NAF. Further data exchange between the device and the NAF can continue with the HTTP or the HTTP based protocols.
The device's authentication to the NAF is performed over the Ua reference point, where the NAF specific key is used to authenticate the device and wherein further data exchange between the device and the NAF takes place. The protocol use by the Ua reference point has been standardized by 3GPP and is fixed to HTTP.
According to one embodiment, a method is provided to be performed by a network element. The network element provides an application service to a device over a network. The method comprises the steps of authenticating a request message from the device using a shared key generated according to the GBA, and sending to the device a response indicating a successful authentication. The response includes information that indicates one or more supported protocols for establishing a communication session between the device and the network element.
According to another embodiment, a network element provides an application service to a device over a network. The network element comprises a circuitry adapted to cause the network element to authenticate a request message from the device using a shared key generated according to the GBA, and to send to the device a response indicating a successful authentication. The response includes information that indicates one or more supported protocols for establishing a communication session between the device and the network element.
In one embodiment, the circuitry comprises a processor, a memory and an interface both coupled with the processor. The memory contains instructions that, when executed, cause the processor to authenticate a request message from the device using a shared key generated according to the GBA, and to send to the device a response indicating a successful authentication. The response includes information that indicates one or more supported protocols for establishing a communication session between the device and the network element.
According to yet another embodiment, a network element provides an application service to a device over a network. The network element comprises an authentication module adapted to authenticate a request message from the device using a shared key generated according to the GBA, and a sender module adapted to send to the device a response indicating a successful authentication. The response includes information that indicates one or more supported protocols for establishing a communication session between the device and the network element.
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that different references to “an” or “one” embodiment in this disclosure are not necessarily to the same embodiment, and such references mean at least one. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
In the following description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description. It will be appreciated, however, by one skilled in the art, that the invention may be practiced without such specific details. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.
The 3GPP has standardized the protocol use by the Ua reference point as being fixed to HTTP. The 3GPP does not specify how other protocols can be used. To specify the use of a protocol other than HTTP on the Ua reference point needs further research and standardization efforts. However, in some scenarios a different protocol than HTTP is desired; e.g., for the purpose of improving the security and data integrity. If the device wants to use a different protocol (e.g., the Constrained Application Protocol (CoAP)), it would have to try sending a CoAP message to the NAF to see if the NAF responds to the message and indicates support for CoAP. This kind of blindly trying different options is not only inefficient and time consuming, but can be futile for the devices.
Embodiments of the invention provide a mechanism for the NAF to inform a device of available protocols, port and/or security requirements in addition to the standard HTTP option. In addition, the NAF can inform the device of different security requirements for different resources that the NAF possesses. In one embodiment, the NAF can inform the device of available resources and/or protocols on a per user level.
In the standard GBA (as defined by 3GPP TS 33.220), upon successful authentication of a device, the NAF sends an “authentication successful” reply (e.g., a HTTP 200 OK message) to the device. Embodiments of the invention enable the NAF to embed additional information into this reply; e.g., about which security protocols and ports that the NAF supports. The device can parse this information and then choose a suitable protocol to continue the communication with the NAF. In one embodiment the device has a screen and a user input mechanism, such that the device can present the protocol options to the user and the user can determine which protocols to use. The mechanism described herein expands the protocol choice for the device to communicate with the NAF; without this mechanism, the device and the NAF can communicate in HTTP or HTTP based protocols only and no other protocols at all.
Embodiments of the invention add flexibility to the communication between the device and the NAF, and allow the NAF to secure multiple resources in different ways. For example, the NAF can, in the “authentication successful” reply to the device, include information about which security protocols and ports are supported. The NAF may provide this information for each supported resource if these resources have different security requirements. In addition, the NAT can learn from the response from the BSF about what rights the authenticated user has, and thus provide the user with a reply that gives an exact access control limit on a per user basis. The response from the BSF can also contain information about limitations and/or capabilities of the device's subscription (e.g., no CoAP), so that the NAF can reply with only valid options for the device.
The flexibility in protocol usage is especially beneficial for constrained devices that might not support HTTP at all. Constrained devices, such as machine-to-machine (M2M) devices, are constrained with respect to resources in that they typically have limited memory and power. Using the additional information in the “authentication successful” reply described herein, upon successful authentication the device can learn from the NAF which security protocols the NAF supports and can see if any of them matches what the device itself supports.
In the following description, the terms “user” and “subscriber” are used interchangeably to mean the person or entity that owns a subscription to a mobile communication service. The terms “reply” and “response” are also used interchangeably. Moreover, the term “user” herein refers to the user of a device where the device has a mobile subscription owned by the user. Therefore, as used herein, information that is specific to a device is also specific to a user, which in turn is also specific to a subscription.
In one embodiment, the device 110 includes a Universal Integrated Circuit Card (UICC); for example, a SIM card, that stores its 3GPP credentials (such as the identity and the related keys of a subscriber that uses the device 110). The device 110 may be a user equipment (“UE”, e.g., a cellular phone, a laptop computer), a constrained device (e.g., a sensor, an actuator, or any M2M device) or any mobile device that receives the mobile communication service from a mobile network operator. However, for the purpose of GBA, Internet Protocol (IP) connectivity such as Wi-Fi connection or other Internet access capabilities are sufficient for the device 110. The device 110 may, but is not required to, use 3GPP mobile network access for the purpose of GBA.
The HSS 140 is typically operated by a mobile network operator to store user profile information and subscription related information. The BSF 120 is an intermediate functional unit located between the HSS 140 and the device 110. The BSF 120 communicates with the HSS 140 over the Zh reference point. Using the 3GPP credentials of the device 110, the BSF 120 and the device 110 can mutually authenticate over the Ub reference point. The NAF 130 provides application services; e.g., Web services or any Internet accessible services. When the device 110 requests the NAF 130 for its application services, the NAF 130 in turn requests the BSF 120 over the Zn reference point for a shared secret (i.e., the key KsNAF, which is generated by the BSF 120 and the device 110). In addition to the key, the BSF 120 can also provide the NAF 130 with the User Security Settings (USS), if available. The USS is based on the information that the BSF 120 received from the HSS 140, and is specific to the user and the NAF 130. The NAF 130 uses the shared key to authenticate the device 110 over the Ua reference point. After the authentication, this key can be used for secure communication in many ways, as long as the NAF 130 and the device 110 can agree on how the key is used. For example, the key KsNAF can be used as a session key for establishing a secure communication session between the device 110 and the NAF 130. Moreover, for example, when using the Transport Layer Security (TLS) (as defined by 3GPP TS 33.222) with the key KsNAF, the key can be used as a pre-shared key (PSK) to secure the HTTP communication between the device 110 and the NAF 130.
After successfully authenticating the device 110, the NAF 130 sends a response to the device 110 over the Ua reference point to indicate the successful authentication. Embodiments of the invention allow the NAF 130 to provide information to the device 120 in addition to the indication of the successful authentication. For example, the information may contain one or more protocols supported by the NAF 130, including or in addition to the protocol that the device 110 and the NAF 130 have used for authenticating the device 110.
In response to the initial request, the NAF 130 replies with a HTTP 401 authentication request message, indicating that the device needs to he authenticated (step 220) The device 110 then mutually authenticates with the BSF 120 according to the AKA procedure (step 230), from Which the device 110 receives its B-TID. Using the device's 3GPP credentials and the NAF identifier (e.g., based on the FQDN), the device generates the NAF specific key (KsNAF). The device 110 calculates a digest using KsNAF and other information exchanged with the NAF 130 and the BSF 120, and sends a request message including the digest and the B-TID to the NAF 130 (step 240). In
Upon receiving the request message, the NAF 130 sends the B-TID and its own identifier (NAF-ID) to the BSF 120 (step 250). In response, the NAF 130 receives a time-limited NAF specific key (KsNAF), the key expiration time, the bootstrapping information creation time, and the USS, among other information (step 260). The NAF 130 and the device 110 now share a secret key, i.e., KsNAF. Using KsNAF, the NAF 130 can verify the digest. If the digest is verified, the NAF 130 knows that the device 110 has successfully authenticated with the BSF 120. Thus, the device 110 is successfully authenticated to the NAF 130.
Based on the USS from the BSF 120 and the policy of the NAF, the NAF 130 determines user-specific information, e.g., which resource(s) are available to the user and/or which protocol(s) are allowed to the user (step 270). The NAF 130 then sends a response (e.g., HTTP 200 OK message) to the device 110 indicating the successful authentication of the device 110, and, in addition, the response includes information such as supported protocols. In one embodiment, the NAF 130 may encode the additional information with KsNAF (step 280). The NAF 130 then sends the response to the device (step 290), which in this example specifically indicates a protocol and a port available to the user. The NAF 130 may indicate more than one supported protocol in the response. Thus, the device 110 may select one of the supported protocols for establishing a secure communication session with the NAF 130.
In steps 210 and 240 of
In alternative embodiments, the NAF 130 responds with the supported protocol information (and other available information if any) in the HTTP 200 OK message regardless of whether “GET/ app.protocol” is present in the device's request message in step 240. That is, the device's request message in step 240 may include no indication for any specific resource, and the NAF 130 will still respond with the supported protocol information in the HTTP 200 OK message. The device's request message in step 240 may alternatively include a request for an action on a specific resource different from “GET/ app.protocol,” and the NAF 130 will still respond with the supported protocol information in the HTTP 200 OK message. The supported protocol information may be added to the actual response to the device's request. For example, if the device's request is for index.html, then the NAF's response will include the content of index.html and the additional information such as supported protocols. The NAF 130 may encode the additional information portion of the response with KsNAF; the rest of the response is sent according to the GBA standard (i.e., not encoded with KsNAF). In these alternative embodiments, the device's initial request in step 210 may include a request for a specific resource, or may include no indication for any specific resource.
In step 270 of
In addition to the protocol/port information, the NAF 130 may also add into its response (e.g., the HTTP 200 OK message) one or more of the following, including but not limited to:
Crypto parameters for the given protocols, such as supported cipher suits. The cipher suits can play a role when the device 110 selects in what way it is to be connected to the NAF 130.
Per resource protocols. Some of the resources hosted by the NAF 130 may only accept specific protocols. For example, some resources may only accept HTTP/TLS while other resources may also accept CoAP/DTLS (Datagram TLS).
Per user information. The NAF 130 may provide only the resources that are available to this particular device 110 based on the information received in the USS from the BSF 120 and the policy of the NAF 130. The USS and the NAF policy may also limit which protocols that the device 110 is allowed to use towards this service.
Key KsNAF identifier. The NAF 130 may be requested to provide an application service to multiple devices, and may use a different KsNAF for each device. The NAF 130 can use an identifier to distinguish which device is initiating a connection to receive the application service, and which KsNAF is to be used for the connection. The B-TID may be used for identifying the key KsNAF. However, in some selected security protocols, the B-TID may not be suitable to be used (e.g., the B-TID may be too long). In one alternative embodiment, the NAF 130 can generate its own identifiers. This identifier can be sent to the device 110 in the authentication successful response, and can be used to identify the shared key when the device 110 establishes a new session based on the information it has learned from the NAF 130.
Once the device 110 receives the above-mentioned information embedded in the NAF's response, the device 110 can select, from the options presented, the most suitable way of communicating with and securing the communication to the NAF 130.
In step 290 of
In one embodiment, the USS received from the BSF 120 or a policy of the NAF 130 may indicate that the device 110 is prohibited from requesting for supported protocols. When the device 110 requests for supported protocols (e.g., by sending a request for the resource using “app.protocol”), the NAF 130 can reply with a HTTP 403 denied message. Alternatively, the NAF 130 can, instead of the list of supported protocols, embed a note indicating that the device 110 is not allowed to query this information.
It is noted that the messages exchanges in steps 210-230 of
The method 500 may be performed by hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions run on a processing device), or a combination thereof. In one embodiment, the method 500 may be performed by a network element 600 of
The operations of the diagrams of
It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reading and understanding the above description. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/IB2015/050256 | 1/13/2015 | WO | 00 |
