Federated access service authorization

MIKKO NIIRANEN and PREETIDA VINAYAKRAY-JANI Nokia Reseach Center

Itämerenkatu 11-13 00180 Helsinki

FINLAND

Abstract: - The increasing variety of access technologies provided by network service providers increases the complexity in handover processes. This paper proposes an approach which aims to simplify this scenario by using federated authentication and authorization credentials for users. The credentials, or tokens, are transferred to the service provider over any authentication protocol, on any access technology, by allowing any authentication protocol data in the token together with a generic authorization part. If the authorization part is signed by a trusted service provider in the same federation, it provides enough proof to the service provider to allow the user to use the services stated in the token.

Keywords: Authorization, Authentication, Access Services, Handover, Federations, Token.

1. Introduction With a variety of access technologies available from many cellular/wireless network service providers, there is a significant need for secure and seamless access to the services offered by the service providers. However with more technologies, services and multi-interface end devices joining the fray, the gap between the services offered by the various access networks will confine, adding more complexity to the handover/mobility process. Therefore handover solutions need to come up with unified authentication and authorization approach that ensure secure and seamless access to the services for end user.

Considering such unified approach, the proposed approach here uses the federated authentication and authorization tokens which include authentication and authorization credentials of user. The end device/user – MT establishes such token securely when it first subscribes the services from home service providers. With successful authentication and authorization in home service provider (SP), the MT receives the handover token (MT_HOToken) so that MT is able to perform secure and seamless handover while roaming. Nevertheless such approach is not limited to one specific standardized authentication method, as system architecture is flexible to adapt to any authentication method.

The paper will start of by providing a glance over Related work and Background in section 2. After that the general picture of the work is presented in 3. The System Architecture is described in 3.1, the Security Assumptions regarding the architecture in 3.2, and the Software Architecture in 3.3. The Token Specifications (3.4) section specifies the tokens used in the system,

while 3.5 and 3.6 describe the MT Startup and Handover, respectively. Security Statements (3.7) briefly state the security of the system. The paper is concluded in chapter 4 Conclusions. 2. Related work & Background Authentication and authorization architectures have been studied extensively in the past. In [1], the port based authentication architecture 802.1X is specified. This architecture is used for authentication in 802.11.Since EAP [2] is used it provides high flexibility for authentication methods. For UMTS, the AKA [3] authentication protocol is defined. This protocol provides authentication based on the International Mobile Subscriber Identity (IMSI), and a pre-shared key between the phone and the home SP. This architecture provides little flexibility. So, a problem with authentication at the link layer is that different access services (i.e. GPRS, CDMA, WLAN) use different authentication mechanisms and some of these are highly standardized.

In [4], an authentication and authorization system using the Liberty Alliance Identity Architecture (LAIA) [5] to provide WLAN network access authentication is specified. The authentication is however done at the IP layer. An approach where link layer security is put completely out of scope is [6]. Also in that paper a LAIA based approach is described. The problem with this approach is that no data link layer authentication or security is considered, and the MT gets link layer access and an IP address even before authenticating.

A paper describing SIM based authentication in combination with the LAIA is [7]. Here, when a user

Proceedings of the 10th WSEAS International Conference on COMMUNICATIONS, Vouliagmeni, Athens, Greece, July 10-12, 2006 (pp21-26)

with a mobile phone is trying to access a web service he/she is directed to an IdP in the operators network, which is federated with the web service provider. The authentication with the IdP is based on the SIM authentication.

None of the above described authentication architectures support both network access authentications for various network access technologies at the link layer together with service authorization in one go. An architecture supporting this would be strong in the future mobile networks, which probably will consist of mobile terminals with multiple access interfaces for different network access technologies used for accessing the services provided by the service providers.

