WO2020178046A1

WO2020178046A1 - User equipment-initiated request for type of authentication and key agreement exchange in a communication system

Info

Publication number: WO2020178046A1
Application number: PCT/EP2020/054606
Authority: WO
Inventors: Suresh Nair; Anja Jerichow; Nagendra S BYKAMPADI
Original assignee: Nokia Technologies Oy
Priority date: 2019-03-02
Filing date: 2020-02-21
Publication date: 2020-09-10

Abstract

Given user equipment receives an authentication request from a network entity of a communication network. In response to the authentication request, the given user equipment requests a type of authentication and key agreement exchange with the network entity, wherein the type of authentication and key agreement exchange comprises an authentication and key agreement exchange based on ephemeral keys that are generated specific to a given instance of the authentication and key agreement exchange.

Description

USER EQUIPMENT-INITIATED REQUEST FOR TYPE OF AUTHENTICATION AND KEY AGREEMENT EXCHANGE IN A COMMUNICATION SYSTEM

Field

The field relates generally to communication systems, and more particularly, but not exclusively, to authentication and key agreement operations within such systems.

Background

This section introduces aspects that may be helpful to facilitating a better understanding of the inventions. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

Fourth generation (4G) wireless mobile telecommunications technology, also known as Long Term Evolution (LTE) technology, was designed to provide high capacity mobile multimedia with high data rates particularly for human interaction. Next generation or fifth generation (5G) technology is intended to be used not only for human interaction, but also for machine type communications in so-called Internet of Things (IoT) networks.

While 5G networks are intended to enable massive IoT services (e.g., very large numbers of limited capacity devices) and mission-critical IoT services (e.g., requiring high reliability), improvements over legacy mobile communication services are supported in the form of enhanced mobile broadband (eMBB) services providing improved wireless Internet access for mobile devices.

In an example communication system, user equipment (5G UE in a 5G network or, more broadly, a UE) such as a mobile terminal (subscriber) communicates over an air interface with a base station or access point referred to as a gNB in a 5G network. The UE contains at least one Universal Subscriber Identity Module (USIM) and appropriate application software. The USIM securely stores the permanent subscription identifier and its related key, which are used to identify and authenticate subscribers to the 5G network. The access point (e.g., gNB) is illustratively part of an access network of the communication system. For example, in a 5G network, the access network is referred to as a 5G System and is described in 3GPP Technical Specification (TS) 23.501, V15.4.0, entitled“Technical Specification Group Services and System Aspects; System Architecture for the 5G System,” the disclosure of which is incorporated by reference herein in its entirety. In general, the access point (e.g., gNB) provides access for the UE to a core network (CN), which then provides access for the UE to other UEs and/or a data network such as a packet data network (e.g., Internet). Furthermore, 5G network access procedures are described in 3GPP Technical Specification (TS) 23.502, V15.4.1, entitled“Technical Specification Group Services and System Aspects; Procedures for the 5G System,” the disclosure of which is incorporated by reference herein in its entirety. Still further, 3GPP Technical Specification (TS) 33.501, V15.3.1, entitled“Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the 5G System,” the disclosure of which is incorporated by reference herein in its entirety, further describes security management details associated with a 5G network.

It is realized that a UE configured with a USIM with long term pre-shared secrets stored thereon may be susceptible to leakages wherein such secrets are compromised and used to maliciously access UE communications. However, effectively preventing such malicious attacks due to key leakages can present significant challenges.

Summary

Illustrative embodiments provide techniques for enabling user equipment to initiate a request for a type of authentication and key agreement exchange.

For example, in one illustrative embodiment, given user equipment receives an authentication request from a network entity of a communication network. In response to the authentication request, the given user equipment requests a type of authentication and key agreement exchange with the network entity, wherein the type of authentication and key agreement exchange comprises an authentication and key agreement exchange based on ephemeral keys that are generated specific to a given instance of the authentication and key agreement exchange.

Further illustrative embodiments are provided in the form of non-transitory computer-readable storage medium having embodied therein executable program code that when executed by a processor causes the processor to perform the above steps. Still further illustrative embodiments comprise apparatus with a processor and a memory configured to perform the above steps.

