1. IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0297-00-0000
Title: Fast re-Authentication Protocol for Inter-Domain Authentication
Date Submitted: September, 11, 2007
Presented at IEEE session #NN in City
Authors or Source(s):
 Maryna Komarova (ENST)
Abstract: This document provides an overview of the Fast re-Authentication Protocol for inter-AAA domain roaming.

2. IEEE 802.21 presentation release statements
This document has been prepared to assist the IEEE 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
The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws < and in Understanding Patent Issues During IEEE Standards Development
IEEE presentation release statements
This document has been prepared to assist the IEEE 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
The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual < and in Understanding Patent Issues During IEEE Standards Development

3. Outline Problem statement Fast re-Authentication
Authentication latency estimation
Ticket acquisition
Conclusions

4. Problem statement Motivation: Mobility - ubiquitous and seamless
Mutual authentication between the network and the user;
Commonly used authentication protocols were designed without taking mobility into consideration;
Real-time applications (VoIP) - handover duration must not be more than 150 ms (ITU TG.102);
Only the authentication phase of the inter-domain handover takes more time (eg., TLS – 300ms);
Inter-domain communication for credentials verification causes unpredictable latencies,
Using of certificates is costly and requires complex maintenance;
Aim:
Decrease the inter-domain authentication latency;
Avoid inter-domain communications during handover;
Define the credentials for inter-domain roaming;

5. Proposed approach
The network serves the client if the client has been successfully authenticated in a partner network;
Proof – the authentication ticket;
Both the home and the current networks can generate tickets for clients;
Consists of two sub-protocols:
ticket acquisition and
fast authentication.

6. Assumptions
The mobile user can roam from one non-partner network to another;
The user terminal is attached to a network and it has performed an initial full authentication;
The target network has roaming agreements either with the user’s home or his current network;
Authorities that have roaming agreements share symmetric or asymmetric keys K= {KR} ;
The user can communicate with the network, where he has been authenticated, in a secure manner;

7. Authentication ticket
C: part in-clear
target_name
issuer_name
expires
S: encrypted part
{auth_res
user_pseudonym
} KR
Signature SHA-256(C|S, KR)
Issued after successful authentication;
May be issued by the home or by the current network;
May be verified only by the issuer and the target network ;
The ticket is bound
to the issuing and the target networks by the usage of the key KR ;
to the user by its pseudonym and the result of the previous authentication;
Ticket size is 286 bytes;
Does not require revocation mechanism;

8. Fast re-Authentication
Based on symmetric cryptography;
Ka is the authentication key, derived from the data contained in the ticket, the random number and the address of the UT’s network interface;
Km is the Master Secret, serves as a material to session keys derivation.
C: part in-clear
target_name
issuer_name
expires
S: encrypted part
{auth_res
user_pseudonym
} KR
Signature SHA-256(C|S, KR)

9. Authentication latency
Experiments on the described test-bed have shown the average authentication latency ms for FAP and ms for TTLS-MD5 under the same conditions

10. Ticket acquisition
Provides a client with credentials for further authentication;
The home FAPS generates tickets for all partners (one ticket for each partner);
The current FAPS generates tickets for its neighboring partners;
Signed and
encrypted
with client’s key

11. Ticket acquisition Two operation modes: proactive and reactive;
A home network creates a neighbor table containing information about the presence of a physical path between its roaming partners;
On the client’s request, the server generates tickets only for the networks neighboring to the current location of the user;
The approach is based on the creation and the use of the neighbor table.

12. Optimized ticket distribution
Ticket for N3 N1
N1: N2, N3, N4
N2: N1
N3: N2, N5, N1
N4: N1
Request N3
Ticket for N1 N3
Request N2 N3 N4 N5
Reactive mode
The UT chooses the target network;
The anchor FAPS responds with a ticket and adds the new entity to the neighbor table;
Proactive mode
The UT is attached to a visited network and it has not chosen the target network;
The anchor FAPS creates tickets for all neighbors of the UT’s current network of attachment.

13. Thank you! Conclusions FAP localizes the authentication process;
Eliminates the need for management of user credentials;
Minimizes communication between different domains
In-session inter-domain communication is steel needed for management and ticket acquisition reasons;
Decreases the authentication latency;
Allows mutual generation of key material;
Easy to implement as the EAP method.
Reduces network load at the ticket acquisition phase and makes it possible to serve a greater number of highly mobile users
Thank you!