3. Federated Identity Management To authenticate over various access technologies and get authorization to use the available services in a SP domain, the proposed approach uses identity management principles on the link layer. This means that a user’s identity is linked to the services which it is authorized to access, and that the standardized authentication mechanisms are followed for the different access technologies which the user accesses. The authorization decision is only needed once in each SP domain for access to all the access services, since the authorization decision is based upon the identity, and not the technology specific account identifier.

To carry the identities and their related information, such as authorized services, two tokens are specified (see section 3.4). The tokens are transferred to the SP in any access specific authentication protocol. The tokens provide proof to the SP that the MT is authorized to use the services that are stated in the token. The proof comes from the fact that the SPs have established trust relationships (federations), by which it is possible for the SPs in the federation to verify the token. The trust relationships are pre-established. 3.1. System Architecture The system architecture consists of four main entities: the MT, IdP, PAC and AP/BS. The last three of them

form a SP domain. An example SP domain is shown in Fig. 1. • The MT is a mobile device which may have several

interfaces supporting different access technologies like GPRS, WLAN, etc. The MT therefore needs to be able to determine when a handover needs to take place, either within an access network or between two access networks. It also needs to be able to authenticate using the specific authentication protocols for each of the access technologies.

• The IdP is an Identity Provider, which handles users identities and their credentials. The IdP needs to be able to create the tokens and also be able to verify them.

• The PAC (Provider Access Control) is the entity that receives the tokens through an authentication protocol specific for the access type. It should forward the tokens to the IdP in the domain for verification, and also be able to verify tokens created by the IdP in the same domain.

• The network also includes different types of Access Points (AP) or Base Stations (BS).

3.2. Security Assumptions Assumptions regarding the system architecture:

• The MTs share authentication credentials with their home SPs. This is needed to be able to generate a session key in a handover, which will be described later in this paper (section 3.6).

• All participating IdPs of the SPs in a federation hold a X.509 certificate. They also have a federation certificate which is specific for the federation. All participating service providers in the federation have this certificate in common.

• The PACs in the networks have to know the certificates for the SP they belong to and also be able to verify a certificate/certificate chain.

3.3. Software Architecture As described, the system architectural entities mainly include Mobile Terminal (MT), and Provider Access Controller (PAC) and Identity Provider (IdP) in home as well as in visited networks. To achieve the functional objectives in section 3.1 the entities are enhanced with following software components. Mobile Terminal: • Media Independent Handover (MIH) module:

Determines the necessity for handover and with Fig. 1: System architecture

Proceedings of the 10th WSEAS International Conference on COMMUNICATIONS, Vouliagmeni, Athens, Greece, July 10-12, 2006 (pp21-26)

predefined policies in terms of the authentication and authorization, link layers performance and pre-defined access and media profile in user/application, finally such mobility decision gets executed. The outcome of handover decision triggers the authentication and authorization event for MT.

• Authentication module: Handles the authentication and authorization procedures in the MT.

Provider Access Controller: • Authenticator module: Solicits the access

authentication of a visiting MT. It also forwards the authorization part of the token to the IdP.

Identity Provider: • Authorization module: Verifies the authorization

parts of the tokens. • Database module: Interacts with a database which

manages the identity of the MT’s belonging to the SP along with their authentication and access service authorization credentials.

• Location module: Receives location updates concerning MTs from foreign SPs.

3.4. Token Specifications Two tokens are defined, one called the startup token (MT_SUToken), which is used at MT boot up and initial network access authentication, and another called the handover token (MT_HOToken), which is used in handover situations after a successful initial authentication. The main difference between the two tokens is that the MT_HOToken has fields for a nonce and a key and that it has a shorter lifetime than the MT_SUToken. The MT_SUToken is pre-distributed securely to the MT upon service purchase from the home SP and stored in the MT in a secure place where it cannot be tampered with by malicious users. A MT_HOToken is created by an IdP in a SP domain when a handover trigger is received.