Advantageously, illustrative embodiments provide techniques for enabling given user equipment to initiate a request for a type of authentication with a communication network (e.g., 4G or 5G) using a short-lived cryptographic key pair (ephemeral key pair) that is generated in each instance of an authentication and key agreement exchange. In one or more illustrative embodiments, the type of authentication and key agreement exchange is EAP-AKA’ Perfect-Forward Secrecy (PFS). However, alternative embodiments encompass alternative types of authentication and key agreement exchange based on ephemeral keys that are generated specific to the given instance of the authentication and key agreement exchange.

These and other features and advantages of embodiments described herein will become more apparent from the accompanying drawings and the following detailed description.

Brief Description of the Drawings

FIG. 1 illustrates a communication system with which one or more illustrative embodiments may be implemented.

FIG. 2 illustrates user equipment and network element/functions for performing authentication procedures with which one or more illustrative embodiments may be implemented.

FIG. 3 illustrates a user equipment-initiated type of authentication and key agreement exchange, at the beginning of the process, according to an illustrative embodiment.

FIG. 4 illustrates a user equipment-initiated type of authentication and key agreement exchange wherein the user equipment indicates its preference during the negotiation phase of the process, according to another illustrative embodiment.

Detailed Description

Embodiments will be illustrated herein in conjunction with example communication systems and associated techniques for providing authentication and other procedures in communication systems. It should be understood, however, that the scope of the claims is not limited to particular types of communication systems and/or processes disclosed. Embodiments can be implemented in a wide variety of other types of communication systems, using alternative processes and operations. For example, although illustrated in the context of wireless cellular systems utilizing 3GPP system elements, the disclosed embodiments can be adapted in a straightforward manner to a variety of other types of communication systems.

In accordance with illustrative embodiments, one or more 3 GPP technical specifications (TS) and technical reports (TR) may provide further explanation of network elements/functions and/or operations that may interact with parts of the inventive solutions, e.g., the above-referenced 3 GPP TS 23.501, 23.502 and 33.501. Other 3 GPP TS/TR documents may provide other conventional details that one of ordinary skill in the art will realize. However, while well suited for 3 GPP standards, embodiments are not necessarily intended to be limited to any particular standards.

In existing 3GPP networks, authentication of the UE is based on a long term pre shared secret key (called K) that is part of the USIM and stored safely in the Universal Integrated Circuit Card (UICC) of the UE. There have been attacks reported recently about how these long-term key materials (pre-shared secrets) have been stolen from the UEs and made available to the general public.

One way to protect the session, even if long term key K has been leaked, is to have a key that is generated dynamically for every authentication run, i.e., a shared secret key that is short lived, and not used more than once between the UE and the mobile network. The shared secret key thus derived, provides so-called Perfect Forward Secrecy (PFS) for the session keys generated from it. PFS is described in the Network Working Group Internet- Draft (IETF RFC) entitled“Perfect-Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAR-AKA' PFS)” dated January 21, 2019 and identified as draft-arkko-eap-aka-pfs-04, and in 3 GPP SA3 Contribution S3- 190295, the disclosures of which are incorporated by reference herein in their entireties. However, in this existing approach, it is completely up to the network (Extensible Authentication Protocol (EAP) server) to decide on the usage of PFS. This network-initiated scheme has several drawbacks.

For example, if the UE subscription identity (International Mobile Subscriber Identity or IMSI) and corresponding long-term keys have been compromised, initiating the PFS is acknowledgement by the network that it is compromised.

Further, in the existing PFS proposal, the UE always has to depend on the serving (visited) network in conjunction with the home network to initiate this PFS and secure session, even if the long-term key has been compromised. On the contrary, it is realized herein that it is preferable if there is a mechanism for the UE to activate PFS (and disable authentication based on the compromised long-term key) when it is found to be compromised. In other words, it is realized herein that it is in the UE’s interest to protect its session by generating secure keys in every session, hence the UE should have the control.

Still further, in some roaming scenarios, a serving network may not have any interest to support the PFS scheme, hence the authenticator in the serving network may not initiate PFS even if the home network policy is to support PFS to the UE.

Yet further, the existing PFS protocol as proposed has some inconsistencies. For example, the server does not know whether the peer (UE) will support this PFS extension until it responds to the EAP-AKA Challenge with the PFS extension.

Illustrative embodiments provide improvements that enable the UE to initiate (or trigger) PFS. Prior to describing such illustrative embodiments, a general description of main components of a 4G and/or 5G network will be described below in the context of FIGS. 1 and 2.

