|
(11) | EP 2 258 126 B9 |
| (12) | CORRECTED EUROPEAN PATENT SPECIFICATION |
| Note: Bibliography reflects the latest situation |
|
|
| (54) |
SECURITY FOR A NON-3GPP ACCESS TO AN EVOLVED PACKET SYSTEM SICHERHEIT FÜR EINEN NICHT-3GPP-ZUGANG ZU EINEM ENTWICKELTEN PAKETSYSTEM SÉCURITÉ POUR UN ACCÈS NON 3GPP À UN SYSTÈME PAR PAQUETS ÉVOLUÉ |
|
|
||||||||||||||||||||||||||||
| Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention). |
FIELD OF THE INVENTION
[0001] The present invention relates to security for an Evolved Packet System (EPS). In particular, the invention relates to security for EPS when it is accessed from a non-3GPP (non- Third Generation Partnership Project) access network.
BACKGROUND OF THE INVENTION
[0002] EPS is a successor technology of UMTS (Universal Mobile Telecommunications System). Security aspects of EPS depend on whether an access network is a 3GPP-defined access network, e.g. GERAN (GSM (Global System for Mobile communication) EDGE (Enhanced Data rates for Global Evolution) Radio Access Network), UTRAN (UMTS Terrestrial Radio Access Network), E-UTRAN (evolved UTRAN), or a non-3GPP access network, e.g. evolved HRPD (High Rate Packet Data) as defined by 3GPP2 (Third Generation Partnership Project 2), WiMAX (Worldwide Interoperability for Microwave Access) as defined by IEEE (Institute of Electrical and Electronic Engineers) and the WiMAX Forum.
[0003] In case the access network is E-UTRAN (also known as LTE (Long Term Evolution)), i.e. a 3GPP-defined access network, a serving network authentication means that a User Equipment (UE) is ensured to communicate with a Mobility Management Entity (MME) in a particular serving network. This is a security feature not known in UMTS.
[0004] In order to prevent that this security feature is circumvented by an attacker an additional feature called cryptographic network separation is required. In the following, some more background information is given so that this additional feature can be explained.
[0005] In UMTS and in EPS alike, an authentication vector is a collection of parameters, which contains, among others, cryptographic keys CK, IK and a so-called AMF (Authentication Management Field) separation bit. When an attacker knows the keys CK, IK he can impersonate a serving network entity. The keys CK, IK are available in UMTS serving networks in entities SGSN (Serving GPRS (General Packet Radio Service) Support Node) and RNC (Radio Network Controller). Therefore, any compromise of an SGSN or RNC in one UMTS serving network allows an attacker to impersonate another UMTS serving network entity.
[0006] EPS users are equipped with a UICC (UMTS Integrated Circuit Card) with a USIM (User Services Identity Module) application for security purposes. User records are held in an HSS (Home Subscriber Server).
[0007] Cryptographic network separation of user's security data as specified for EPS rests on the particular handling of the Authentication Management Field (AMF), which is part of the AV (Authentication Vector), in the HSS and a Mobile Equipment (ME). The ME is a User Equipment (UE) without the UICC.
[0008] Security procedures between UE and EPC (Evolved Packet Core) network elements comprising ASME (Access Security Management Entity) and HSS including Authentication Centre, comprise an Authentication and key agreement procedure (AKA). The EPS AKA produces keys forming a basis for user plane and control plane protection (ciphering, integrity). EPS AKA is based on following long term keys shared between UE and HSS:
- K is the permanent key stored on the USIM (User Services Identity Module) and in the Authentication Centre AuC;
- CK, IK is the pair of keys derived in the AuC and on the USIM during an AKA run.
[0009] As a result of the authentication and key agreement, an intermediate key K_ASME is generated which is shared between UE and ASME. For E-UTRAN access networks, the ASME is the MME.
[0010] The purpose of this procedure is to provide an MME (Mobility Management Entity) with one or more MME security contexts (e.g. K_ASME) including a fresh authentication vector from the user's HSS to perform a number of user authentications.
[0011] An MME security context is derived from the authentication vector. To derive the key K_ASME in the HSS, a Key Derivation Function is used which contains input parameters CK, IK and SN (serving network) identity.
[0012] EPS introduces cryptographic network separation for the case of E-UTRAN access networks by using the AMF separation bit. This feature makes it impossible for an attacker to steal keys CK, IK from an entity in one serving network, with either UTRAN or E-UTRAN access networks, and use them to impersonate another serving network when the UE is using E-UTRAN access. This feature ensures by cryptographic means that a security breach in one network does not affect another network, hence the name "cryptographic network separation".
[0013] In the context of E-UTRAN access to EPS, cryptographic network separation is achieved in the following way:
- a Home Subscriber Server (HSS) uses only authentication vectors with AMF separation bit = 1 for E-UTRAN access networks;
- the Home Subscriber Server (HSS) uses only authentication vectors with AMF separation bit = 0 for UTRAN access networks;
- when an access is made via E-UTRAN, the HSS does not send CK, IK to another entity outside the HSS, but sends a key derived from CK, IK and a serving network identity to the MME in the serving network; and
- a UE accepts only authentication vectors with AMF separation bit = 1 for E-UTRAN access networks.
[0014] In the context of non-3GPP access networks, for subscriber authentication, a protocol EAP-AKA (Extensible Authentication Protocol for Authentication and Key Agreement) is used. EAP-AKA is terminated in a 3GPP AAA (Access, Authorization, and Accounting) server, which always resides in a home network. The 3GPP AAA server obtains the keys CK, IK from an HSS (Home Subscriber Server). The keys CK, IK then remain in the 3GPP AAA server, which resides in the home network. Therefore, stealing of CK, IK is not the problem here. However, the 3GPP AAA server produces a Master Session Key (MSK) from CK, IK and then sends the MSK to an authenticator which is an entity controlling an access from a user equipment. In the context of non-3GPP access to EPS, the authenticator can be an entity in a non-3GPP access network in the case of so-called trusted access, or the authenticator can be an evolved Packet Data Gateway (ePDG) in a 3GPP EPS network in the case of so-called untrusted access.
[0015] The problem is that the authenticator may be compromised and may use the MSK to impersonate another authenticator in a different network. E.g. a WLAN (Wireless Local Area Network) access point from a 3G-WLAN interworking system may obtain an MSK, and then impersonate an ePDG in an EPS network or an authenticator in an eHRPD network. This would make the security of an EPS network dependent on that of the WLAN access point. But the latter may enjoy quite low physical security and may reside in an exposed location. Furthermore, the backhaul link from this WLAN access point may be weakly protected. This dependency of EPS security on WLAN security is therefore highly undesirable.
[0016] In the 3GPP TR33821 v0.7.03 (2008-02), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Rationale and track of security decisions in Long Term Evolved (LTE) RAN /3GPP System Architecture Evolution (SAE) (Release 8), February 29, 2008, XP050435836, a security technology is described that allows a terminal to verify whether it is connected to an Evolved Packet Core (EPC) by using a separation bit in the authentication data. This feature is called 'SAE binding'. In particular, a security technology for accessing the EPC via an E-UTRAN access network is described.
SUMMARY OF THE INVENTION
[0017] Apparatuses and methods are provided for solving the above problem, which are defined in the appended claims. An embodiment of the invention may also be implemented by a computer program product.
[0018] According to an embodiment of the invention, in the context of non-3GPP access to EPS an attacker can be prevented from impersonating an authenticator by compromising another authenticator in a different network. In other words, cryptographic separation of authenticators, and cryptographic separation of networks in which the authenticators reside can be provided in the context of non-3GPP access to EPS.
[0019] According to an embodiment of the invention, the EAP-AKA protocol does not have to be changed, and no protocol changes on the authenticators are required.
BRIEF DESCRIPTION OF THE DRAWINGS
[0020]
Fig. 1 shows a signalling diagram illustrating authentication and key agreement for trusted access according to an embodiment of the invention.
Fig. 2 shows a signalling diagram illustrating authentication and key agreement for untrusted access according to an embodiment of the invention.
Fig. 3 shows a schematic block diagram illustrating a structure of a user equipment, an authenticator, an authentication server and a home subscriber server according to an embodiment of the invention.
DESCRIPTION OF EMBODIMENTS OF THE INVENTION
[0021] In the following the invention will be described by way of embodiments thereof referring to the accompanying drawings which form part of the specification.
[0022] For the purpose of an embodiment of the invention to be described herein below, it should be noted that
- a user equipment may for example be any device by means of which a user may access a communication network; this implies mobile as well as non-mobile devices and networks, independent of the technology platform on which they are based; only as an example, it is noted that terminals equipped with a UICC (UMTS (Universal Mobile Telecommunications System) Integrated Circuit Card) with a USIM (User Services Identity Module) application for security purposes are particularly suitable for being used in connection with the present invention;
- method steps likely to be implemented as software code portions and being run using a processor at one of the entities are software code independent and can be specified using any known or future developed programming language;
- method steps and/or devices likely to be implemented as hardware components at one of the entities are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS, CMOS, BiCMOS, ECL, TTL, etc, using for example ASIC components or DSP components, as an example;
- generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the present invention;
- devices can be implemented as individual devices, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved.
[0023] As described above, in the context of non-3GPP access networks, for subscriber authentication, the protocol EAP-AKA is used. EAP-AKA is terminated in an AAA server (3GPP AAA server), which, in the context of 3GPP networks, always resides in the home network. The 3GPP AAA server obtains the keys CK, IK from an HSS. The keys CK, IK then remain in the 3GPP AAA server, which resides in the home network. The 3GPP AAA server produces a Master Session Key (MSK) from CK, IK and then sends the MSK to an authenticator which is an entity controlling an access from a user equipment (UE). In the context of non-3GPP access to EPS, the authenticator can be an entity in a non-3GPP access network in the case of so-called trusted access, or the authenticator can be an evolved Packet Data Gateway (ePDG) in a 3GPP EPS network in the case of so-called untrusted access.
[0024] According to an embodiment of the invention, the HSS does not send the keys CK, IK to the AAA server, but applies a transformation to obtain keys CK_new, IK_new. The UE applies the same transformation to the keys CK, IK obtained from USIM (UMTS Subscriber Identity Module). The AAA server, an EAP peer on the UE, and the authenticator do not notice this transformation and proceed with EAP-AKA. Moreover, the use of the AMF separation bit is as for E-UTRAN access in so far as the HSS sends authentication vectors with the AMF separation bit set to 1 only to AAA servers when they are used for EPS access, and the UE checks that the AMF separation bit is set to 1 when the UE accesses EPS.
[0025] In order to achieve authentication of the authenticator or the serving network to the UE, according to an embodiment of the invention the transformation applied by the HSS and the UE includes a meaningful authenticator or serving network identity, e.g. a Fully Qualified Domain Name of an ePDG, or a Mobile Country Code (MCC) plus Mobile Network Code (MNC) identifying an eHPRD network. The UE and the HSS have the identity in the same form available.
[0026] MSK keys derived from CK, IK and from CK_new, IK_new respectively are different. Therefore, e.g. a WLAN access point stealing an MSK derived from CK, IK cannot use this MSK for impersonating an authenticator in the EPS context, as for the latter MSK would have to be derived from CK_new, IK_new.
[0027] In the following an implementation example will be described by referring to Figs. 1 and 2.
Fig. 1 shows a signalling diagram illustrating authentication and key agreement for trusted access to EPS from a non-3GPP access network according to an embodiment of the invention.
Fig. 2 shows a signalling diagram illustrating authentication and key agreement for untrusted access according to an embodiment of the invention.
[0028] According to an embodiment of the invention, access authentication for non-3GPP access in EPS is based on EAP-AKA. An AAA server 30 (3GPP AAA server), which resides in an EPC, may act as an EAP server for EAP-AKA.
[0029] According to the embodiment, it is assumed that an HSS 40 sends an authentication vector with AMF separation bit = 1 to the AAA server 30 if and only if the authentication vector is used with the procedures defined in the embodiment.
[0030] According to an embodiment of the invention, the procedure shown in Fig. 1 is performed whenever the procedure shown in Fig. 2 is not performed.
[0031] As shown in Fig. 1, in step S101 a connection is established between a UE 10 and a trusted non-3GPP access network, using a procedure specific to the non-3GPP access network.
[0032] In step S102, an authenticator 20 in the trusted non-3GPP access network sends an EAP Request/Identity to the UE 10, requesting a user identity. In step S103 the UE 10 sends an EAP Response/Identity message. The UE 10 may send its identity complying with Network Access Identifier (NAI) format. NAI contains either a pseudonym allocated to the UE 10 in a previous run of the authentication procedure or, in the case of first authentication, an IMSI (International Mobile Subscriber Identity). In the case of first authentication, the NAI indicates EAP-AKA.
[0033] In step S104 the EAP Response/Identity message is routed towards the AAA server 30 based on a realm part of the NAI. The routing path may include one or several AAA proxies (not shown in Fig. 1). In step S105 the AAA server 30 receives the EAP Response/Identity message that contains the subscriber identity over a Ta*/ Wd* interface (not shown).
[0034] In step S106 the AAA server 30 checks whether it has an unused authentication vector with AMF separation bit = 1 available for that subscriber, i.e. the UE 10. If not, a set of new authentication vectors is retrieved from the HSS 40 in step S106. For this purpose, the AAA server 30 includes an indication that the authentication vector is for EPS use, and the identity of the access network in which the authenticator 20 resides, e.g. MCC+MNC of an eHRPD access network, into a message sent to the HSS 40 in step S106. A mapping from a temporary identifier to an IMSI is required. The HSS 40 retrieves an authentication vector from an Authentication Centre (not shown) with AMF separation bit = 1. The HSS 40 then transforms this authentication vector into a new authentication vector by computing (CK_new, IK_new) = F(CK, IK, <access network identity>, <possibly further parameters>) where F is a key derivation function. The HSS 40 then sends this transformed authentication vector to the AAA server 30 in step S106.
[0035] It is to be noted that the AAA server 30 does not notice the transformation and treats this authentication vector like any other authentication vector.
[0036] In addition, the AAA server 30 may retrieve authentication vectors from the HSS 40 when it detects that a VPLMN (Visited Public Land Mobile Network) selected by a user of the UE 10 has changed. This may happen, for example, when the user is performing a VPLMN re-selection procedure and is initiating a new authentication procedure via a new VPLMN.
[0037] The HSS 40 may check if there is a 3GPP AAA Server already registered to serve for this subscriber, i.e. the UE 10. In case the HSS 40 detects that another AAA Server has already registered for this subscriber, it may provide the AAA server 30 with the previously registered AAA server address. The authentication signalling is then routed to the previously registered AAA server with Diameter-specific mechanisms, e.g., the AAA server 30 transfers the previously registered AAA server address to a 3GPP AAA proxy or an AAA entity in the trusted non-3GPP access network, or the AAA server 30 acts as an AAA proxy and forwards the authentication message to the previously registered AAA server.
[0038] In step S107, the AAA server 30 requests again the user identity, using the EAP Request/AKA Identity message. This identity request is performed as intermediate nodes may have changed or replaced the user identity received in the EAP Response Identity message. However, this new request of the user identity can be omitted by the home operator if it is assured that the user identity could not have been changed or modified by any means in the EAP Response Identity message.
[0039] In step S108, the authenticator 20 in the access network forwards the EAP Request/AKA Identity message to the UE 10. In step S109, the UE 10 responds with the same identity it used in the previous EAP Response Identity message. In step S110, the authenticator 20 in the access network forwards the EAP Response/AKA Identity to the AAA server 30. The identity received in this message will be used by the AAA server 30 in the rest of the authentication process. If an inconsistency is found between the identities received in the two messages (EAP Response Identity and EAP Response/AKA Identity) so that a user profile and authentication vectors previously retrieved from the HSS 40 are not valid, these data may be requested again from the HSS 40. In other words, step S106 may be repeated before continuing with step S111.
[0040] In order to optimise performance, the identity re-request process (steps S107 to S110) may be performed before user profile and authentication vectors retrieval.
[0041] In step S111 the AAA server 30 checks whether it has an EPS access profile of the UE 10 available. If not, the EPS access profile is retrieved from the HSS 40. The AAA server 30 verifies that the UE 10 is authorized to use the EPS. It is to be noted that this step could be performed at some other point, after step S105 and before step S114.
[0042] In step S112 new keying material is derived from IK_new and CK_new according to EAP-AKA. A new pseudonym and/or re-authentication ID may be chosen and if chosen they should be protected, i.e. encrypted and integrity protected, using keying material generated from EAP-AKA.
[0043] In step S113 the AAA server 30 sends RAND, AUTN, a message authentication code (MAC) and two user identities (if they are generated), protected pseudonym and/or protected re-authentication id, to the authenticator 20 in the access network in an EAP Request/AKA-Challenge message. The sending of the re-authentication id depends on 3GPP operator's policies on whether to allow fast re-authentication processes or not. It implies that, at any time, the AAA server 30 decides (based on policies set by the operator) to include the re-authentication id or not, thus allowing or disallowing a triggering of a fast re-authentication process.
[0044] The AAA server 30 may send as well a result indication to the authenticator 20 in the access network, in order to indicate that it wishes to protect a success result message at the end of the process, i.e. if the outcome is successful. The protection of result messages depends on home operator's policies.
[0045] In step S114 the authenticator 20 in the access network sends the EAP Request/AKA-Challenge message to the UE 10. In step S115 the UE 10 first checks whether the AMF separation bit in the EAP Requets/AKA-Challenge message is set to 1. If this is not the case the UE 10 rejects the authentication. Otherwise, the UE 10 runs AKA algorithms on a USIM application. The USIM application verifies that AUTN is correct and hereby authenticates the network. If AUTN is incorrect, the UE 10 rejects the authentication (not shown in this example). If a sequence number is out of synch, the UE 10 initiates a synchronization procedure. If AUTN is correct, the USIM application computes RES, IK and CK.
[0046] Moreover, in step S115 the UE 10 computes (CK_new, IK_new) = F(CK, IK, <access network identity>, <possibly further parameters>) where F is a key derivation function, in the same way as the HSS 40. The UE 10 derives required additional new keying material, including the key MSK, from the new computed IK and CK (i.e. CK_new, IK_new) in the same way as the AAA server 30, and checks the received MAC with the new derived keying material.
[0047] If a protected pseudonym and/or re-authentication identity were received, then the UE 10 stores the temporary identity(s) for future authentications.
[0048] In step S116 the UE 10 calculates a new MAC value covering the EAP message with the new keying material. The UE 10 sends a message EAP Response/AKA-Challenge containing calculated RES and the new calculated MAC value to the authenticator 20 in the access network. The UE 10 may include in this message a result indication if it received the same indication from the AAA server 30. Otherwise, the UE 10 may omit this indication.
[0049] In step S117 the authenticator 20 in the access network sends the EAP Responsea/AKA-Challenge message tn the AAA server 30. In step S118 the AAA server 30 checks the received MAC and compares XRES to the received RES. If all checks in step S118 are successful, in step S119 the AAA server 30 may send a message EAP Request/AKA-Notification, previous to an EAP Success message, if the AAA server 30 requested previously to use protected successful result indications. This message is MAC protected.
[0050] In step S120 the authenticator 20 in the access network forwards the message to the UE 10. In step S121 the UE 10 sends the EAP Response/AKA-Notification. In step S122 the authenticator 20 in the access network forwards the EAP Response/AKA-Notification message to the AAA server 30. The AAA server may ignore the contents of this message. In step S123 the AAA server 30 sends an EAP Success message to the authenticator 20 in the access network, which may be preceded by an EAP Notification, as explained in step S120. The AAA server 30 also includes keying material, e.g. the key MSK, in an underlying AAA protocol message (i.e. not at an EAP level). The authenticator 20 in the access network stores the keying material to be used in communication with the authenticated UE 10 as required by the access network.
[0051] In step S124, the authenticator 20 in the access network informs the UE 10 about the successful authentication with the EAP Success message. Now the EAP AKA exchange has been successfully completed, and the UE 10 and the authenticator 20 in the access network share keying material derived during that exchange. In step S125 the AAA server may initiate the registration to the HSS 40.
[0052] The authentication process may fail at any moment, for example because of unsuccessful checking of MACs or no response from the UE 10 after a network request. In that case, the EAP AKA process will be terminated and an indication should be sent to the HSS 40.
[0053] In the following a tunnel full authentication and authorization process of an untrusted access to EPS will be described by way of an embodiment shown in Fig. 2. A tunnel end point in the EPS network is an ePDG 60 acting as an authenticator. As part of a tunnel establishment attempt, use of a certain APN (Access Point Name) is requested. When a new attempt for tunnel establishment is performed by an UE 50 the UE 50 should use IKEv2 (Internet Key Exchange version 2). The authentication of the UE 50 in its role as IKEv2 initiator terminates at an AAA server 30 (3GPP AAA server). The UE 50 may send EAP messages over IKEv2 to the ePDG 60. The ePDG 60 may extract the EAP messages received from the UE 50 over IKEv2, and send them to the AAA server 30. The UE 50 may use Configuration Payload of IKEv2 to obtain a Remote IP address.
[0054] EAP-AKA message parameters and procedures regarding authentication are omitted. Only decisions and processes relevant to the use of EAP-AKA within IKEv2 are explained.
[0055] As the UE 50 and the ePDG 60 generate nonces as input to derive the encryption and authentication keys in IKEv2, replay protection is provided. For this reason, there is no need for the AAA server 30 to request a user identity again using the EAP-AKA specific methods, because the AAA server 30 is certain that no intermediate node has modified or changed the user identity.
[0056] In step S201, the UE 50 and the ePDG 60 exchange a first pair of messages IKE_SA_INIT, in which the ePDG 60 and the UE 50 negotiate cryptographic algorithms, exchange nonces and perform a Diffie_Hellman exchange.
[0057] In step S202, the UE 50 sends the user identity (in IDi payload) and APN information (in IDr payload) in a first message of an IKE_AUTH phase, and begins negotiation of child security associations. The UE 50 omits an AUTH parameter in order to indicate to the ePDG 60 that it wants to use EAP over IKEv2. The user identity should be compliant with Network Access Identifier (NAI) format, containing IMSI or a pseudonym, as defined for the EAP-AKA protocol. The UE 50 may send a configuration payload (CFG_REQUEST) within the IKE_AUTH request message to obtain a remote IP Address.
[0058] In step S203, the ePDG 60 sends an Authentication Request message with an empty EAP AVP (Attribute Value Pair) to the AAA server 30, containing the user identity and APN. The ePDG 60 should include a PDG-type indicator indicating that the authentication is being performed for tunnel establishment with an ePDG and not an I-WLAN (Interrogating WLAN) PDG. This will help the AAA server 30 to distinguish among authentications for trusted access, as described with respect to Fig. 1, authentications for tunnel setup in I-WLAN which would allow also EAP-SIM (Subscriber Identity Module), and authentications for tunnel setup in EPS which allow only EAP-AKA.
[0059] In step S204, the AAA server 30 may fetch a user profile and authentication vectors from the HSS 40 if these parameters are not available in the AAA server 30. The AAA server 30 includes the PDG-type indicator, and the identity of the ePDG in its request to the HSS 40.
[0060] Moreover, in step S204, the HSS 40 retrieves an authentication vector from the Authentication Centre with AMF separation bit = 1. The HSS 40 then transforms this authentication vector into a new authentication vector by computing (CK_new, IK_new) = F(CK, IK, <PDG-type indicator, ePDG identity>, <possibly further parameters>) where F is a key derivation function. The HSS 40 then sends this transformed authentication vector to the AAA server 30.
[0061] It is to be noted that the AAA server 30 does not notice the transformation and treats this authentication vector like any other authentication vector.
[0062] In addition, the AAA server 30 may retrieve authentication vectors from the HSS 40 when it detects that a VPLMN selected by a user has changed. This can happen, for example, when a user is performing a VPLMN re-selection procedure and is initiating a new authentication procedure via a new VPLMN. It is to be noted that a user cannot initiate a new authentication procedure.
[0063] In step S205, the AAA server 30 initiates an authentication challenge. The user identity is not requested again. In step S206, with a message IKE_AUTH Response, the ePDG 60 responds with its identity, a certificate, and sends the AUTH parameter to protect the previous message it sent to the UE 50 in the IKE_SA_INIT exchange. The ePDG 60 completes the negotiation of the child security associations as well. The EAP message EAP-Request/AKA-Challenge received from the AAA server 30 is included in order to start the EAP procedure over IKEv2.
[0064] In step S207, the UE 50 first checks whether the AMF separation bit is set to 1 in the message IKE_AUTH Response received from the ePDG 60. If this is not the case the UE 50 rejects the authentication. Otherwise, the UE 50 runs AKA algorithms on a USIM application and checks the authentication parameters as described with respect to step S115 in Fig. 1.
[0065] The UE 50 then computes (CK_new, IK_new) = F(CK, IK, <PDG-type indicator, ePDG identity>, <possibly further parameters>) where F is a key derivation function, in the same way as the HSS 40. The UE 50 derives required additional new keying material, including a key MSK, according to the EAP-AKA protocol from the new computed IK and CK (i.e. CK_new, IK_new) in the same way as the AAA server 30, and in step S207a, responds to the authentication challenge. The only payload (apart from the header) in an IKEv2 message IKE_AUTH Request is an EAP message EAP-Response/AKA-Challenge.
[0066] In step S208, the ePDG 60 forwards the EAP-Response/AKA-Challenge message to the AAA server 30. In step S209, when all checks are successful, the AAA server 30 sends an Authentication Answer including an EAP success and keying material to the ePDG 60. This keying material should comprise the MSK generated during the authentication process. When Wm* and Wd* interfaces between the ePDG 60 and the AAA server 30 are implemented using Diameter, the MSK may be encapsulated in an EAP-Master-Session-Key parameter.
[0067] In step S209a, the ePDG 60 sends an Authorization Request message with an empty EAP AVP to the AAA server 30, containing APN. In step S209b, the AAA server 30 checks in user's subscription (subscription of the UE 50) if the user (the UE 50) is authorized to establish the tunnel. The counter of IKE SAs (Internet Key Exchange Security Associations) for that APN is stepped up. If the maximum number of IKE SAs for that APN is exceeded, the AAA server 30 should send an indication to an ePDG that established the oldest active IKE SA (it could be the ePDG 60 or a different one) to delete the oldest established IKE SA. The AAA server should update the information of IKE SAs active for the APN accordingly.
[0068] In step S209c, the AAA server 30 sends an AA-Answer to the ePDG 60. The AAA server 30 may send the IMSI within the AA-Answer, if the Authorization Request message in step S109a contains a temporary identity, i.e. if an AA-Request does not contain the IMSI.
[0069] In step S210, the MSK should be used by the ePDG 60 to generate the AUTH parameters in order to authenticate the IKE_SA_INIT phase messages, as specified for IKEv2. These two first messages had not been authenticated before as there was no keying material available yet. A shared secret generated in an EAP exchange, e.g. the MSK, when used over IKEv2, should be used to generated the AUTH parameters.
[0070] In step S211, an EAP Success/Failure message is forwarded to the UE 50 over IKEv2. In step S212, the UE 50 may take its own copy of the MSK as input to generate the AUTH parameter to authenticate the first IKE_SA_INIT message. The AUTH parameter is sent to the ePDG 60.
[0071] In step S213, the ePDG 60 checks the correctness of the AUTH received from the UE 50. At this point the UE 50 is authenticated. In case S2b reference point is used, PMIP (Proxy Mobile IP) signalling between the ePDG 60 and a PDN GW (Packet Data Network Gateway) (not shown) can start. The ePDG 60 continues with the next step in the procedure described with respect to Fig. 2 only after successful completion of a PMIP binding update procedure.
[0072] In step S214, the ePDG 60 calculates the AUTH parameter which authenticates the second IKE_SA_INIT message. The ePDG 60 should send an assigned Remote IP address in a configuration payload (CFG_REPLY). Then the AUTH parameter is sent to the UE 50 together with the configuration payload, security associations and the rest of the IKEv2 parameters and the IKEv2 negotiation terminates.
[0073] In step S215, if the ePDG 60 detects that an old IKE SA for that APN already exists, it will delete the IKE SA and send the UE 50 an INFORMATIONAL exchange with a Delete payload in order to delete the old IKE SA in the UE 50.
[0074] Fig. 3 shows a schematic block diagram illustrating a structure of a user equipment 100, an authenticator 200, an authentication server 300 and a home subscriber server 400 according to an embodiment of the invention. The user equipment 100 may act as the UE 10 shown in Fig. 1 or the UE 50 shown in Fig. 2. The authentication server 300 may act as AAA server shown in Figs. 1 and 2, and the home subscriber server 400 may act as the HSS 40 shown in Figs. 1 and 2. The authenticator 200 may act as the authenticator 20 shown in Fig. 1 or as the ePDG 60 shown tin Fig. 3.
[0075] According to the embodiment shown in Fig. 3, the user equipment 100 comprises a processor 310, a receiver 311 and a transmitter 312, which communicate with each other via a bus 313. The authentication server 300 comprises a processor 330, a receiver 331 and a transmitter 332, which communicate with each other via a bus 333. The home subscriber server 400 comprises a processor 340, a receiver 341 and a transmitter 342, which communicate with each other via a bus 343. The authenticator 200 comprises a processor 320, a receiver 321 and a transmitter 322, which communicate with each other via a bus 323.
[0076] The processor 320 of the authenticator 200 controls access from the user equipment 100 to a network, e.g. an EPS network, during authentication between the user equipment and the network, and may cause the transmitter 322 to transmit use information and an identity of the authenticator 200 to the authentication server 300 during the control.
[0077] The processor 330 of the authentication server 300 checks whether unused authentication information including a separation indicator (AMF separation bit) which is set (i.e. set to 1) is available for the user equipment 100 during authentication between the user equipment 100 and the EPS network. In case the unused authentication information is not available, the processor 330 includes the use information and the identity of the authenticator 200 controlling access from the user equipment 100 to the EPS network in a request for authentication information and causes the transmitter 331 to transmit the request. The use information may comprise at least one of an indication that the authentication information is for an evolved packet system use and an indicator indicating that the authentication is performed for tunnel establishment with the authenticator 200. The indicator and/or the identity may have been received from the authenticator 200. The identity of the authenticator 200 may comprise at least one of a fully qualified domain name, a mobile country code and a mobile network code.
[0078] The receiver 341 of the home subscriber server 400 may receive the request for authentication information from the authentication server 300. The processor 340 of the home subscriber server 400 transforms cryptographic keys (CK, IK) for the user equipment 100 in accordance with the use information into access specific cryptographic keys (CK_new, IK_new) based on the identity of the authenticator 200, and generates the authentication information including the access specific cryptographic keys and a separation indicator (AMF separation bit) which is set (i.e. set to 1) in accordance with the use information, and the transmitter 342 of the home subscriber server 400 transmits the authentication information to the authentication server 300.
[0079] The receiver 331 of the authentication server 300 receives the authentication information from the home subscriber server 400, and the processor 330 computes a key (MSK) specific to an authentication method from the access specific cryptographic keys. The authentication method may be based on an extensible authentication protocol method for authentication and key agreement (EAP-AKA).
[0080] The processor 310 of the user equipment 100 checks whether a separation indicator (AMF separation bit) included in authentication information is set (i.e. set to 1). The authentication information may be received by the receiver 311 from the authenticator 200 during authentication between the user equipment 100 and the EPS network using extensible authentication protocol method for authentication and key agreement (EAP-AKA). If the separation indicator is set, the processor 310 transforms cryptographic keys (CK, IK) obtained from a USIM (not shown) inserted in the user equipment 100 into access specific cryptographic keys (CK_new, IK_new) based on the identity of the authenticator 200 and computes a key (MSK) specific to the authentication method from the access specific cryptographic keys. The transmitter 312 may transmit authentication messages using the extensible authentication protocol method for the authentication and key agreement.
[0081] According to an embodiment of the invention, the home subscriber server 400 receives a request for authentication information from the authentication server 300 and transforms cryptographic keys (CK, IK)for the user equipment 100 into access specific cryptographic keys (CK_new, IK_new) based on the identity of the authenticator 200 controlling access from the user equipment 100 to the EPS network, and generates the authentication information including the access specific cryptographic keys and a separation indicator which is set. The user equipment 100 checks whether the separation indicator included in the authentication information is set, and if the separation indicator is set, transforms cryptographic keys into access specific cryptographic keys based on the identity of the authenticator 200, and computes a key (MSK) specific to an authentication method from the access specific cryptographic keys.
[0082] According to an embodiment of the invention as described above, new keys CK_new, IK_new are derived in parallel on a UE and an HSS transparent to an EAP mechanism controlled by an AAA server. These new derived keys cannot be misused for authorization in other networks.
[0083] In EPS for non-3GPP untrusted access, cryptographic separation is with authenticator granularity. As described above, involved entities are HSS and ePDG. As a result, one authenticator cannot impersonate another authenticator even when there are several ePDGs (authenticators) per serving PLMN.
[0084] In EPS for non-3GPP trusted access, cryptographic separation is per PLMN level as described above. It can be per authenticator as well if the authenticator can provide a meaningful identity to the AAA server.
[0085] It is to be understood that the above description of the embodiments is illustrative of the invention and is not to be construed as limiting the invention. Various modifications and applications may occur to those skilled in the art without departing from the scope of the invention as defined by the appended claims.
check (S115, S207) whether a separation indicator included in authentication information is set, the authentication information being received during authentication between the apparatus (10, 50) and a network using an extensible authentication protocol method for authentication and key agreement, the separation indicator indicating whether or not the network is an evolved packet system network; and
transform (S115, S207), if the separation indicator is set, cryptographic keys CK, IK for the apparatus into new cryptographic keys CK_new, IK_new using an identity of the network, and compute (S115, S207) a key MSK to be used in the extensible authentication protocol method from the new cryptographic keys CK_new, IK_new.
a receiver (341) configured to receive (S106, S204) a request for authentication information during authentication between a user equipment (10, 50) and a network using an extensible authentication protocol method for authentication and key agreement, the request including use information and an identity of the network;
a processor (340) configured to transform (S106, S204) cryptographic keys CK, IK for the user equipment in accordance with the use information into new cryptographic keys CK_new, IK_new using the identity of the network, and generate the authentication information including the new cryptographic keys and a separation indicator which is set in accordance with the use information, the separation indicator indicating whether or not the network is an evolved packet system network, wherein the new cryptographic keys serve as a basis for computing a key MSK to be used in the extensible authentication protocol method; and
a transmitter (342) configured to transmit (S106, S204) the authentication information.
checking (S115, S207) whether a separation indicator included in authentication information is set, the authentication information being received during authentication between a user equipment (10, 50) and a network using an extensible authentication protocol method for authentication and key agreement, the separation indicator indicating whether or not the network is an evolved packet system network; and
if the separation indicator is set, transforming (S115, S207) cryptographic keys CK, IK for the user equipment into new cryptographic keys CK_new, IK_new using an identity of the network, and computing (Sll5, S207) a key MSK to be used in the extensible authentication protocol method from the new cryptographic keys CK_new, IK_new.
receiving (S106, S204) a request for authentication information during authentication between a user equipment (10, 50) and a network using an extensible authentication protocol method for authentication and key agreement, the request including use information and an identity of the network;
transforming (S106, S204) cryptographic keys CK, IK for the user equipment in accordance with the use information into new cryptographic keys CK_new, IK_new using the identity of the network, and generating (S106, S204) the authentication information including the new cryptographic keys and a separation indicator which is set in accordance with the use information, the separation indicator indicating whether or not the network is an evolved packet system network, wherein the new cryptographic keys serve as a basis for computing a key MSK to be used in the extensible authentication protocol method; and
transmitting the authentication information.
zu prüfen (S115, S207), ob ein Trennindikator, der in Authentifizierungsinformationen enthalten ist, gesetzt ist, wobei die Authentifizierungsinformationen während einer Authentifizierung zwischen der Vorrichtung (10, 50) und einem Netz unter Verwendung eines Verfahrens eines erweiterbaren Authentifizierungsprotokolls zur Authentifizierung und Schlüsselvereinbarung empfangen werden, wobei der Trennindikator angibt, ob das Netz ein Netz eines entwickelten Paketsystems ist oder nicht; und
wenn der Trennindikator gesetzt ist, kryptographische Schlüssel CK, IK für die Vorrichtung in neue kryptographische Schlüssel CK_new, IK_new unter Verwendung einer Identität des Netzes zu transformieren (S115, S207), und einen Schlüssel MSK, der im Verfahren des erweiterbaren Authentifizierungsprotokolls verwendet werden soll, aus den neuen kryptographischen Schlüsseln CK_new, IK_new zu berechnen (S115, S207).
einen Empfänger (341), der dazu konfiguriert ist, eine Anforderung für Authentifizierungsinformationen während einer Authentifizierung zwischen einem Benutzergerät (10, 50) und einem Netz unter Verwendung eines Verfahrens eines erweiterbaren Authentifizierungsprotokolls zur Authentifizierung und Schlüsselvereinbarung zu empfangen (S106, S204), wobei die Anforderung Verwendungsinformationen und eine Identität einer Vorrichtung, die den Zugang von einem Benutzergerät zu einem Netz steuert, umfasst;
einen Prozessor (340), der dazu konfiguriert ist, kryptographische Schlüssel CK, IK für das Benutzergerät gemäß den Verwendungsinformationen in neue kryptographische Schlüssel CK_new, IK_new unter Verwendung einer Identität des Netzes zu transformieren (S106, S204) und die Authentifizierungsinformationen mit den neuen kryptographischen Schlüsseln und einem Trennindikator zu erzeugen, der gemäß den Verwendungsinformationen gesetzt wird, wobei der Trennindikator angibt, ob das Netz ein Netz eines entwickelten Paketsystems ist oder nicht, wobei die neuen kryptographischen Schlüssel als Basis zum Berechnen eines Schlüssels MSK dienen, der im Verfahren des erweiterbaren Authentifizierungsprotokolls verwendet werden soll; und
einen Sender (342), der dazu konfiguriert ist, die Authentifizierungsinformationen zu senden (S106, S204).
Prüfen (S115, S207), ob ein Trennindikator, der in Authentifizierungsinformationen enthalten ist, gesetzt ist, wobei die Authentifizierungsinformationen während einer Authentifizierung zwischen einem Benutzergerät (10, 50) und einem Netz unter Verwendung eines Verfahrens eines erweiterbaren Authentifizierungsprotokolls zur Authentifizierung und Schlüsselvereinbarung empfangen werden, wobei der Trennindikator angibt, ob das Netz ein Netz eines entwickelten Paketsystems ist oder nicht; und
wenn der Trennindikator gesetzt ist, Transformieren (S115, S207) von kryptographischen Schlüsseln CK, IK für das Benutzergerät in neue kryptographische Schlüssel CK_new, IK_new unter Verwendung einer Identität des Netzes, und Berechnen (S115, S207) eines Schlüssels MSK, der in dem Verfahren des erweiterbaren Authentifizierungsprotokolls verwendet werden soll, aus den neuen kryptographischen Schlüsseln CK_new, IK_new.
Empfangen (S106, S204) einer Anforderung für Authentifizierungsinformationen während einer Authentifizierung zwischen einem Benutzergerät (10, 50) und einem Netz unter Verwendung eines Verfahrens eines erweiterbaren Authentifizierungsprotokolls zur Authentifizierung und Schlüsselvereinbarung, wobei die Anforderung Verwendungsinformationen und eine Identität einer Vorrichtung, die den Zugang von einem Benutzergerät zu einem Netz steuert, umfasst;
Transformieren (S106, S204) von kryptographischen Schlüsseln CK, IK für das Benutzergerät gemäß den Verwendungsinformationen in neue kryptographische Schlüssel CK_new, IK_new unter Verwendung einer Identität des Netzes und Erzeugen (S106, S204) der Authentifizierungsinformationen mit den neuen kryptographischen Schlüsseln und einem Trennindikator, der gemäß den Verwendungsinformationen gesetzt wird, wobei der Trennindikator angibt, ob das Netz ein Netz eines entwickelten Paketsystems ist oder nicht, wobei die neuen kryptographischen Schlüssel als Basis zum Berechnen eines Schlüssels MSK dienen, der in dem Verfahren des erweiterbaren Authentifizierungsprotokolls verwendet werden soll; und
Übertragen der Authentifizierungsinformationen.
vérifier (S115, S207) si un indicateur de séparation inclus dans des informations d'authentification est défini, les informations d'authentification étant reçues au cours d'une authentification entre l'appareil (10, 50) et un réseau au moyen d'un procédé de protocole d'authentification extensible pour authentification et accord de clés, l'indicateur de séparation indiquant si ou non le réseau est un réseau système évolué à commutation de paquets, et
transformer (S115, S207), si l'indicateur de séparation est défini, les clés cryptographiques CK, IK pour l'appareil en des nouvelles clés cryptographiques CK_new, IK_new au moyen d'une identité du réseau, et calculer (S115, S207) une clé MSK à utiliser dans le procédé de protocole d'authentification extensible à partir des nouvelles clés cryptographiques CK_new, IK_new.
un récepteur (341) configuré de façon à recevoir (S106, S204) une demande pour des informations d'authentification au cours d'une authentification entre un équipement d'utilisateur (10, 50) et un réseau au moyen d'un procédé de protocole d'authentification extensible pour authentification et accord de clés, la demande comprenant des informations d'utilisation et une identité du réseau,
un processeur (340) configuré de façon à transformer (S106, S204) les clés cryptographiques CK, IK pour l'équipement d'utilisateur selon les informations d'utilisation en les nouvelles clés cryptographiques CK_new, IK_new au moyen de l'identité du réseau et à générer les informations d'authentification comprenant les nouvelles clés cryptographiques et un indicateur de séparation qui est défini selon les informations d'utilisation, l'indicateur de séparation indiquant si ou non le réseau est un réseau système évolué à commutation de paquets, dans lequel les nouvelles clés cryptographiques servent de base pour le calcul d'une clé MSK à utiliser dans le procédé de protocole d'authentification extensible, et
un émetteur (342) configuré de façon à émettre (S106, S204) les informations d'authentification.
la vérification (S115, S207) si un indicateur de séparation inclus dans des informations d'authentification est défini, les informations d'authentification étant reçues au cours d'une authentification entre un équipement d'utilisateur (10, 50) et un réseau au moyen d'un procédé de protocole d'authentification extensible pour authentification et accord de clés, l'indicateur de séparation indiquant si ou non le réseau est un réseau système évolué à commutation de paquets, et
si l'indicateur de séparation est défini, la transformation (S115, S207) des clés cryptographiques CK, IK pour l'équipement d'utilisateur en les nouvelles clés cryptographiques CK_new, IK_new au moyen d'une identité du réseau, et le calcul (S115, S207) d'une clé MSK à utiliser dans le procédé de protocole d'authentification extensible à partir des nouvelles clés cryptographiques CK_new, IK_new.
la réception (S106, S204) d'une demande pour des informations d'authentification au cours d'une authentification entre un équipement d'utilisateur (10, 50) et un réseau au moyen d'un procédé de protocole d'authentification extensible pour authentification et accord de clés, la demande comprenant des informations d'utilisation et une identité du réseau,
la transformation (S106, S204) des clés cryptographiques CK, IK pour l'équipement d'utilisateur selon les informations d'utilisation en les nouvelles clés cryptographiques CK_new, IK_new au moyen de l'identité du réseau, et la génération (S106, S204) des informations d'authentification comprenant les nouvelles clés cryptographiques et un indicateur de séparation qui est défini selon les informations d'utilisation, l'indicateur de séparation indiquant si ou non le réseau est un réseau système évolué à commutation de paquets, dans lequel les nouvelles clés cryptographiques servent de base pour le calcul d'une clé MSK à utiliser dans le procédé de protocole d'authentification extensible, et
la transmission des informations d'authentification.