Both the tokens consist of two parts: the authentication part and the authorization part. It is necessary to separate them to support different authentication mechanisms. So, the authentication part contains data for a specific authentication mechanism, while the authorization part is generic. The MT_SUToken is shown in Table 1 while the MT_HOToken is shown in Table 2 .

3.4.1. Authentication The authentication part is identical in both the tokens. It consists of the Access Service Type field and the Authentication data field. The Access Service Type field

Table 1: MT_SUToken contents. is used to indicate what type of access service the MT is authenticating through, for accounting reasons. As most authentication mechanisms will require their own authentication data to provide possibility to authenticate using the standard authentication protocol/mechanism for the access technology, the authentication token part contains the Authentication Data field, which can contain this information.

Here is, as an example only described what the field can contain for UMTS AKA. To understand what is needed in the token for AKA, knowledge about AKA is required. As mentioned in section 2, AKA is based on a pre-shared key and an IMSI, which the mobile phone and its corresponding home network operator share. For authentication of the mobile phone, the network who wants to authenticate the MT sends it a random number (RAND) and a network authentication token (AUTN). AUTN is used for network authentication to the MT, while RAND should be computed by the MT with its shared key K to yield RES. RES is then sent to the network for verification. So, based on this, what is needed to be sent the network is the response RES, which is computed from RAND using K. This needs to be included in the token Authentication Data field.

3.4.2. Authorization The Authorization part of the token differs in the two token types. Common to the both are the Authorized Services, Authentication Status, MTid, NAI of home network, Token Creation Time, Token Lifetime and Signature fields. The contents in these fields are quite self explanatory. The difference between the MT_HOToken and the MT_SUToken are the Session Master Key and Nonce fields. These fields will hold a session key for handover situations and a nonce for key derivation at the MT, respectively. The Session Key and optionally also the MT Id field will be encrypted using the public key of the target SP in a handover, if known, or the federation public key if not. The authorization part is signed by the SP using their private key. The MT_SUToken is signed by the home SPs of the MTs with their private keys.

Part Field Encrypted

Authentication Access Service Type No

- Authentication Data No

Authorization Authentication Status No - MT id No

- NAI of home net. No

- Token creation time No

- Token Lifetime No

- Authorized services No

- Signature No

Proceedings of the 10th WSEAS International Conference on COMMUNICATIONS, Vouliagmeni, Athens, Greece, July 10-12, 2006 (pp21-26)

Table 2: MT_HOToken contents 3.5. MT Startup When a MT is switched on, the MT will start by authenticating using some authentication protocol suitable for the available access media, i.e. SIM authentication for GPRS. During the authentication procedure the MT will send its MT_SUToken to the PAC, as shown in Fig. 2. The token is sent in a message which belongs to the access specific authentication protocol. This causes some differences in when the token is sent to the network, since protocols are different, and also in what data the Authentication Part of the MT_SUToken contains, since that part contains data applicable to the access technology specific authentication protocol. This makes it possible to get authenticated over various authentication protocols/mechanisms, as mentioned in section 3.4. The token also contains the authorization part. This, as described, contains information about what services the user is authorized to use, etc.

As the PAC receives the MT_SUToken it will use the data in the Authentication Data field in the authentication protocol. The authorization part of the token is forwarded by the PAC to the IdP to check the creation time, lifetime, MtId, home network NAI, and the authorized services. The Authorized Services field determines what services the MT can use in the network.

The IdP also verifies the signature of the token, to make sure it is validly created by a trusted SP in the same federation. The IdP responds to the PAC with the result of the verification. If the authentication of the MT is successful and if the result of the authorization token verification at the IdP was successful the PAC sends the protocol specific message of successful authentication, which now also means that the MT is also successfully authorized for the services.

