One document matched: draft-xue-radext-key-management-01.txt
Differences from draft-xue-radext-key-management-00.txt
Network Working Group L. Xue
Internet-Draft Huawei
Intended status: Informational B. Gao
Expires: January 13, 2014 China Telecom
July 12, 2013
RADIUS Extensions for Key Management in WLAN network
draft-xue-radext-key-management-01
Abstract
It is a general case in operators networks that Authenticator is
deployed on Service Gateway (SGW) to avoid overload on the Access
Controller (AC). In this scenario, the encryption/decryption node
can't obtain Pairwise Master Key (PMK) information during Extensible
Authentication Protocol (EAP) procedure, it is not sufficent to
achieve traffic encryption/decryption requirement in Wireless Local
Area Network (WLAN) network.
This document analyzes the requirement and issue for key management
that has arisen so far during 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 January 13, 2014.
Copyright Notice
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
Xue & Gao Expires January 13, 2014 [Page 1]
Internet-Draft key management via radius July 2013
(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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
5. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 6
5.1. PMK Announcement Messages . . . . . . . . . . . . . . . . 6
6. Authentication Procedure . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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.
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. During the
Extensible Authentication Protocol (EAP) [RFC3748] procedure between
Station (STA) and Authenticator Server (AS), Pairwise Master Key
(PMK) will be generated as a side effect. Moreover, AS distributes
PMK to the Authenticator defined in[RFC3748].
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.
However, in practice, it is a general case in operators networks that
Authenticator is deployed on Service Gateway (SGW) to avoid overload
Xue & Gao Expires January 13, 2014 [Page 2]
Internet-Draft key management via radius July 2013
on the Access Controller (AC). In this scenario, the encryption/
decryption node can't obtain PMK information during EAP procedure, it
is not sufficient to achieve traffic encryption/decryption
requirement in WLAN network.
This document analyzes the requirement and issue for key management
that has 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.
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
Xue & Gao Expires January 13, 2014 [Page 3]
Internet-Draft key management via radius July 2013
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.
Service Gateway (SGW)
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
Supplicant is kind of device in authentication. 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 defined in [RFC3748]. The
supplicant is station (STA) in WLAN network.
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 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
In practice, ACs are deployed on the centralized center in existing
operator networks. In order to avoid the traffic overload on AC,
WTPs forward the wireless frames directly to SGW deployed in the
network. The AC does not have the intelligence to aggregate all the
wireless frames. An illustration of the WLAN centralized
architecture is shown as follows.
Xue & Gao Expires January 13, 2014 [Page 4]
Internet-Draft key management via radius July 2013
+------+
| |
| AC |
| |
+--+---+
|
|
|
+------+ +------+ +--+---+ /-------\
| | | | | | | |
| STA | /-/ | WTP +--------------+ SGW +----+ Service |
| | | | | | | |
+------+ +------+ +------+ \-------/
Figure 1 WLAN Centralized Architecture
In EAP framework, SGW could act as the Authenticator instead of AC
because of several reasons. First of all, a powerful AC that
aggregates the Authenticator function is not a appreciated choice for
some operators.There are large numbers of AC devices in the operators
existing network. The AS will overload the communication with large
numbers of AC devices if ACs acts as the Authenticator. On the other
hand, SGW MUST support the RADIUS Relay function when AC acts as the
Authenticator in EAP framework. In this scenario, both SGW and AC
should be responsible for authentication procedure. For operators,
it is cost in large-scale upgraded deployment. Consequently,it is a
popular scenario for operator to deploy the EAP Authenticator on SGW.
Unfortunately, the Authenticator SGW is the only node which can
obtain the derived PMK,except of STA and AS. But AC is supposed to
deliver the PMK to the WTP to guarantee the security requirement, and
there is not standard interface for SGW sending the PMK to the WTP or
the AC. The authentication procedure when SGW acting as
Authenticator is shown as following figure.
In this document, the mechanism is specified to inform the PMK to
ecryption/decryption node, which is the WTP or AC.
Authenticator
Supplicant Authenticator Server
+-------+ +----+ +----+ +-------+ +-------+
| | | | | | | | | |
| STA | | WTP| | AC | | SGW | | AAA |
| | | | | | | | | |
+-------+ +----+ +----+ +---+---+ +-------+
|
Xue & Gao Expires January 13, 2014 [Page 5]
Internet-Draft key management via radius July 2013
| | |
|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 2 Authentication Procedure When SGW Deployed as Authenticator
5. Protocol overview
Based on the analysis above, it is recommended that control messages
used for PMK announcement from SGW to WTP/AC should be defined when
SGW acts the EAP Authenticator.
If AC is the encryption/decryption node, the SGW sends the PMK to AC
via these control messages. If WTP is the encryption/decryption
node, the SGW sends the PMK to AC as well, then AC sends the obtained
PMK to WTP via protocol defined in [RFC4564]. However, the SGW can
send the PMK to WTP directly, which conforms to the mechine defined
in this document.
As we know, RADIUS attributes are comprised of variable length Type-
Length-Vaule 3 tuples. New attribute values can be added without
disturbing existing implementation of the protocol. This document
describes the RADIUS extension to support the PMK announcement
between SGW and WTP/AC. Specially, new RADIUS messages, including
Key-of-Announcement(KoA) message, KoA-ACK/NAK message, are defined.
5.1. PMK Announcement Messages
There are three messages defined for PMK announcement, shown in
following figures.
Authenticator
+---------+ +---------+
| | | |
Xue & Gao Expires January 13, 2014 [Page 6]
Internet-Draft key management via radius July 2013
| | | |
| WTP/AC | | SGW |
| | | |
+---------+ +---------+
| |
| KoA Message |
|<--------------------------------------|
| |
| |
| |
| KoA ACK/NAK Message |
|-------------------------------------> |
| |
| |
| |
| |
Figure 3 PMK Announcement Messages
o During the authentication procedure, when SGW obtains the PMK from
AS, the SGW initiates the KoA message and send it to the AC.
o If AC is able to obtain the PMK successfully, AC responds the KoA
ACK message to SGW. Otherwise, AC responds the KoA NAK message to
SGW.
The format for PMK announcement messages 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 4 PMK Announcement Message Format
Code
Xue & Gao Expires January 13, 2014 [Page 7]
Internet-Draft key management via radius July 2013
The Code field is one octet, and identifies the type of RADIUS
packet. Packets with an invalid Code field MUST be discarded
silently.
o KoA: TBD
o KoA-ACK: TBD
o KoA-NAK (optional): TBD
Identifier
The Identifier field is one octet. It is used to identifier a pair
of KoA and KoA-ACK/NAK message. This value is set by SGW in this
specification when SGW sends the KoA message to AC. The Identifier
field must be changed by SGW whenever a valid reply has been received
for a previous KoA message.
Authenticator
The same as defined in [RFC3576].
In addition, the following attributes should be included in PMK
Announcement messages.
o Calling-Station-Id. This attribution is used to carry the STA
identifier, for example MAC address. It can be used to bind the
PMK for 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 SGW
to transport PMK to AC. The Keying-material attribute may be
included within KoA-ACK/NAK messages. The format is shown in
following figure.
Xue & Gao Expires January 13, 2014 [Page 8]
Internet-Draft key management via radius July 2013
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 5 Keying-Material Attribute Format
Type
TBD
Length
34
Value
The Value field is 32 octets, containing the PMK information.
o KoA-Feedback, shown as follows. It is responsible to provide the
feedback when AC receives the KoA message from SGW. The KoA-
Feedback attribute may include within KoA-ACK/NAK messages.
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 6 KoA-Feedback Atrribute Format
Type
TBD
Length
4
Value
Xue & Gao Expires January 13, 2014 [Page 9]
Internet-Draft key management via radius July 2013
The Value field is 2 octets, containing the feedback from the AC when
received the KoA message. In this version, several values are
defined.
o 0 Succeed
o 1-8 Reject, can be used in KoA-NAK to indicate the fail reasons.
6. Authentication Procedure
Based on the control message defined in this document, the
recommended procedure is shown as follows.
Authenticator
Supplicant Authenticator Server
+-------+ +----+ +-------+ +-------+
| | | | | | | |
| STA | | AC | | SGW | | 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 7 Authentication Procedure
Xue & Gao Expires January 13, 2014 [Page 10]
Internet-Draft key management via radius July 2013
1 Mutual authentication procedure as general defined in
[RFC3748][IEEE-802.1X].
2 After EAP authentication completes, the SGW acting as Authenticator
initiates and transmits the KoA packet to AC via KoA message. It is
desirable to provide keying information needed based on
[IEEE-802.11i].
3 AC should interpret the KoA message and obtain the PMK included in
Keying-material attribute as an indication that the AS has
successfully authenticated the STA. If AC is able to get the PMK
successfully, AC responds the KoA ACK message to SGW. Otherwise, AC
responds the KoA NAK message to SGW.
Additionally, the derived PMK can be used with 4-Way Handshake to
derive, bind, and verify PTK or GTK, which is out of the scope.
7. IANA Considerations
TBD
8. Security Considerations
The security must be guaranteed between the SGW and the WTP/AC for
key announcement. If there is security requirements, IPsec tunnel or
MD5 encryption/decryption algorithm between SGW and WTP/AC are
needed.
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.
Xue & Gao Expires January 13, 2014 [Page 11]
Internet-Draft key management via radius July 2013
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 3576,
July 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, 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.
Authors' Addresses
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
Bo Gao
China Telecom
No. 1835, South Pudong Road
Shanghai 200122
China
Email: gaobo@sttri.com.cn
Xue & Gao Expires January 13, 2014 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 02:31:30 |