21-07-0387-00-0001 1

IEEE 802.21 MEDIA INDEPENDENT HANDOVER

DCN: 21-07-0387-00-0001

Title: Problem Statement for Authentication Signaling Optimization

Date Submitted: November, 13, 2007

Presented at IEEE 802.21 session #23 in Atlanta

Authors or Source(s): Maryna Komarova (ENST)

Abstract: This contribution provides analysis of applicability of pre-authentication to different use-cases of roaming agreements presence between the serving, target and home networks.

21-07-0387-00-0001 2

IEEE 802.21 presentation release statementsThis document has been prepared to assist the IEEE 802.21 Working Group. It is

offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.

The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.21.

The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual <http://standards.ieee.org/guides/opman/sect6.html#6.3> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html> 

IEEE 802.21 presentation release statementsThis document has been prepared to assist the IEEE 802.21 Working Group. It is

offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.

The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.21.

The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws <http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf> 

21-07-0387-00-0001 3

Outline

• Use cases: handover between two networks of the same media type deployed in different administrative domains;

• Applicability of EAP pre-authentication;• Direct pre-authentication;• Indirect pre-authentication;

• Possible solutions;

• MIIS selection.

21-07-0387-00-0001 4

Use case 3.1

Serving Network

MN

SARA

RA RASAS

SIS

Target Network

TA

TAS

TIS

Home Network

HA

HAS HIS

• A mobile device transitions between two networks of the same media type deployed in different administrative domains.

• There are roaming agreements between the serving and the target network.

• The target authenticator and authentication server trust information forwarded or signed by an entity belonging to the serving network

• Requirements:•Accordingly to these roaming agreements trust relations should be established between the Serving Authenticator (SA) and the Target Authenticator (TA).•Protocols for communication between entities of the MN’s home network and entities of the target network are needed to be defined.

21-07-0387-00-0001 5

Use case 3.2

Serving Network

MN

SA

RA/

No RA RA

SAS

SIS

Target Network

TA

TAS

TIS

Home Network

HA

HAS HIS

• A mobile device transitions between two networks of the same media type deployed in different administrative domains.

• There are no roaming agreements between the serving and the target network

• There are roaming agreements between one of the MN’s home networks and the target network. This situation is possible when the MN has subscriptions in multiples networks

• Requirements•A way in that information about the target network is provided to the MN should be defined.

21-07-0387-00-0001 6

Applicability of EAP pre-authentication

• To optimize the security signaling for the inter-domain handover EAP pre-authentication was proposed [1], [2]. Two modes of EAP pre-authentication are defined: direct pre-authentication and indirect pre-authentication.

• Requirements:• The TA must support pre-authentication;• The ability of TA to support pre-authentication must be

communicated to the MN;• Avoid multiple pre-authentications with the same TA;• Avoid pre-authentication for a MN that has non-expired

authentication session lifetime;• Potential solution:• AAA server defines maximum number of pre-authentication sessions per

MN;• AAA server communicates the authentication session lifetime via pre-

authentication signaling protocol;

– Such a protocol is not defined yet.

21-07-0387-00-0001 7

Direct pre-authentication • The TA accepts direct pre-authentication.

• The SA is not involved in the pre-authentication signaling. The pre-authentication is performed either at L2 or at L3 depending on which layer the TA is deployed.

• If the pre-authentication protocol is defined for a target network technology, the MN requires support from 802.21 in terms of providing information about the TA address and supported pre-authentication mode.

• Vulnerability to DoS attacks:• An attacker it can send numerous pre-authentication requests to the same TA

• This can be mitigated;• An attacker can observe pre-authentication requests arriving in clear and after

that it can impersonate a valid user by sending pre-authentication requests on behalf of him.

• As the attacker is not aware of MN’s credentials, the pre-authentication will fail and the state of the valid MN will change to “unauthorized”.

• When the valid MN will try to perform a fast authentication using the MSK generated as a result of the pre-authentication, it will not have a correspondent authorization and it will execute the full authentication exchange with the TA.

• To eliminate the possibility of described attacks, the indirect authentication proposed in [3] may be implemented.

21-07-0387-00-0001 8

Indirect pre-authentication

• The TA may process pre-authentication requests only from authorized nodes. In case of presence of roaming agreements between the serving and the target networks the serving authenticator can forward pre-authentication requests from the MN to one or many candidate authenticators.

• Requirements:• The infrastructure knowledge sharing and trust relations

establishment are needed between authenticators belonging to different administrative domains.

21-07-0387-00-0001 9

Indirect pre-authentication: Issues

• The SA may be implemented at L2 and the target authenticator – at L3 or vise versa. The pre-authentication problem statement draft [3] specifies that the indirect pre-authentication signaling is performed over L3. • The L2 authenticator generally is not authorized to communicate with

entities in other subnet or administrative domain. Adding functionality to the L2 authenticator leads to increasing the cost of authenticator deployment.

• Requirement: define proxy agent functionality.

• If MN performs indirect pre-authentication via the serving authenticator, the latter must distinguish the pre-authentication requests to be processed from pre-authentication requests to be forwarded to the target authenticator.

• The functionality of SA for indirect authentication is not defined for all access technologies.

21-07-0387-00-0001 10

Roaming agreements use cases

• Roaming agreements specify what network entities may communicate with each other.

• Use case 3.1: roaming agreements are established between the serving and the target networks and either direct (if supported by the TA) or indirect (if supported by both TA and SA) pre-authentication can be performed.

• Use case 3.2: roaming agreements are established between the target and the MN’s home networks. The pre-authentication is possible in direct mode, if this mode is supported by the TA.