As mentioned, in UMTS, the authentication architecture does not provide any flexibility for the protocol. However, the MT_SUToken can be sent to the network PAC in the User Authentication Response message in the AKA protocol. The calculated RES value will then be inserted in the Authentication Data field in the token, as described in 3.4.1. The PAC, will have to forward the token to the IdP for verification, after which it notifies the PAC of the decision, which is based on the token. Meanwhile the PAC will have verified the RES value, and also knows if authentication was successful. If it was, the MT is authenticated and authorized for the services specified in the token.

The MT_SUToken has to be updated when it its lifetime is running out. This always has to be done by the home SP, although it can be done via an intermediary SP. The exact procedure for how the token is updated is out of scope for this paper, but it can be seen that once a MT with a MT_SUToken which lifetime is ending is entering a SP, the home IdP could create a new one for the MT. 3.6. Handover As the MT is moving, it will come across various access networks of varying types and belonging to various SPs. A handover can be done within the current service provider domain, or to another service provider, in this case called roaming.

SPs can establish roaming contracts in the form of federations. This will provide the possibility to skip the authentication phase when moving from a network to another by using the federation trust relationship between the SPs, and simply make an authorization decision upon entry to the network. It is in the handover case where the MT_HOToken comes to use, as the IdP in an SP creates, and sends it to the MT, upon a receipt of a trigger from the MT that it is going to move. The MT_HOToken is delivered to the MT securely using the trust relationship between it and the IdP.

3.6.1. Inter domain handover In a handover situation we assume that the MT receives a network and service specific coverage update through integrated sensor technology like GPS, etc. With such update the MIH module (see section 3.3) proactively

Part Field Encrypted Authentication Access Service Type No - Authentication Data No Authorization Authentication Status No - MT id Optionally

- NAI of home net. No

- Token creation time No

- Token Lifetime No

- NAI of target net. No

- Session Master Key Yes

- Nonce No

- Authorized services No

- Signature No

Fig.2: MT Startup

Proceedings of the 10th WSEAS International Conference on COMMUNICATIONS, Vouliagmeni, Athens, Greece, July 10-12, 2006 (pp21-26)

determines the necessity of handover. Such approach minimizes the usage of air bandwidth and optimizes the handover performances by minimizing signaling overhead and delay. When a coverage update is received and a necessity to perform handover is realized, the MT sends a trigger message to the current IdP. Upon the receipt of the trigger the IdP creates a MT_HOToken consisting of the current security context for the MT, and signs it. The MT_HOToken is then sent to the MT. When the MT receives the MT_HOToken from the IdP it is ready for handover.

As a MT handover between SPs occur the MT sends the MT_HOToken to the SP during the access specific link layer authentication, as shown in Fig. 3. The foreign SP PAC forwards the MT_HOToken of the visiting MT to the IdP for verification when it receives it. Before MT gets authenticated, the IdP verifies the identity of the visiting MT. Once the identity of the MT is verified, the IdP decrypts the key from the handover token. This key can then be used as a master key for session key derivation in the PAC. The MT, who has stored the nonce from the received handover token, can also derive this key by using the Key Derivation Key and the nonce. Assuming visiting SP and home provider has roaming agreement (federation), the verification of identity also authorizes the MT for any specified service usage.

While moving in the visited network, the handover module in MT keeps the track of sensor update and determines the need for inter or intra frequency handover and maintains the session continuity through security context transfer from current access to targeted access. 3.6.2. Intra domain handover When a MT handover is about to occur from an access network to another access network within a SP, the IdP creates a new MT_HOToken which is sent to the MT. The PAC also transfers the current security context to the target PAC where handover is targeted. If an access network authentication system is hierarchically structured, we assume that the security context is transferred to the highest entity in the hierarchy and then distributed downwards to the level necessary.

When the handover occurs the MT sends the MT_HOToken to the PAC in the network access authentication protocol as described in section 3.6.1. The PAC now only needs to verify the signature of the token to verify that the MT is previously authenticated, and derive new encryption keys using the Session Key in the MT_HOToken. 3.6.3. Handover within an access network This paper will not present any general method for performing handover within an access network since they are quite access technology specific. It is however noted that the presented solution could help in handover within a WLAN network by taking advantage of the PAC for security credential distribution to target APs in handover. Also the MT_HOToken could be transferred from the MT upon a handover to the target AP. These approaches are referred to as future work. 3.7. Security Statements • The Authorization parts of the tokens are protected

