Internet DRAFT - draft-goswami-aaa-mipv4-wlan-auth
draft-goswami-aaa-mipv4-wlan-auth
INTERNET-DRAFT Subrata Goswami
Expires March 12, 2003 Consultant
October 13, 2002
DIAMETER Application for Mobile-IPv4 and 802.11 Authentication
<draft-goswami-aaa-mipv4-wlan-auth-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119].
Abstract
This document describes a single way to perform both Mobile-IPv4
and 802.11 authentication and key exchanges. Diameter Mobile-IPv4
Application can be used to consummate message sequences for both
802.11 and Mobile IPv4. It is possible to replace the currently
proposed 802.1x Authentication/key-exchange with Diameter
Mobile-IPv4 Application.
1. Overview and Rationale
In the 802.11 wireless LAN [WiFi] network an 802.11 client connects to an
802.11 Access Point (AP) at the link layer. 802.11 provides a mechanism to
achieve handoffs between AP's and the client. A 802.11 client first
authenticates and then associates with one AP. When the 802.11 client
decides that it is better to move to a second AP, it can do a
re-association with the second AP.
Similarly when a Mobile-IPv4 (MIP4) client moves from subnet to subnet, it
seeks a Foreign Agent (FA) situated in the subnet and registers with the FA.
The IP packet sent in Registration Message has the Home IP address as the
source, and the destination address can be the FA's IP address or the "All
Mobility Agents" multicast address 224.0.0.11. The FA then responds with
Registration Reply message. The Registration Message also includes
Authentication Extensions. A significant hurdle in deployment of MIPv4 has
been the distribution and management of the security association between MN-HA,
FA-HA, and MN-FA. Recently a method, Diameter Mobile IP v4 Application
(DIMPA), has been suggested by which all these 3 different keys can be
generated dynamically from a single shared secret between the MN and a
AAA agent [DIMPA]. This DIMPA provides in addition to its core
accounting functionality.
As mentioned in a previous draft [SIMIP], there is substantial overlap
between what 802.11 and MIPv4 do during their respective registration
phases. As pointed out in that draft it is possible to nest these operations
and thus reduce the number of messages that need to be exchanged between
the MN and the infrastructure. The same issues of overlapping work between
the 802.11i authentication phase and DIMPA registration arises.
The situation of non co-located FA is primarily considered here, although a
brief discussion of co-located FA is also provided. Also, we will only
consider 802.11 infrastructure mode networks.
2. 802.11 Network Architecture.
A hypothetical IP over 802.11 network is shown in the following figure.
The mobile client, MN, can move from subnet X1 to X3 and from AP2 to AP3.
[FA1]-[AAAF1]
|
... [AP1]-------[X1]-|
[MN]... | |
[AP2]---- |----[X]-----> [HA]---[AAAH]
|
[AP3/FA3]---[X3]-|
|
[AAAF3]
[MN] - Mobile Node
[FA] - Foreign Agent
[HA] - Home Agent
[AAAH/F] - Home/Foreign AAA Agent
[AP] - Access Point
[X] - IP Router
... - 802.11 link
--- - 802.3 link
Figure 1: 802.11 Network with AAA Agents
When the MN moves from AP1 to AP2, it first Authenticates with AP2 and then
Dissociates with AP1 at the 802.11 link layer. As the move from AP1 to AP2
occurs within the same subnet, hence the MN is still served by the same FA
and the same AAAF. When the MN moves from AP2 to AP3 it is served by a
different set of FA and AAAF, FA3 and AAAF3 respectively.
3. Message Sequence
The following figure shows the what happens when MN moves from AP2 to
AP3. During the AP1 to AP2 handoff, the MN is in same subnet, hence MIPv4
registration is not required, although 802.1x key-exchange is required.
Figure 2 depicts the messages exchanged between the MN and the infrastructure.
Here the AAAF is assumed to be a RADIUS entity in addition to being a
DIAMETER [DIM] entity. This particular figure depicts the situation
when 802.11 pre-authentication is not done.
We will first consider the scenario when 802.11 pre-authentication is
not done [WiFiTGi]. Then we will discuss the scenario with
pre-authentication.
MN AP2 AP3 FA3 AAAF3 AAAH HA
<--- 802.11 Data ------>
-- 802.1x EAP Start--------------->
<- 802.1x EAP Req-Id---------------
-- 802.1x EAP Res-Id-------------->
--RADIUS Acc-Req--->
----------->
<-----------
<-RADIUS Acc-Cha----
<-- 802.1x EAP Req 1--------------
--- 802.1x EAP Res 1------------->
--RADIUS Acc-Req(1)->
<-RADIUS Acc-Res(1)--
.
.
<-RADIUS Acc-Acp/Rej--
<--802.1x EAP Suc/Fal-------------
<--802.1x Install Keys------------
-- 802.1x Key Install status----->
---802.1x EAPOL Key Msg --------->
(w/ nonce1)
<---802.1x EAPOL Key Msg ---------
(w/ nonce2 and MIC)
----802.1x EAPOL Key Msg -------->
(w/ nonce1 and MIC, Install)
<---802.1x EAPOL Key Msg ---------
(w/ nonce2 and MIC, Install)
-- 802.11 Dissoc-Req---->
----- MIPv4 Reg-Req w/MN-AAA ----------->
--AAA AMR->
Session-Id=sid1
--AAA AMR->
sid1
---HAR------>
sid1
<--HAA-------
sid1
<---AAA AMA-
sid1
<-AAA AMA-
sid1
<---- MIPv4 Reg-Res---------------------
Figure 2. 802.11 and MIPv4 message sequences in series.
As can be seen in Figure 2, the 802.11 link layer key-exchange is done
through the 4-way handshake is implemented using EAPOL-Key messages [TGi] after
the authentication. "The 4-way handshake confirms the liveness of the STAs
communicating directly with each other over the 802.1l link, guarantees the
freshness of the their shared session key, and synchronizes the usage of the
key to secure the 802.11 link" [TGi].
4. When 802.11 Pre-authentication is not used
On the surface it looks as if the 802.1x based authentication/key-exchange
and DMIPA share a number of common messages. Both message sequences
do authentication ?f the MN first and then do key exchanges. So it should
be possible to combine both of them into a single message sequence. In a
previous draft [SIMIP], it was suggested MIPv4 registration messages can be
carried as Information Elements (IE) in 802.11 Association/Reassociation frames.
Here the same IE's can be used. DIMPA provides an Attribute Value Pair (AVP)
called the MIP-MN-AAA-Auth AVP, which identifies the MN's security association
with the Home AAA agent (AAAH). The MIP-MN-AAA-Auth AVP is constructed
from the MIPv4 Registration Request containing the Mobile IP Authentication
extension with the MN-AAA Authentication subtype [MIPCR,DMIPA]. DIMPA constructs
all the MIPv4 keys and distribute them. So it is a simple incremental task for
DIMPA to generate one more key (RC4 40 or 104 bit for TKIP [WiFiTGi]) to share
between MN an AP. The following figure, Figure 3., shows a message sequence
for using DIMPA for both 802.11 and MIPv4 authentication and key-exchange.
MN AP2 AP3 FA3 AAAF3 AAAH HA
<--- 802.11 Data ------>
----- 802.11 Associate with------->
(MIPv4 Reg-Req w/MN-AAA)
----------> MIPv4 Reg-Req w/MN-AAA
--AAA AMR->
Session-Id=sid1
--AAA AMR->
sid1
--HAR---->
sid1
<-HAA-----
sid1
<---AAA AMA-
sid1
<-AAA AMA-
sid1
<--------- MIPv4 Reg-Res w/MIPv4 Auth Extensions
<---- MIPv4 Reg-Res---------------------
(MIPv4 Reg-Req w/MIPv4 Auth Extensions)
Figure 3. DIMPA based combined 802.11/Mobile-IP authentication
5. When 802.11 Pre-authentication is used
In 802.11 pre-authentication is used for fast handoff, here the MN collects
a list of all the AP's it can hear from, through beacon frames or through
probe response frames, and the authenticates with a number of them without
associating with any [PREAUTH]. After association, the AP starts forwarding
frames for the MN.
Pre-authentiation is handled through pre-registration in MIPv4, which is
described in section 5.3. A MIPv4 Pre-Registration Request/Reply is same
as MIPv4 Registration Request/Reply with the following differences, contains
a new MIPv4 extension called the Pre-Reg Extension which is followed by the
MN-HA Authentication Extension.
5.1 The Pre-Reg Extension
A new Mobile IP extension, called the Pre-Reg Extension,
is defined to indicate to the FA/HA/AAF/AAH that this registration is only for
key-exchange, the HA and FA MUST not re-route traffic if the Pre-Reg
Extension is present. The following figure shows the Pre-Reg
Extension, it is a MIPv4 Long Extension.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Items |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Items |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Pre-Reg Extension
Type ? TBD (non skippable)
Subtype A number assigned to identify the way in
which the List of Items is to be used by the
mobility and AAA agents.
Length The 16-bit Length field indicates the length of
the extension in bytes. It is equal to the number
of bytes in the Authenticator, List of Items plus
4 (for the Number of Items field).
Number of Items The number of items in List of Items.
List of Items The List of Items contains a list of items
(e.g. IP Address)
Subtype 0:
In Pre-Registration Request a Pre-Reg contains a list of FA IP
addresses with which the MN as all ready pre-registered. In a Pre-Registration
Reply, the Pre-Reg MUST contain only the IP address of the FA.
An MN-HA Authentication Extension MUST follow this extension.
Subtype 1:
In a Registration Request the presence of this extension indicates to the
FA that the MN has all ready Pre-Registered.
An MN-FA Authentication Extension MUST follow this extension.
Subtype 2-255 are reserved.
5.2 The MIP-Pre-Reg AAA AVP
A corresponding AAA AVP is defined that carries the Pre-Reg
Extension in AMR/AMA and HAR/HAA. The following figure shows the Pre-Reg
AVP. The AVP Code is 1001 (tentative) and the value is the MIP Pre-Reg
extension.
5.3 Message Sequence
The messages sequence for pre-authentication is shown in Figure 4, which is
same as Figure 3 except that the MIPv4 IE in the 802.11 Association Request/Reply
does not contain a MN-HA Key Request/Response Extension. Several pre-registration
may precede a registration.
MN AP2 AP3 FA3 AAAF3 AAAH HA
<--- 802.11 Data ------>
--- 802.11 Pre-Auth Req with------>
(MIPv4 Pre-Reg-Req w/MN-AAA+Pre-Reg Subtype 0)
----------> MIPv4 Pre-Reg-Req w/MN-AAA
--AAA AMR->
Session-Id=sid1
--AAA AMR->
sid1
--HAR---->
sid1
<---------->
(Key exchange*)
<-HAA-----
sid1
<---AAA AMA-
sid1, MN-HA+MN-FA+HA-FA+MN-AP Key AVP
<-AAA AMA-
sid1, MN-HA+MN-FA+HA-FA+MN-AP Key AVP
<-------- MIPv4 Pre-Reg-Res
MN-HA+MN-FA+HA-FA+MN-AP MIPv4 Auth Extension
| Install MN-AP key in AP
<---- MIPv4 Pre-Auth-Res-------------
(MIPv4 IE Pre-Reg-Res w/+Pre-Reg Subtype 0)
(MN-HA+MN-FA+HA-FA+MN-AP MIPv4 Auth Extension in IE)
.
.
----- 802.11 Associate with------->
(MIPv4 Reg-Req w/MN-FA and Pre-Reg Subtype 1)
Figure 4. DIMPA based combined 802.11/Mobile-IP pre-auth/pre-reg
The Key AVP's are secured by the MN-AAA security credential. The HA,FA, and AP
gets their copy of the session key through IPSec or TLS or CMS secured
connections [CMS,DIM]. IPSec and TLS are manually configured, hence are not
very scalable. Cryptographic Message Syntax (CMS), is the method used to
secure MIME (S/MIME) messages. CMS was designed to allow Diameter
implementations to use existing S/MIME tools and thu? .
How the keys are exactly distributed would provided in a later version of this
draft.
6. New IE, AVP, Mobile IP Extensions.
6.1 New Information Elements in 802.11 Management Frames
No new IE is required except those mentioned in [SIMIP].
6.2 New Diameter AVP's
6.2.1 MIP-MN-to-AP-Key AVP
A new Diameter AVP is defined for the AP-to-MN key, MIP-MN-to-AP Key.
The MIP-MN-to-AP-Key AVP (AVP Code 1002) is of type Grouped, and
contains the mobile node's key material, which it uses to derive the
session key it shares with the AP. The home agent uses
this AVP in the construction of the Mobile IP "Unsolicited MN-FA Key
from AAA Subtype" extension [MIPKEYS]. The SPI in the extension's FA
SPI field is allocated by the home agent, but it SHOULD take into
consideration the SPI requested by the mobile node in the "MN-FA Key
Request From AAA Subtype" extension.
MIP-MN-to-AP-Key ::= < AVP Header: 1002 >
{ 80211-Algorithm-Type }
{ 80211-Key-Material }
{ 80211-MN-AAA-SPI }
* [ AVP ]
6.2.2 MIP-Pre-Reg AVP
Another new AVP, MIP-Pre-Reg, as mentioned in section 5.2 is also defined.
6.3 Mobile IP Extensions
A new MIPv4 extension, Pre-Reg Extension, is required as defined in section 5.1.
Another new MIPv4 Authentication Extension is required for transporting the
MN-AP key to the AP from the FA.
7. Mobile Entity Implications
There are some implications for the different mobile entities involved.
7.1 Implications for MN (STA)
The MN should be capable of passing the MIPv4 information to the 802.11
driver and vice-versa. At the instant the MN is ready to send an
Association Request it should be able to access the MN's Mobile-IPv4
attributes. Similarly, when the MN receives an Association Response there
should be a mechanism to change the Mobile-IPv4 attributes in MN.
The MN (or the 802.11 STA) should be provide a new Authentication Suite
called DMIPA in the Robust Security Network (RSN) Information Element in
the TGi spcification. Tentatively a value of 3 is assigned to it.
7.2 Implications for 802.11 AP
The 802.11 AP should be able to extract/include the MIPv4-802.11 IE's.
7.3 Implications for FA
To be added
7.4 Implications for AAAH
To be added
7.5 Implications for AAAF
To be added
8. Co-located FA
To be added.
9. Miscellaneous
To be added
10. Acknowledgments
All the RFC's, ID's, freely available 802.11 standards. Dr. Bernard Aboba for
many useful pointers and Mr. Aditya Agarwal for several discussions.
11. References
[WiFi] IEEE, "Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications", 1999.
[MIPv4] Perkins, C., "IP Mobility Support", RFC 3220, January 2002.
[WiFiTGi] IEEE, "802.11i Draft 2.3", 2002.
[DIM] Calhoun, P et. al.,
"Diameter Base Protocol", draft-ietf-aaa-diameter-12.txt, July 2002.
[DMIPA] Calhoun, P. et. al., "Diameter Mobile IPv4 Application",
draft-ietf-aaa-diameter-mobileip-12.txt, August 2002.
[SIMIP] Goswami,S., "Simultaneous Handoff of 802.11 and Mobile IPv4",
draft-goswami-mobileip-simultaneous-handoff-v4-01.txt, September 2002.
[MIPCR] Perkins,C., et.al., "Mobile IPv4 Challenge/Response Extensions",
November 2000.
[PREAUTH] Aboba, B, "IEEE 802.1x Pre-authentication", IEEE 802.11-02/389r0,
June 2002.
[CMS] Calhoun,P. et. al., "Diameter CMS Security Application",
draft-ietf-aaa-diameter-cms-sec-05.txt, April 2002.
8. Author's Address
Subrata Goswami, Ph.D.
Consultant
Newark, CA 94560
sgoswami@umich.edu
This document expires March 12, 2003.