21-07-0387-00-0001 11

Roaming agreements use cases: Issues

• Indirect authentication that involves the SA is not possible in use case 3.2 even if the TA supports this pre-authentication mode.

• Possible solution. The AAA protocols (RADIUS and Diameter) can operate in a proxy mode forwarding authentication messages from the MN to the destination AAA server. The MN can perform the pre-authentication via its home network. If such candidate networks were chosen, indirect authentication can be accomplished by splitting pre-authentication signaling to MN – HA and HA – TA signaling. HA defines a dedicated authenticator in the MN’s home network.

• The effectiveness and performance of this approach is needed to be analyzed.

• Requirements. Information provided by the MIIS must contain not only the address of the TA but also the address of the entity that is able to forward pre-authentication packets to the TA. For example, the address of the HA or the authenticator located in the third-party network.

21-07-0387-00-0001 12

Roaming agreements use cases: Issues (2)

• In several scenarios pre-authentication with the target authenticator is not possible. This may happen when:

•The TA does not support direct pre-authentication for security reasons and the SA does not support forwarding of pre-authentication messages from the MN to the TA.•The TA does not support pre-authentication.

Pre-authentication type supported by an authenticatorPossibility of pre-

authenticationTA SA HA*

Direct All modes All modes Yes

Indirect Direct Direct No

Indirect Indirect Direct Yes

Indirect Direct Indirect Yes

Indirect Indirect Indirect Yes*HA may either the home or a third party proxy authenticator. “Indirect” means that some intermediate authenticator is involved in the pre-authentication signalling .

21-07-0387-00-0001 13

Possible solutions: Pre-authentication with AAA server

• The pre-authentication result may be cached on the AAA server and it may be pushed to an authenticator belonging to the same AAA domain.

• IETF HOKEY ERP and pre-authentication can be combined in this case. It is necessary to investigate the performance and deployment cost of this combination.

• Requirements:• AVPs to inform the MN about unexpired session shall be defined [5].• The threshold value for the remaining session lifetime should be

estimated.• The service provider network may be interested to make only one (or a

limited set of authenticators) authenticator publicly accessible for security reasons.

• Issues:• Pre-authentication latency with the target AAA server: If the AAA

server is not located in the access network (Remote AAA server) the RTT between the TA and AS is longer. Real data should be examined.

21-07-0387-00-0001 14

Call flow for authentication with AAA server

Home authenticator

Home AAA server

Target AAA server

Target Authenticator

MN

MSK MSK

21-07-0387-00-0001 15

Call flow for the pre-authentication with the CAS

Administrative domain 2Administrative domain 1

MN CAS2CA3CAS1 CA2CA1

Attached to SA

Pre-authentication

MSK1MSK1 MSK1

Pre-authentication

MSK2MSK2 MSK2

Handovers Becomes SA

Pre-authentication request

MSK2

MSK2

MSK2

Session lifetime is not

expired

Access request

Access rejectSession valid

Session valid

Access request

Push MSK2

Handovers

Keys negotiation

Becomes SA

21-07-0387-00-0001 16

Using a dedicated authenticator for pre-authentication

• For security reasons an administrative domain may define pre-authentication support only for a small subset of authenticators (one at least). This dedicated TA serves to assure pre-authentication between the MN and the AS. When the MN handovers to the TA belonging to the same AAA domain the MSK generated as a result of pre-authentication is pushed to the TA, state of the MN changes to “authenticated” and MN and TA negotiate session keys.

• Requirements:• The entity performing the functionality of an authenticator shall be

defined• The transport between the MN and this authenticator shall be defined.• It is desirable to provide pushing of MSK to the TA before the MN

handovers to the TA (proactive mode). • The mechanism for mapping between addresses of dedicated TA and TA

should be defined.• The authenticator that forwards pre-authentication requests must be

either trusted for the target AS or it must be able to communicate with the AS that can proxy requests to the target AS.

21-07-0387-00-0001 17

Call flow for the pre-authentication with using dedicated TA

MNDedicated

TATarget

ASTA

Access-specific authentication

AAARADIUS/Diameter

Authentication session ID

MSK

Attached to the SA

Authentication session ID

MSK

MN pre-authenticated

Moved to the TA

Authentication session ID

Authentication session ID

MSK

Session keys negotiation

MN authenticated

21-07-0387-00-0001 18

Choosing the MIIS

• Issue: The current 802.21 draft does not specify the location of the MIIS. Such a way, the IS may be located in the serving, candidate or home network or even it can be managed by the third party authority. To choose the set of candidate networks the MN must use only trusted and verified information. Authorities providing IS may compete.

• The MN may receive contradictory or conflicting information.• That is why it is desirable to define some trust rating for IS.

This trust rating may be based on the previous experience: it is positive when the provided information was correct and it is negative if provided information was not correct. For handover decision making the MN chooses the set of IS with the highest rating.

• Is the evaluation of trust to the IS is in the scope of the SG?

21-07-0387-00-0001 19

References

• I-D: draft-ietf-hokey-preauth-ps-01.txt

• 21-07-0122-04-0000-Security_proposal.ppt, “Security Optimization During Handovers: 802.21 SG Proposal”.

• I-D: draft-ietf-hokey-preauth-ps-01

• “Technical Requirements document for MIH Security”, http://www.ieee802.org/21/doctree/Security_SG/21-07-0302-02-0000-MIH_Security_Technical_Requirements_Skeleton.doc.

• I-D: draft-aboba-radext-wlan-00.txt

21-07-0387-00-0001 20

Q&A

Thank you!