RADIUS Extensions for Key Management in WLAN network
draft-xue-radext-key-management-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Li Xue | ||
| Last updated | 2013-02-18 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-xue-radext-key-management-00
Network Working Group L. Xue
Internet-Draft Huawei
Intended status: Informational February 18, 2013
Expires: August 22, 2013
RADIUS Extensions for Key Management in WLAN network
draft-xue-radext-key-management-00
Abstract
In order to guarantee the security and integration of the subscriber
in WLAN network, Pairwise Master Key (PMK) will be generated as an
access authorization token during the mutual authentication procedure
between station (STA) and authenticator server (AS). Then, the PMK
and 4-way handshake are used between STA and Authenticator to derive,
bind and verify the Pairwise Transient Key (PTK), which is a
collection of operational keys for security. Also,Group Transient
Key (GTK) can be derived, and is used to secure multicast/broadcast
traffic. In the authentication architecture, only STA and AS can
manufacture PMK, moreover, AS can only distribute PMK to
Authenticator.However, if the authenticator function is not
collocated with the encryption/decryption function, it is difficult
to achieve traffic encryption/decryption in WLAN network.The purpose
of this document is to analyze the requirement and issue for key
management that have arisen so far during STA authentication process
in WLAN network. Meanwhile, the control messages for key management
are defined.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 22, 2013.
Copyright Notice
Xue Expires August 22, 2013 [Page 1]
Internet-Draft key management via radius February 2013
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4.1. 802.1x/EAP Operation . . . . . . . . . . . . . . . . . . . 5
4.2. Possibility of Authentication Entities in WLAN . . . . . . 7
4.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 9
5. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 10
5.1. PMK Announcement Messages . . . . . . . . . . . . . . . . 11
6. Authentication Procedure . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Xue Expires August 22, 2013 [Page 2]
Internet-Draft key management via radius February 2013
1. Introduction
The Wireless Local Area Network (WLAN) is becoming very popular,
which is used in many industries (the financial, medical, and
manufacturing, etc). It features low cost and flexible network, and
high speed wireless data access with open spectrum. Besides, the
WLAN technology is now used by more and more service operators to
supplement cellular (2G/3G/LTE) network.
In order to enhance the user experience, the perception-free
authentication for WLAN network is preferred. Additionally, for
operators, it is the trend to do unified authentication together with
2G/3G/LTE network, especially for user equipment with (U)SIM.
EAP[RFC3748] based authentication methods are widely deployed in WLAN
network. EAP is end-to-end transport for authentication framework
between Supplicant and Authentication Server (AS).
Based on the WLAN security requirements mentioned in [IEEE-802.11i],
keying material used for encryption and integrity algorithms must be
obtained in the uniform authentication procedure. Fortunately,
802.11i implements a key derivation/management regime. During the
mutual authentication procedure between STA and AS, Pairwise Master
Key (PMK) will be generated as a side effect. The PMK,which is a
fresh symmetric key. Then, the PMK and 4-way handshake
[IEEE-802.11i]are used to derive, bind and verify the Pairwise
Transient Key (PTK), which is a collection of operational keys for
secure between STA and encryption/decryption node. Also,Group
Transient Key (GTK) can be derived, and is used to secure multicast/
broadcast traffic between STA and encryption/decryption node.
In the authentication architecture, only STA and AS can manufacture
PMK, moreover, AS distributes PMK to to Authenticator.However, if the
authenticator function is not collocated with the encryption/
decryption function, it is difficult to achieve traffic encryption/
decryption in WLAN network.For example, the authenticator is deployed
on Gateway (GW) node, whereas, the encryption/decryption node always
WTP or AC.The purpose of this document is to analyze the requirement
and issue for key management that have arisen so far during
authentication process in WLAN network. Meanwhile, the control
messages for key management are defined.
The specification described in this document is applicable if
authenticator function is not collocated with the encryption/
decryption function in WLAN. It is recommended for WLAN network
deployment as informational.
Xue Expires August 22, 2013 [Page 3]
Internet-Draft key management via radius February 2013
2. Requirements Language
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 [RFC2119].
3. Terminology
This document uses the following terminologies.
Wireless Termination Point (WTP)
The physical or logical network entity that contains an RF antenna
and wireless physical layer (PHY) to transmit and receive station
traffic for wireless access networks. This definition has the same
meaning used in [RFC4118].
Access Controller (AC)
The network entity that provides WTP access to the network
infrastructure in the data plane, control plane, management plane, or
a combination therein, as defined in [RFC4118]
Authentication Server(AS)
An entity that provides an authentication service to an
authenticator. This service determines, from the credentials
provided by the Supplicant, whether the Supplicant is authorized to
access the services provided by the system in which the authenticator
resides. AS is generally located on the backend AAA server.
Authenticator
An entity that facilitates authentication of other entities attached
to the same LAN. The term authenticator is also used in [RFC3748],
and has the same meaning in this document.
Gateway (GW)
A device in operator access network, who can charge the subscriber
authentication. It maybe BRAS (Broadband Remote Access Server) or
BNG (Broadband Network Gateway).
Supplicant
A device at one end of a point-to-point LAN segment seeks to be
authenticated by an Authenticator. It is the same as the Peer
Xue Expires August 22, 2013 [Page 4]
Internet-Draft key management via radius February 2013
defined in [RFC3748]. The supplicant is station (STA) in WLAN
network. It can be user equipment (UE) device. We can also call the
supplicant as subscriber.
Station (STA)
A device that contains an interface to a wireless medium. User
equipment (UE) with (U)SIM is one type of STA. In authentication
procedure, STA is deployed as the Supplicant.
Pairwise Master Key (PMK)
PMK is a fresh symmetric key controlling STA's and the encryption/
decryption node (WTP or AC) access to 802.11 channel during the
session.
Pairwise Transient Key (PTK)
PTK is used to encrypt/decrypt unicast traffic for supplicant, which
is derived from the 4-way handshake [IEEE-802.11i].
Group Temporal Key (GTK)
GTK is used to encrypt/decrypt multicast/broadcast traffic for
supplicant, which is derived from the 4-way handshake[IEEE-802.11i].
4. Problem Statement
4.1. 802.1x/EAP Operation
As a generic authentication framework, EAP[RFC3748] can be used
combined with some payload protocols. In WLAN network, EAP is
carried over authentication protocol such as RADIUS
[RFC2865][RFC2866][RFC3579]. An example for end-to-end EAP procedure
in context of WLAN is shown as following figure 1.
Xue Expires August 22, 2013 [Page 5]
Internet-Draft key management via radius February 2013
Authenticator
Supplicant Authenticator Server
+-------+ +-------+ +-------+
| | | | | |
| | | | | |
| | | | | |
+-------+ +-------+ +-------+
| | |
|802.1x/EAP-Request Identity |
|<-------------------------+ |
|802.1x/EAP-Response Identity |
| (EAP type specific) | |
|------------------------->| RADIUS Access |
| | Request/Identity |
| +------------------------->|
| EAP type specific |
| mutual authentication |
|<-------------------------o------------------------->|
| | |
| | Radius Accept(with PMK) |
| |<-------------------------+
| 802.1x/EAP-Success | |
|<-------------------------+ |
| | |
Figure 1 802.1x/EAP Operation
In the 802.1x/EAP authentication framework, there are three entities
acting as follows.
o Supplicant: The end of the link that responds to the
authenticator, as well same meaning as the peer mentioned in
[RFC3748] . In this document, STA is one type of supplicant, it
could be User equipment (UE) with (U)SIM ,etc.
o Authenticator: An entity that facilitates authentication of other
entities attached to the same LAN, defined in[RFC3748]. In the
existing WLAN, whichever WTP, AC or Service Gateway could be
deployed as Authenticator based on operator's requirement.
o Authenticator Server: An entity that provides an authentication
service to an authenticator. This service determines, from the
credentials provided by the supplicant, whether the supplicant is
authorized to access the services provided by the system in which
the authenticator resides. As mentioned in [IEEE-802.1X], the
Xue Expires August 22, 2013 [Page 6]
Internet-Draft key management via radius February 2013
Authentication Server function can be co-located with an
Authenticator, or it can be accessed remotely via a network to
which an Authenticator has access. In this document, we assume
the Authenticator server isn't co-located with the Authenticator.
Always, AAA server is the Authenticator Server.
Actually, there are several possibilities of entities deployment in
WLAN, especially the Authenticator. Also sometimes the authenticator
is a standalone device which doesn't support encryption/decryption
function. In the next sub-section, the possibilities of entities
deployment in typically WLAN are described .
4.2. Possibility of Authentication Entities in WLAN
Based on the WTP type in WLAN, which is an intelligent device or a
little more than radio-for-wire media converter, some industry
analyses have oversimplified the WLAN architecture into two
categories. They are WTP autonomous management architecture and WTP
centralized management architecture. The previous type of WTP is
also called as "FAT AP". The FAT AP is a standalone device
responsible for all WLAN functionality, such as encryption/
decryption, authentication, etc. Instead, the other type of WTP is
always defined as FIT AP. The FIT AP is a radio-for-wire media
converter. The WTPs will be managed by Access Controller (AC).
In the autonomous architecture, each of the WTPs is managed by itself
independently, as shown in Figure 2.
In this case, the authentication entities is deployed as:
o Supplicant: STA
o Authenticator: WTP, also providing encryption/decryption function.
o AS: AAA server as general.
+------+ +------+ +------+ /-------\
| | | | | PE/ | | |
| STA | /-/ | WTP +-------------+ GW +----+ Service |
| | | | | | | |
+------+ +------+ +------+ \-------/
Figure 2 Autonomous Architecture
Comparatively, in the centralized management architecture, WTPs have
less functions and added Access Controller (AC) is responsible for
configuration, control and management of WTPs. The 802.11 function
Xue Expires August 22, 2013 [Page 7]
Internet-Draft key management via radius February 2013
splits between WTP and the Access Controller (AC) in this
architecture.Figure 3 shows an example of a centralized management
network.
In this case, the authentication entities is deployed as:
o Supplicant: STA
o Authenticator: WTP/AC/GW, but only WTP/AC can provide encryption/
decryption function.
o AS: AAA server as general.
+------+
| |
| AC |
| |
+--+---+
|
|
|
+------+ +------+ +--+---+ /-------\
| | | | | PE/ | | |
| STA | /-/ | WTP +--------------+ GW +----+ Service |
| | | | | | | |
+------+ +------+ +------+ \-------/
Figure 3 Centralized Architecture
As described in previous section, only authenticator can obtain the
PMK during the authentication. Meanwhile the PMK and 4-way handshake
[IEEE-802.11i]are used to derive, bind and verify the Pairwise
Transient Key (PTK), which is a collection of operational keys for
secure between STA and encryption/decryption node. Also,Group
Transient Key (GTK) can be derived, and is used to secure multicast/
broadcast traffic between STA and encryption/decryption node. In the
centralized architecture, if the authenticator function is deployed
on GW node, not collocated with the encryption/decryption function,
it is difficult to achieve traffic encryption/decryption in WLAN
network.
Actually, it is a general case in existing network because AC isn't
intelligent enough to aggregate all the WLAN critical functions in
one. Consequently, It is a popular scenario to split the
authentication function from AC to GW, which is the existing
authentication gateway for other service, such as PPP, etc. This
enables a better environment that diminishes the software and
Xue Expires August 22, 2013 [Page 8]
Internet-Draft key management via radius February 2013
hardware upgrade for operator. In this scenario, the issues for key
management arises. For the following discussion, the problem
statement is introduced for key management during STA's
authentication process in centralized architecture.
4.3. Problem Statement
Pairwise Master Key (PMK) will be generated as an access
authorization token during the mutual authentication procedure
between STA and AS to guarantee the security requirement in WLAN.
Then, PTK and GTK will be generated via PMK and 4-way
handshake[IEEE-802.11i]. PTK/GTK is used to secure STA's unicast/
(broadcast/multicast) traffic between STA and ecryption/decryption
node, which could be WTP or AC.
Unfortunately, in exiting authentication procedure, authenticator is
the only node which can obtain the derived PMK,except of STA and AS.
In addition, authenticator is not always deployed collocated on
ecryption/decryption node. That is to say, WTP/AC cannot implement
STA's traffic encryption/decryption because of lacking the PMK
information. In this case, mechanism is needed to inform the PMK to
ecryption/decryption node, WTP or AC in WLAN.
In practice, this case is likely to happen in WLAN. Sometimes, AC in
the existing network, kind of enterprise device, isn't the high
intelligent devices to aggregate all the WLAN critical intelligent
function in one. For operator, it is costly in large-scale ungraded
deployment. As result, authentication is always deployed on GW node
instead of AC. Fortunately, the GW node is the potential node for
authentication in real network for other subscriber such as PPP, etc.
It is good at Authenticator function. This enables a better
environment that diminishes the software and hardware upgrade risks .
Based on the above analysis, because of lack the initial fresh
symmetric key for encryption/decryption, it is challenge for WTP/AC
to control the 802.11 channel with STA, as shown in figure 4. The
problem must be resolved.
Xue Expires August 22, 2013 [Page 9]
Internet-Draft key management via radius February 2013
Authenticator
Supplicant Authenticator Server
+-------+ +----+ +----+ +-------+ +-------+
| | | | | | | | | |
| STA | | WTP| | AC | | GW | | AAA |
| | | | | | | | | |
+-------+ +----+ +----+ +---+---+ +-------+
|
| | |
|802.1x/EAP-Requesr Identity | |
|<------------------------------+ |
|802.1x/EAP-Response Identity | |
| (EAP type specific) | |
|------------------------------>| RADIUS Access |
| | Request/Identity |
| +------------------------->|
| EAP type specific |
| mutual authentication |
|<------------------------------o------------------------->|
| | |
| | Radius Accept(with PMK) |
| |<-------------------------+
| 802.1x/EAP-Success | |
|<------------------------------+ |
| | |
Figure 4 Authentication procedure when GW deployed as Authenticator
5. Protocol overview
Based on the analysis above, it is recommended that control messages
used for PMK transported from GW to WTP/AC in order to support
encryption requirement between STA and WTP/AC when GW is the
Authenticator.
If AC is the encryption/decryption node, the GW can send the PMK to
AC via these control messages. If WTP is the encryption/decryption
node, the GW can use send the PMK to AC as well, then AC sends the
obtained PMK to AP via protocol defined in [RFC4564]. The control
messages between GW and AC is defined in this version. The purpose
of this section is to provide control procedure and packet definition
for key management in centralized architecture. Moreover, the
control messages must fix the issues without creating
incompatibilities with deployed implementation.
As we know, RADIUS attributes are comprised of variable length Type-
Xue Expires August 22, 2013 [Page 10]
Internet-Draft key management via radius February 2013
Length-Vaule 3 tuples. New attribute values can be added without
disturbing existing implementation of the protocol. RADIUS packet is
one option.This document describes the RADIUS attributes supporting
the key transmit between GW (Authenticator) and WTP/AC. Specially,
RADIUS commands (Key-of-Announcement, KoA-ACK/NAK) are defined in
order to enable PMK to be send from Authenticator (GW) to AC. These
extended commends trigged by the RADIUS Accept message during
authentication procedure.New RADIUS attributes for PMK announcement
are described.
The PMK announcement packets contain PMK derived by AS during the
authentication procedure. Typically, this is used to achieve PMK
announcement from GW to AC. Based on the exchanged keying material,
the traffic security and integration requirement between STA and
WTP/AC can be fixed.
The PMK Announcement packets are defined as below.
5.1. PMK Announcement Messages
Authenticator
+---------+ +---------+
| | | |
| | | |
| WTP/AC | | GW |
| | | |
+---------+ +---------+
| |
| KoA Message |
|<--------------------------------------|
| |
| |
| |
| KoA ACK/NAK Message |
|-------------------------------------> |
| |
| |
| |
| |
Figure 5 PMK Announcement Messages
During the authentication procedure, when GW obtains the PMK key via
RADIUS Accept Message from AS, the GW initiates the KoA message and
send to AC. The AC responds the KoA message with KoA-ACK if the AC
is able to successfully get the PMK for the subscriber, or KoA-NAK if
the PMK announcement fail.
Xue Expires August 22, 2013 [Page 11]
Internet-Draft key management via radius February 2013
The packet format is the general RADIUS. Fortunately, Change-of-
Authorization Messages (CoA) have defined in [RFC3576], which is have
similar mechanisms. The PMK messages is similar as, [RFC3576] ,
which is shown as follows
The packet format is shown as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 6 PMK Announcement Message Format
Code
The Code field is one octet, and identifies the type of RADIUS
packet. RADIUS codes for this document are assigned as follows.
Packets with an invalid Code field must be silently discarded.
o 100 - Key-of-Announcement
o 101 - KoA-ACK
o 102 - KoA-NAK (optional)
Identifier
The Identifier field is one octet, and aids in matching requests and
replies. This value is set by GW in this specification when GW sends
the KoA message to AC. It is used to identifier a pair of KoA and
KoA-ACK/NAK message.The Identifier field must be changed by GW
whenever a valid reply has been received for a previous request.
Authenticator
The same as defined in [RFC3576].
The following attributes should be included in PMK Announcement
messages.
Xue Expires August 22, 2013 [Page 12]
Internet-Draft key management via radius February 2013
o Calling-Station-Id. This attribution is used to take the STA
identifier, for example MAC address. It can be used to bind the
PMK to a special STA. The call-station-id attribute may be
included within KoA, KoA-ACK/NAK messages. The values are shown
below.
Type
31 as defined in [RFC5176].
Length
8
Value
The Value field is 6 octets, containing the STA MAC address.
o Keying-Material, shown as follows. This attribute is used by GW
to transport PMK to AC. The Keying-material attribute may be
included within KoA-ACK/NAK messages. The format is shown below.
0 1 2 3 4
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 | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 Keying-Material Attribute Format
Type
The type could be an unassigned type right now. In this
specification, type 17 is recommended.
Length
34
Value
The Value field is 32 octets, containing the PMK information.
Xue Expires August 22, 2013 [Page 13]
Internet-Draft key management via radius February 2013
o KoA-Feedback, shown as follows. It is responsible to provide the
feedback when AC receives the KoA command from GW. The KoA-
Feedback attribute may include within KoA-ACK/NAK messages. The
format is shown below.
0 1 2 3 4
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 | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 KoA-Feedback Atrribute Format
Type
The type could be an unassigned type right now. In this
specification, type 21 is recommended. Considering the
compatibility, the type 18 can also be used here defined in
[RFC2865].
Length
4
Value
The Value field is 2 octets, containing the feedback from the AC when
received the KoA message.In this version, only two value is defined.
o 0 Succeed
o 1 Reject, can be used as KoA-NAK .
6. Authentication Procedure
Based on the control message definition, the recommended procedure is
shown as follows if the AC is the encryption/decryption node.
Xue Expires August 22, 2013 [Page 14]
Internet-Draft key management via radius February 2013
Please view in a fixed-width font such as Courier.
Authenticator
Supplicant Authenticator Server
+-------+ +----+ +-------+ +-------+
| | | | | | | |
| MH | | AC | | GW | | AAA |
| | | | | | | |
+-------+ +-+--+ +---+---+ +-------+
| |
| | | |
|802.1x/EAP-Requesr Identity | | ~~~~
|<------------------------------+ | ^
|802.1x/EAP-Response Identity | | |
| (EAP type specific) | | |
|---------------+-------------->| RADIUS Access |
| | | Request/Identity |
| | +------------------------->| 1
| |EAP type specific |
| mutual authentication |
|<------------------------------o------------------------->| |
| | | | |
| | | Radius Accept(with PMK) | v
| | |<-------------------------+
| 802.1x/EAP-Success | | ~~~~
|<------------------------------+ |
| | | |
| | 2 KoA | |
| |<==============+ |
| | | |
| |3 KoA ACK/NAK | |
| +==============>| |
| | | |
Figure 9 Authentication Procedure
1 Mutual authentication procedure as general defined in
[RFC3748][IEEE-802.1X].
2 After EAP authentication completes, the GW works as Authenticator
initiates and transmits the KoA packet to AC. It is desirable to
provide keying information needed based on [IEEE-802.11i].To
accomplish this, the KoA message contains the attributes to provide
the PMK to AC.
3 AC should interpret the receipt of the Keying-material attribute
Xue Expires August 22, 2013 [Page 15]
Internet-Draft key management via radius February 2013
within the KoA message as an indication that the server has
successfully authenticated the STA. Additionally, the derived PMK
during authentication can be used with 4-Way Handshake to derive,
bind, and verify PTK or GTK. The 4-way handshake procedure is
defined in IEEE, which is out of the scope.
7. IANA Considerations
TBD
8. Security Considerations
Right now, the AS is only trusted to transport PMK to the
Authenticator which was established with the supplicant. So if the
Authenticator need to announce the PMK to the third parities, except
the supplicant, the security must be guaranteed between the GW and
the AC for key announcement. It can be achieved by IPsec tunnel or
MD5 encryption/decryption algorithm.
9. Normative References
[IEEE-802.11i]
"Institute of Electrical and Electronics Engineers,
"Unapproved Draft Supplement to Standard for
Telecommunications and Information Exchange Between
Systems-LAN/MAN Specific Requirements -Part 11: Wireless
LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications: Specification for Enhanced Security" "",
September 2004.
[IEEE-802.1X]
"Institute of Electrical and Electronics Engineers, "Local
and Metropolitan Area Networks: Port-Based Network Access
Control"", September 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Xue Expires August 22, 2013 [Page 16]
Internet-Draft key management via radius February 2013
Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 3576,
July 2003.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy
for Control and Provisioning of Wireless Access Points
(CAPWAP)", RFC 4118, June 2005.
[RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang,
"Objectives for Control and Provisioning of Wireless
Access Points (CAPWAP)", RFC 4564, July 2006.
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176,
January 2008.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
Author's Address
Li Xue
Huawei
No.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,
Beijing, HaiDian District 100095
China
Email: xueli@huawei.com
Xue Expires August 22, 2013 [Page 17]