FIG. 1 shows a communication system 100 within which illustrative embodiments are implemented. It is to be understood that the elements shown in communication system 100 are intended to represent main functionalities provided within the system, e.g., UE access functions, mobility management functions, authentication functions, serving gateway functions, etc. As such, while reference may be made to specific elements in 4G/5G networks that provide these main functions, other network elements may be used to implement some or all of the main functions represented. Also, it is to be understood that not all functionalities of a 4G or 5G network are depicted in FIG. 1. Rather, functions that facilitate an explanation of illustrative embodiments are represented. Subsequent figures may depict some additional elements/functions.

Accordingly, as shown, communication system 100 comprises user equipment (UE) 102 that communicates via an air interface 103 with an access point (eNB in 4G and gNB in 5G) 104. The UE 102 may be a mobile station, and such a mobile station may comprise, by way of example, a mobile telephone, a computer, or any other type of communication device. The term“user equipment” as used herein is therefore intended to be construed broadly, so as to encompass a variety of different types of mobile stations, subscriber stations or, more generally, communication devices, including examples such as a combination of a data card inserted in a laptop or other equipment such as a smart phone. Such communication devices are also intended to encompass devices commonly referred to as access terminals.

In one embodiment, UE 102 is comprised of a Universal Integrated Circuit Card (UICC) part and a Mobile Equipment (ME) part. The UICC is the user-dependent part of the UE and contains at least one Universal Subscriber Identity Module (USIM 105) and appropriate application software. The USIM 105 (as illustrated in FIG. 1 as part of UE 102) securely stores the permanent subscription identifier and its related key, which are used to identify and authenticate subscribers to access networks. The ME is the user-independent part of the UE and contains terminal equipment (TE) functions and various mobile termination (MT) functions.

The access point 104 is illustratively part of an access network of the communication system 100. Such an access network may comprise, for example, a 4G or 5G architecture having a plurality of base stations and one or more associated radio network control functions. The base stations and radio network control functions may be logically separate entities, but in a given embodiment may be implemented in the same physical network element, such as, for example, a base station router or femto cellular access point.

The access point 104 in this illustrative embodiment is operatively coupled to one or more serving (visited) network entities/functions 106. The serving or visited network may be a visited public land mobile network (VPLMN) to which the UE roams when leaving its home public land mobile network (HPLMN). In a 5G network, examples of such network entities/functions 106 comprise, but are not limited to, an Access and Mobility Management Function (AMF). A Security Anchor Function (SEAF) can also be implemented with the AMF connecting a UE with the mobility management function. Further, in 5G, some of these entities/functions comprise the Unified Data Management (UDM) function, as well as an Authentication Server Function (AUSF). In 4G, the home subscriber server (HSS) performs the functions of the UDM and AUSF, while mobility management is provided by a Mobility Management Entity (MME).

The one or more serving (visited) network entities/functions 106 in this illustrative embodiment are operatively coupled to home network entities/functions 108, i.e., one or more entities/functions that are resident in the home network of the subscriber (HPLMN). The same types of entities/functions that are in the VPLMN are present in the HPLMN (e.g., in 5G, AMF/SEAF/UDM/AUSF etc., and in 4G, MME/HSS etc ).

The access point 104 is also operatively coupled to a serving gateway/function 110, e.g., Session Management Function (SMF) in 5G and Serving Gateway (SGW) in 4G, which is operatively coupled to data network gateway/function 112, e.g., a User Plane Function (UPF) in 5G and Packet Gateway (PGW) in 4G. Data network gateway/function 112 is operatively coupled to a Data Network 114, e.g., Internet. Further typical operations and functions of such network elements are not described here since they are not the focus of the illustrative embodiments and may be found in appropriate 3GPP 5G documentation.

It is to be appreciated that this particular arrangement of system elements is an example only, and other types and arrangements of additional or alternative elements can be used to implement a communication system in other embodiments. For example, in other embodiments, the system 100 may comprise other elements/functions not expressly shown herein.

Accordingly, the FIG. 1 arrangement is just one example configuration of a wireless cellular system, and numerous alternative configurations of system elements may be used. For example, although only single elements/functions are shown in the FIG. 1 embodiment, this is for simplicity and clarity of description only. A given alternative embodiment may of course comprise larger numbers of such system elements, as well as additional or alternative elements of a type commonly associated with conventional system implementations.