using a public key signature with the private key of the SP, which makes it possible to verify their integrity and authenticity. It also gives non-repudiation. Certain parts of the token are also encrypted before signing it. These fields are encrypted using the public part of the key in the certificate of the target network in a handover, or if the target network is not known, using the federation certificate/key.

• Since the tokens are always distributed to the MT over the secured link that has been established between it and the network, no intermediate node can eavesdrop and replay the token.

• By having the Token Creation Time and Token Lifetime fields in the tokens, it is made sure that the probability of token reuse is minimized. A sequence number assures the network PAC that the token is not reused within the network.

• The MT_SUToken is stored at a tamper resistant location in the MT. This prevents unauthorized tampering. The MT_SUToken is also signed which provides integrity and authenticity.

• To protect against an attack where a user shares his or her token with other users to give them access through the users account, the foreign networks can update the home network of an authenticated user of its log on. The home network can then make sure that only one is active at one time by checking the token sequence number which is sent to it on a successful log on.

Fig.3: MT when handing over to a new SP from home SP.

Proceedings of the 10th WSEAS International Conference on COMMUNICATIONS, Vouliagmeni, Athens, Greece, July 10-12, 2006 (pp21-26)

• The system gives protection to eavesdropping and message alteration since it provides access technology specific link layer encryption.

4. Conclusions This paper has presented an approach which provides federated access authentication and service authorization based on identity management. The system architecture was defined, together with its security assumptions. Also the software architecture was defined. Then the two tokens, MT_HOToken and MT_SUToken, needed in the architecture, where specified. This was followed by an overview of how the initial authentication of the MT is done upon MT power up, and how handovers are done using the suggested approach.

The approach carries tokens, consisting of an authentication part and an authorization part, within an access technology specific authentication protocol. This facilitates an authorization decision to services provided by an SP as authentication is performed using the access specific authentication protocol at the link layer. In difference to the mentioned work in section 2 where authorization is done on the network layer after authentication is performed, the described approach simplifies the process.

The authentication part of the tokens which carries data specific to the authentication protocol makes the approach flexible to adapt to any authentication method, and thus any access technology. This should be an improvement compared to previous work, since it provides the same authorization procedure for all access technologies even though authentication is done using different methods.

The specification of how handover within an access network can be performed with the assistance of the approach described in this paper is stated as future work. So is also the definition of how MT_SUToken is updated, making of a thorough security analysis, and finally implementation and testing. References: [1]: IEEE 802.1X-2004, IEEE Standards for Local Area

Networks: Port-Based Network Access Control, 2004.

[2]: IETF, RFC 3748, Extensible Authentication Protocol (EAP), June 2004.

[3]: 3GPP, Technical Specification Group Services and System Aspects; 3G Security; Security Architecture (Release 7), 2006.

[4]: A.S. Merino, Y. Matsunaga, M. Shah, T. Suzuki and R.H. Katz, Secure Authentication System for Public WLAN Roaming, Mobile Networks and Applications 10, 355-370, 2005.

[5]: Liberty Alliance Project, Liberty ID-FF architecture overview, Version 1.2, November 2003.

[6]: G. Krishnamurthi and T. Chan, Using the Liberty Alliance Architecture to Secure IP-level Handovers, 2005.

[7]: M. Schuba, V. Gerstenberger and P. Lahaije, Internet ID – Flexible Re-use of Mobile Phone Authentication Security for Service Access, 2004.

Proceedings of the 10th WSEAS International Conference on COMMUNICATIONS, Vouliagmeni, Athens, Greece, July 10-12, 2006 (pp21-26)