RADIUS Extensions for Key Management in WLAN network
draft-xue-radext-key-management-02
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".
|
|
|---|---|---|---|
| Authors | Li Xue , Dacheng Zhang , Bo Gao | ||
| Last updated | 2014-02-12 | ||
| 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-02
Network Working Group L. Xue
Internet-Draft D. Zhang
Intended status: Informational Huawei
Expires: August 14, 2014 B. Gao
China Telecom
February 10, 2014
RADIUS Extensions for Key Management in WLAN network
draft-xue-radext-key-management-02
Abstract
When a mobile device (referred to as Station (STA) in this work)
tries to connect to a Wireless Local Area Network (WLAN), it needs to
first perform mutual authentication with the EAP server of the
network. As a result of successful authentication, a Pairwise Master
Key (PMK) will be generated, and distributed to the STA and the
Authenticator of the network by the EAP server respectively. The PMK
is used for securing the subsequent communications between the STA
and the Wireless Termination Point (WTP) it attaches to. In
practice, the authenticator may not be deployed on the WTP. In this
case, an approach is required to help the WTP to obtain the PMK.
This work tries to discuss the issues related with this topic and
proposes a RADIUS extension to address the problem.
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 14, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Xue, et al. Expires August 14, 2014 [Page 1]
Internet-Draft key management via radius February 2014
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. EAP in WLAN . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Motivation Scenario . . . . . . . . . . . . . . . . . . . . . 5
6. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 7
6.1. RADIUS Commands for PMK Transportation . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
WLAN is now widely used by service operators as a complement of the
cellular (2G/3G/LTE) networks, and Extensible Authentication Protocol
(EAP)[RFC3748] is regarded as a widely preferred solution for STA
authentication in WLAN. When a STA tries to connect to the WLAN, it
needs to mutually authenticate with the EAP server of the network
first.
According to the security requirements specified in [IEEE-802.11i], a
successful EAP authentication procedure must result in a Pairwise
Master Key (PMK) for the communication between the STA and the EAP
server. In addition, the EAP server also distribute the PMK to the
Authenticator.
In practice, the encryption/decryption operations on the STA traffics
are carried out either on the WTP or the associated Access Controller
(AC) [RFC5416], and so they need to get the PMK to perform this job.
In some deployment scenarios, the Authenticator may be deployed on a
Gateway (GW) node rather than on the WTP or the AC. In this case, a
solution needs to be provided in order to forward keys to the WTP/AC.
Xue, et al. Expires August 14, 2014 [Page 2]
Internet-Draft key management via radius February 2014
This document proposes a solution which extends RADIUS so as to
enable an Authenticator to transfer PMKs to the associated WTPs or
ACs.
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 same terminologies as found in [RFC5415]and
[RFC5247]. Some of the terms defined in the document have been
repeated in this section for the convenience of the reader, along
with additional terminologies that are used by this document.
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.
Authenticator
The entity initiating EAP authentication.
Backend Authentication Server
A backend authentication server is an entity that provides an
authentication service to an authenticator. When used, this server
typically executes EAP methods for the authenticator. This
terminology is also used in [IEEE-802.1X]
EAP Server
The entity that terminates the EAP authentication method with the
supplicant. In the case where no backend authentication server is
used, the EAP server is part of the authenticator. In the case where
the authenticator operates in pass-through mode, the EAP server is
located on the backend authentication server. In this work, the
latter case is considered.
Gateway (GW)
A device in operator access network, who can charge the subscriber
authentication and IP address management.
Xue, et al. Expires August 14, 2014 [Page 3]
Internet-Draft key management via radius February 2014
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 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 STA 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 STA,
which is derived from the 4-way handshake[IEEE-802.11i].
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.
4. EAP in WLAN
In WLAN, EAP [RFC3748] messages are normally transported over RADIUS
[RFC2865][RFC2866][RFC3579]. An example of end-to-end EAP
authentication in a WLAN is illustrated in Figure 1.
Xue, et al. Expires August 14, 2014 [Page 4]
Internet-Draft key management via radius February 2014
Supplicant (STA) Authenticator EAP Server
+-------+ +-------+ +-------+
| | | | | |
| | | | | |
| | | | | |
+-------+ +-------+ +-------+
| | |
|EAP-Request Identity | |
|<-------------------------+ |
|EAP-Response Identity | |
| | |
|------------------------->| |
| | RADIUS Access Request |
| +------------------------->|
| EAP type specific |
| mutual authentication |
|<-------------------------o------------------------->|
| | |
| |RADIUS Access Accept(with PMK)
| |<-------------------------+
| EAP-Success | |
|<-------------------------+ |
| | |
Figure 1. EAP Operation
In the EAP authentication framework, there are three entities:
o Supplicant: The end of the link that responds to the
Authenticator. In this work, a supplicant is actually a STA.
o Authenticator: An entity that facilitates authentication of other
entities attached to the same LAN. In a WLAN, an Authenticator
could be deployed on WTP, AC or GW according to the operator's
requirements.
o EAP Server : An entity provides an authentication service to an
authenticator. In this work, it is assumed that an EAP server is
deployed on a backend device (e.g., AAA server).
5. Motivation Scenario
The architecture of a typical WLAN deployment [BBF-WT-321] is shown
in Figure 2 .
Xue, et al. Expires August 14, 2014 [Page 5]
Internet-Draft key management via radius February 2014
+--------+ +--------+
| AAA | | DHCP |
+---\----+ +----/---+
\ /
\ / /----\
+----+ +--------+ +--------+ +-+--+---+ / \
|STA +----+ WTP +-----+ AC +-----+ GW +-------| IP MAN |
+----+ +--------+ +--------+ +--------+ \ /
\----/
Figure 2 WLAN architecture
As illustrated in this diagram:
o AC and GW are deployed separately.
o AC is responsible for AP management as [RFC5415].
o GW is responsible to provide IP address management and traffic
management ( e.g., QoS, Charging, Remark, etc) for each STA
attached to it. When a STA attempts to access the WLAN, GW will
assign an IPv4 address to the STA after the STA has been
authenticated. In addition, based on the privileges associated
with a STA, GW can decide whether to forward (maybe certain types
of) STA traffics not.
Assuming a STA is attached to the WLAN. After a successful EAP
session, the GW needs to obtain sufficient information about the STA
(including authentication and authorization results) to provide IP
address management and traffic management. There are two candidate
solutions to achieve this.
The first solution is to deploy the Authenticator on the AC. In this
case the GW can act as a RADIUS PROXY during EAP procedure to get the
STA information, as shown in figure 3. In this solution, both the GW
and the AC MUST be involved with the EAP authentication procedure,
and the STA related information needs to be redundantly maintained on
both the GW and the AC. In addition, this solution will make ACs
more complex. Especially, in the scenarios where there are large
amount of WTPs, ACs MUST be deployed close to the WTPs because of
normally a AC is only able to manage a limited number of WTPs. As a
result, there will be a large amount of ACs in the network, which
could be costly for operators and could introduce enormous management
costs on both EAP servers and ACs. Moreover, the encryption of the
communication between EAP server and ACs may damage the effectiveness
of this solution.
Xue, et al. Expires August 14, 2014 [Page 6]
Internet-Draft key management via radius February 2014
The second solution is to deploy the Authenticator on the GW. This
solution can largely avoid this issues occurred in the first
solution. ACs do not have to support EAP procedures, and the number
of GWs could be much less than the number of ACs in a WLAN. However,
in the second solution, the GW needs to find a way to forward the PMK
to the AC,which is the objective of this work.
Authenticator EAP Server
+-------+ +----+ +----+ +-------+ +-------+
| | | | | | | | | |
| STA | |WTP | | AC | | GW | | EAP |
| | | | | | | | | Server|
+-------+ +----+ +----+ +-------+ +-------+
| | | |
|EAP-Request Identity | | |
<---------------------+ | |
|EAP-Response Identity| | |
|-------------------->| | |
| | RADIUS Access Request |
| +----------->------------------------->|
| | | |
| | RADIUS Access Challenge |
| |<----------<--------------------------|
| EAP Exchange | | |
|<------------------->| | |
| | RADIUS|Access Request |
| +----------->------------------------->|
| | | |
| | RADIUS Access Accept |
| |<----------<--------------------------|
| EAP Success | | |
|<--------------------+ | |
| | | |
| DHCP Exchange | |
|<--------------------+---------->| |
| | | Accounting |
| | +----------------------> |
Figure 3 GW acts as RADIUS PROXY
6. Protocol overview
As introduced above, the encryption/decryption operations could be
performed on either AC or WTP. If the AC is the encryption/
decryption node, the Authenticator then needs to send the PMK to AC.
If the WTP is the encryption/decryption node, the Authenticator can
Xue, et al. Expires August 14, 2014 [Page 7]
Internet-Draft key management via radius February 2014
also send the PMK to AC, and AC then forwards the PMK to WTP via
protocol defined in [RFC4564]. Therefore, this work specifies three
RADIUS commands and a set of attributes for PMK transportation from
Authenticator(GW) to AC, i.e., Key-of-Announcement (KoA), KoA-ACK and
KoA-NAK.
The PMK transportation is trigged when the Authenticator receives a
RADIUS Accept message in EAP session which indicates the
authentication success.
6.1. RADIUS Commands for PMK Transportation
Authenticator
+---------+ +---------+
| | | |
| | | |
| AC | | GW |
| | | |
+---------+ +---------+
| |
| KoA Message |
|<--------------------------------------|
| |
| |
| |
| KoA ACK/NAK Message |
|-------------------------------------> |
| |
| |
| |
| |
Figure 4 RADIUS Commands for PMK Transportation
As illustrated in the above figure, during the authentication
procedure between a STA and a EAP server, the GW acts as an
Authenticator. The GW constructs a KoA message and forwards the
message to the AC when it obtains the PMK carried in the RADIUS
Accept message from EAP server. The AC responds with a KoA-ACK
message after successfully accept the PMK. Otherwise, the AC
responds with a KoA-NAK.
The commands use the format of Change-of-Authorization Messages (CoA)
[RFC5176], presented as follows
Xue, et al. Expires August 14, 2014 [Page 8]
Internet-Draft key management via radius February 2014
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 5 Packet Format
Code
The Code field is one octet, and identifies the type of RADIUS
packet. Three new RADIUS codes are defined.
o 100 - Key-of-Announcement
o 101 - KoA-ACK
o 102 - KoA-NAK
Identifier
This 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 the 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 [RFC5176].
The following attributes should be included in KoA, KoA-ACK and KoA-
NAK messages.
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. This attribute may include within KoA, KoA-
ACK and KoA-NAK messages. The values are shown below.
Type
Xue, et al. Expires August 14, 2014 [Page 9]
Internet-Draft key management via radius February 2014
31 as defined in [RFC5176].
Length
8
Value
The Value field is 6 octets, containing the STA MAC address.
o Keying-Material. This attribute is used by GW to transport the
PMK to the AC. This attribute may include within KoA, KoA-ACK and
KoA-NAK messages. The format and the values are 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 6 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.
o KoA-Feedback. It is responsible to provide the feedback when AC
receives the KoA command from GW. This attribute may include
within KoA-ACK/NAK messages. The format is shown below.
Xue, et al. Expires August 14, 2014 [Page 10]
Internet-Draft key management via radius February 2014
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 7 KoA-Feedback Attribute 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 referenced in[RFC2865].
Length
4
Value
The Value field is 2 octets, containing the feedback from the AC when
received the KoA message. It could be reasons for PMK transportation
fails.
7. IANA Considerations
TBD
8. Security Considerations
TBD
9. Normative References
[BBF-WT-321]
"Public Wi-Fi Access in Multi-service Broadband Networks",
January 2014.
[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.
Xue, et al. Expires August 14, 2014 [Page 11]
Internet-Draft key management via radius February 2014
[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.
[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.
[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.
[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And
Provisioning of Wireless Access Points (CAPWAP) Protocol
Specification", RFC 5415, March 2009.
[RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and
Provisioning of Wireless Access Points (CAPWAP) Protocol
Binding for IEEE 802.11", RFC 5416, March 2009.
Authors' Addresses
Xue, et al. Expires August 14, 2014 [Page 12]
Internet-Draft key management via radius February 2014
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
Dacheng Zhang
Huawei
Beijing
China
Email: zhangdacheng@huawei.com
Bo Gao
China Telecom
No. 1835, South Pudong Road
Shanghai 200122
China
Email: gaobo@sttri.com.cn
Xue, et al. Expires August 14, 2014 [Page 13]