FIG. 2 is a block diagram of user equipment and network entities/functions for providing security functionalities (e.g., PFS authentication) in an illustrative embodiment. System 200 is shown comprising user equipment (UE) 202, a network entity/function 204 and a network entity/function 206. For example, in illustrative embodiments and with reference back to FIG. 1, UE 202 can represent UE 102, while network entity/functions 204 and 206 can represent home network entities/functions 108. By way of further example, assuming that a form of Extensible Authentication Protocol (EAP) is implemented, network entity/function 204 represents an EAP Server and network entity/function 206 represents an HSS. UE 202 therefore would represent a Peer in EAP. As will be further explained herein, in accordance with further illustrative embodiments, UE 202 and the network entities/functions 204 and 206 are configured to provide PFS authentication and key agreement exchange and other techniques described herein.

The user equipment 202 comprises a processor 212 coupled to a memory 216 and interface circuitry 210. A processor may also be referred to herein as a processing core. The processor 212 of the user equipment 202 comprises a security processing module 214 that may be implemented at least in part in the form of software executed by the processor. The processing module 214 performs PFS authentication and key agreement exchange operations described in conjunction with subsequent figures and otherwise herein. The memory 216 of the user equipment 202 comprises a security storage module 218 that stores data generated or otherwise used during PFS authentication and key agreement exchange operations.

The network entity/function 204 comprises a processor 222 coupled to a memory 226 and interface circuitry 220. The processor 222 of network entity/function 204 comprises a security processing module 224 that may be implemented at least in part in the form of software executed by the processor 222. The processing module 224 performs PFS authentication and key agreement exchange operations described in conjunction with subsequent figures and otherwise herein. The memory 226 of network entity/function 204 comprises a security storage module 228 that stores data generated or otherwise used during PFS authentication and key agreement exchange operations.

The network entity/function 206 comprises a processor 232 coupled to a memory 236 and interface circuitry 230. The processor 232 of network entity/function 206 comprises a security processing module 234 that may be implemented at least in part in the form of software executed by the processor 232. The processing module 234 performs PFS authentication and key agreement exchange operations described in conjunction with subsequent figures and otherwise herein. The memory 236 of network entity/function 206 comprises a security storage module 238 that stores data generated or otherwise used during PFS authentication and key agreement exchange operations. The processors 212, 222, and 232 of the respective user equipment 202 and network entities/functions 204 and 206 may comprise, for example, microprocessors, application- specific integrated circuits (ASICs), digital signal processors (DSPs) or other types of processing devices, as well as portions or combinations of such elements.

The memories 216, 226, and 236 of the respective user equipment 202 and network entities/functions 204 and 206 may be used to store one or more software programs that are executed by the respective processors 212, 222, and 232 to implement at least a portion of the functionality described herein. For example, PFS authentication and key agreement exchange operations and other functionality as described in conjunction with subsequent figures and otherwise herein may be implemented in a straightforward manner using software code executed by processors 212, 222, and 232. Executable code may also be referred to herein as computer program code.

A given one of the memories 216, 226, or 236 may therefore be viewed as an example of what is more generally referred to herein as a computer program product or still more generally as a processor-readable storage medium that has executable program code (e.g., computer program code) embodied therein. Other examples of processor-readable storage media may include disks or other types of magnetic or optical media, in any combination. Illustrative embodiments can include articles of manufacture comprising such computer program products or other processor-readable storage media.

The memory 216, 226, or 236 may comprise, for example, an electronic random- access memory (RAM) such as static RAM (SRAM), dynamic RAM (DRAM) or other types of volatile or non-volatile electronic memory. The latter may comprise, for example, non volatile memories such as flash memory, magnetic RAM (MRAM), phase-change RAM (PC-RAM) or ferroelectric RAM (FRAM). The term“memory” as used herein is intended to be broadly construed, and may additionally or alternatively encompass, for example, a read-only memory (ROM), a disk-based memory, or other type of storage device, as well as portions or combinations of such devices.

The interface circuitries 210, 220, and 230 of the respective user equipment and network entities/functions 202, 204, and 206 illustratively comprise transceivers or other communication hardware or firmware that allows the associated system elements to communicate with one another in the manner described herein. It is apparent from FIG. 2 that user equipment 202 and the network entities/functions 204 and 206 are configured for communication with each other via their respective interface circuitries 210, 220, and 230. This communication involves user equipment 202 sending data to and receiving data from network entity/function 204, and network entity/function 204 sending data to and receiving data from network entity/function 206. However, in alternative embodiments, other network entities/functions (more generally, elements) may be operatively coupled between or to the user equipment 202 and/or network entities/functions 204 and 206. The term“data” as used herein is intended to be construed broadly, so as to encompass any type of information that may be sent between network entities/functions, as well as between user equipment and such network entities/functions, including, but not limited to, identity data, key pairs, key indicators, registration request/response messages and data, authentication request/response messages and data, control data, audio, video, multimedia, other messages, etc.

It is to be appreciated that the particular arrangement of components shown in FIG. 2 is an example only, and numerous alternative configurations may be used in other embodiments. For example, any given network entity/function can be configured to incorporate additional or alternative components and to support other communication protocols.

Other 4G or 5G system elements may each be configured to comprise components such as a processor, memory and network interface. These elements need not be implemented on separate stand-alone processing platforms, but could instead, for example, represent different functional portions of a single common processing platform.

Given the general concepts described above, illustrative embodiments that address scenarios wherein a UE initiates PFS type authentication and key agreement will now be described.

Note that as used herein, the term ephemeral key is a short-lived cryptographic key that is generated in every key exchange, while the term EAP-AKA’ PFS is used to indicate that ephemeral keys are used during EAP-AKA’ instead of a static key. Note that EAP- AKA’ is an authentication and key agreement protocol defined in the above-referenced 3 GPP TS 33.501 standard.

The problem of how a UE and the mobile network can generate a dynamic shared secret key that can be used for the authentication of the UE and generate session keys for protecting over the air traffic between the UE and the network can be solved in different ways. Illustrative embodiments provide that, whichever way authentication and session key generation are performed such as, e.g., PFS, the UE is configured to request PFS and therefore initiate the PFS process. In existing PFS, the network initiates the PFS process.

For example, in illustrative embodiments:

1. PFS based EAP-AKA’ authentication is initiated by the UE (i.e., the UE is configured to request that type of authentication and key agreement exchange).

2. The home network responds to the request for PFS by triggering EAP-AKA’ PFS instead of the regular static key based EAP-AKA’. This way, UE’s interest to protect its session keys is better accounted for and the UE is in control.

In PFS based EAP-AKA’ authentication is initiated by the UE, illustrative embodiments cover implementations where:

a) UE simply includes the list of curves it supports. The network selects an Elliptic Curve Diffie-Hellman Key Exchange (ECDHE) curve and executes EAP-AKA’ PFS.

b) UE decides on the curve, generates the ephemeral key pair, and shares its ephemeral public key when it initiates PFS.

Advantageously, in accordance with illustrative embodiments, the UE has a mechanism to trigger EAP-AKA’ PFS when it needs to or is otherwise beneficial to do so.

There are two main parts to this UE-initiated PFS process:

Part 1 : The UE initiates EAP-AKA’ PFS

The trigger for EAP-AKA’ PFS comes from the UE.

In FIG. 3, as will be further explained, UE (referred to as“Peer” and“USIM” in FIG. 3) triggers PFS by sending a UE-selected elliptic curve, the generated ephemeral public key and other PFS parameters required for ECDHE to be executed between the UE and the network. Note that the Peer with USIM in FIG. 3 corresponds to UE 102 with USIM 105 in FIG. 1 (as well as UE 202 in FIG. 2).

Part 2: The network responds with the EAP-AKA’ PFS instead of EAP-AKA’

The network (called “Server” in FIG. 3) responds with an EAP-AKA’ PFS authentication instead of the regular EAP-AKA’ based authentication. Note that the Server in FIG. 3 corresponds to an EAP server in the HPLMN of the UE. Note that the“HSS” in FIG. 3 is also in the HPLMN of the UE. Note that while not expressly shown, an EAP authenticator can be present in a visited network (e.g., SEAF in the VPLMN) which acts as a pass-through function between the UE and EAP server.

As shown in FIG. 3, the network may decide to still obtain EAP -AKA’ parameters from the HSS. But illustrative embodiments provide that if the network is capable of supporting EAP -AKA’ PFS, it gives precedence to PFS over the regular EAP -AKA’ mechanism and only sends PFS parameters.

More particularly, as shown in EAP -AKA’ PFS authentication process 300 in FIG. 3, following message 1 (EAP-Req/Identity), Peer decides and indicates that it wants PFS. It generates an ephemeral key pair, sends the public key of that key pair in the EAP identity Response message (message 2) to the Server. In the message, the AT PUB ECDHE attribute carries the public key and the AT KDF PFS attribute carries other PFS related parameters. Both of these are skippable attributes that can be ignored if the Server does not support this extension.

Server now has an identity for the Peer, along with the request for PFS. If the Server decides to respond with EAP -AKA’ PFS, it skips going to the HSS for EAP -AKA’ parameters. Otherwise, as shown in FIG. 3, the Server asks the assistance of the HSS to run AKA’ algorithms generating RAND, AUTN, XRES, CK, IK. Typically, the HSS performs the first part of key derivations so that the Server gets the CK' and IK' keys already tied to a particular network name.

Server now has the needed authentication vector. If the Server supports PFS, it generates an ephemeral key pair, sends the public key of that key pair and the first EAP method message to the Peer (message 3 : EAP -Req/ AKA’ -Challenge). In message 3, the AT PUB ECDHE attribute carries the public key.

The Peer calculates a shared key based on its own key pair and Server’s public key. Finally, the Peer proceeds to derive all EAP -AKA’ keys and constructs a response (message 4: EAP -Resp/ AKA’ -Challenge). The session keys are used to generate AT_MAC. MAC refers to message authentication code as defined in 3GPP RFC 4187, the disclosure of which is incorporated by reference herein in its entirety.

The Server now has all the necessary values and generates the ECDHE shared secret and derives all EAP -AKA’ keys. The Server checks MAC values received in AT_MAC, and responds when the check is successful (message 5: EAP-Success).

In another embodiment as shown in EAP-AKA’ PFS authentication process 400 in FIG. 4, wherein steps and messages are the same as in FIG. 3 with the following exceptions, the Peer simply sends a trigger in message 2 for EAP-AKA’ PFS with a list of elliptic curves it supports.

If the Server supports PFS, it generates an ephemeral key pair, sends the public key of that key pair and the first EAP method message to the Peer (message 3). In message 3, the AT PUB ECDHE attribute carries the public key, and the AT KDF PFS attribute carries other PFS-related parameters including the selected curve.

More particularly, process 400 in FIG. 4 is an embodiment wherein the UE (referred to as“Peer” and“USIM” in FIG. 4) triggers PFS by sending a key derivation attribute AT KDF PFS along with its identity. Further PFS parameters, the selected elliptic curve, the generated ephemeral public key and other PFS parameters required for ECDHE to be executed between the UE and the network are negotiated once the request is accepted by the network during the EAP Challenge/Response phase. Except for the negotiation initiation and the parameter exchange, the key computation procedure for PFS is same in the FIG. 3 and FIG. 4 embodiments.

It should therefore again be emphasized that the various embodiments described herein are presented by way of illustrative example only and should not be construed as limiting the scope of the claims. For example, alternative embodiments can utilize different communication system configurations, user equipment configurations, base station configurations, key pair provisioning and usage processes, messaging protocols and message formats than those described above in the context of the illustrative embodiments. These and numerous other alternative embodiments within the scope of the appended claims will be readily apparent to those skilled in the art.

Claims

Claims What is claimed is:

1. A method comprising:

in given user equipment;

receiving an authentication request from a network element of a communication network; and

in response to the authentication request, requesting a type of authentication and key agreement exchange with the network element, wherein the type of authentication and key agreement exchange comprises an authentication and key agreement exchange based on ephemeral keys that are generated specific to a given instance of the authentication and key agreement exchange;

wherein the given user equipment comprises a processor and memory configured to execute the above steps.

2. The method of claim 1, wherein the requesting step further comprises the given user equipment sending a message to the network element identifying one or more attributes that the given user equipment supports, wherein the one or more attributes comprise one or more attributes of the authentication and key agreement exchange.

3. The method of claim 2, wherein the one or more attributes comprise elliptic curves supported by the given user equipment.

4. The method of claim 3, further comprising participating in the authentication and key agreement exchange with the network element and, upon successful authentication, the given user equipment generates a set of keys to enable the given user equipment to access the communication network.

5. The method of claim 4, wherein the participating step further comprises the given user equipment receiving from the network element a public key of an ephemeral key pair and an identification of a network element-selected curve of the elliptic curves supported by the given user equipment.

6. The method of claim 5, wherein the participating step further comprises the given user equipment calculating a shared key based on the public key received from the network element and an ephemeral key pair generated by the given user equipment based on the selected curve.

7. The method of claim 6, wherein the participating step further comprises the given user equipment deriving the set of keys from the shared key to enable the given user equipment to access the communication network.

8. The method of claim 6, wherein the participating step further comprises the given user equipment sending a message to the network element comprising a message authentication code and a public key of the ephemeral key pair generated by the given user equipment.

9. The method of claim 1, wherein the requesting step further comprises the given user equipment sending a message to the network element containing a public key of an ephemeral key pair generated by the given user equipment based on a user equipment- selected curve supported by the given user equipment and one or more other attributes.

10. The method of claim 9, further comprising participating in the authentication and key agreement exchange with the network element and, upon successful authentication, the given user equipment generates a set of keys to enable the given user equipment to access the communication network.

11. The method of claim 10, wherein the participating step further comprises the given user equipment receiving from the network element a public key of an ephemeral key pair.

12. The method of claim 11, wherein the participating step further comprises the given user equipment calculating a shared key based on the public key received from the network element and the ephemeral key pair generated by the given user equipment.

13. The method of claim 12, wherein the participating step further comprises the given user equipment deriving the set of keys from the shared key to enable the given user equipment to access the communication network.

14. The method of claim 12, wherein the participating step further comprises the given user equipment sending a message to the network element comprising a message authentication code.

15. An article of manufacture comprising a non-transitory computer-readable storage medium having embodied therein executable program code that when executed by the processor causes the processor to performs the steps of claim 1.

16. An apparatus comprising:

at least one processing core;

at least one memory including computer program code;

the at least one memory and the computer program code being configured to, with the at least one processing core, cause the apparatus at least to:

receive an authentication request from a network element of a communication network; and

in response to the authentication request, request a type of authentication and key agreement exchange with the network element, wherein the type of authentication and key agreement exchange comprises an authentication and key agreement exchange based on ephemeral keys that are generated specific to a given instance of the authentication and key agreement exchange.

17. The apparatus of claim 16, wherein the requesting operation further comprises the apparatus sending a message to the network element identifying one or more attributes that the apparatus supports, wherein the one or more attributes comprise one or more attributes of the authentication and key agreement exchange.

18. The apparatus of claim 17, wherein the one or more attributes comprise elliptic curves supported by the apparatus.

19. The apparatus of claim 16, wherein the requesting operation further comprises the apparatus sending a message to the network element containing a public key of an ephemeral key pair generated by the apparatus based on an apparatus-selected curve supported by the apparatus and one or more other attributes.

20. A method comprising:

in a network element of a communication network;

sending an authentication request to given user equipment; and

in response to the authentication request, receiving a request from the given user equipment for a type of authentication and key agreement exchange with the given user equipment, wherein the type of authentication and key agreement exchange comprises an authentication and key agreement exchange based on ephemeral keys that are generated specific to a given instance of the authentication and key agreement exchange;

wherein the network element comprises a processor and memory configured to execute the above steps.

21. The method of claim 20, further comprising the network element deciding whether or not to perform the requested type of authentication and key agreement exchange with the given user equipment.

22. The method of claim 20, wherein the request receiving step further comprises the network element receiving a message from the given user equipment identifying one or more attributes that the given user equipment supports, wherein the one or more attributes comprise one or more attributes of the authentication and key agreement exchange.

23. The method of claim 22, wherein the one or more attributes comprise elliptic curves supported by the given user equipment.

24. The method of claim 20, wherein the request receiving step further comprises the network element receiving a message from the given user equipment containing a public key of an ephemeral key pair generated by the given user equipment based on a user equipment-selected curve supported by the given user equipment and one or more other attributes.

25. The method of claim 20, further comprising participating in the authentication and key agreement exchange with the given user equipment and, upon successful authentication, the network element generates a set of keys to enable secure communications with the given user equipment.

26. An article of manufacture comprising a non-transitory computer-readable storage medium having embodied therein executable program code that when executed by the processor causes the processor to performs the steps of claim 20.

27. An apparatus comprising:

at least one processing core;

at least one memory including computer program code;

send an authentication request to given user equipment; and

in response to the authentication request, receive a request from the given user equipment for a type of authentication and key agreement exchange with the given user equipment, wherein the type of authentication and key agreement exchange comprises an authentication and key agreement exchange based on ephemeral keys that are generated specific to a given instance of the authentication and key agreement exchange.

28. The apparatus of claim 27, wherein the apparatus is further configured to decide whether or not to perform the requested type of authentication and key agreement exchange with the given user equipment.