Internet DRAFT - draft-orr-wireless-lan-architectures
draft-orr-wireless-lan-architectures
Network Working Group S. Orr
Internet-Draft A. Grieco
Intended status: Informational Cisco Systems, Inc.
Expires: December 29, 2012 June 27, 2012
Cryptographic Security Characteristics of 802.11 Wireless LAN Access
Systems
draft-orr-wireless-lan-architectures-00.txt
Abstract
This note identifies all of the places that cryptography is used in
Wireless Local Area Network (WLAN) architectures, to simplify the
task of selecting the protocols, algorithms, and key sizes needed to
achieve a consistent security level across the entire architecture.
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 December 29, 2012.
Copyright Notice
Copyright (c) 2012 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.
Orr & Grieco Expires December 29, 2012 [Page 1]
Internet-Draft Wireless-LAN-Architectures June 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used In This Document . . . . . . . . . . . . . . 4
3. Architectures . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Standalone WLAS . . . . . . . . . . . . . . . . . . . . . 5
3.3. Centralized WLAS . . . . . . . . . . . . . . . . . . . . . 5
3.4. Architectural Commonality . . . . . . . . . . . . . . . . 6
4. WTP to Access Controller Service Cryptographic Security . . . 7
5. Client to AAA Service Cryptographic Security . . . . . . . . . 8
5.1. EAP Method . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Pre Shared Key Method . . . . . . . . . . . . . . . . . . 8
6. Authenticator to AAA Service Cryptographic Security . . . . . 9
7. Wireless Link Layer Cryptographic Security . . . . . . . . . . 10
8. Cryptographic profiles . . . . . . . . . . . . . . . . . . . . 11
8.1. DTLS and TLS . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 13
8.3. Link Layer Encryption . . . . . . . . . . . . . . . . . . 14
8.4. AAA . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.5. IPSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.1. Algorithm Choices . . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Orr & Grieco Expires December 29, 2012 [Page 2]
Internet-Draft Wireless-LAN-Architectures June 2012
1. Introduction
Wireless LAN Access Systems (WLAS) are complex systems that involve
interworking many technology components defined by various standards
bodies. To ensure that the entire system is secure against
sophisticated, persistent, and well-funded adversaries, each
component MUST use strong cryptography. However, the architectural-
level cryptographic capabilities and relationships between the
various protocols and security mechanisms provide by each of the WLAS
architecture components have not been documented.
In this note, we define a series of architectures based on common
wireless LAN standards; IEEE 802.11 (a,b,g,i) [IEEE.802-11.2007],
IEEE 802.11n [IEEE.802-11n.2009], Control and Provisioning of
Wireless Access Points [RFC5415], RADIUS [RFC2865], IEEE 802.1x
[IEEE.802-1X.2010], and the Extensible Authentication Protocol
[RFC5247]. Within each of these architectures, we describe the uses
of cryptography and in doing so, we capture an overall understanding
of the cryptographic security of the Wireless LAN Access Systems.
This document can also serve as a framework for future specifications
to define profiles that specify particular cryptographic algorithms
at each area of the architecture creating detailed specifications for
interoperability with well understood cryptographic security
properties.
This document does not define new protocols, nor cryptographic
algorithms.
Orr & Grieco Expires December 29, 2012 [Page 3]
Internet-Draft Wireless-LAN-Architectures June 2012
2. Conventions Used In This Document
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].
Orr & Grieco Expires December 29, 2012 [Page 4]
Internet-Draft Wireless-LAN-Architectures June 2012
3. Architectures
3.1. Overview
The Wireless LAN Access System (WLAS) architectures discussed in this
document describe host/user authentication, over the air security, as
well as various methods for managing the backend processes to support
that wireless LAN access system. These backend processes include
both distributed as well as non-distributed infrastructures for doing
access control, authentication and Radio-Frequency management.
3.2. Standalone WLAS
The Standalone WLAS consist of a Wireless Termination Point (WTP or
Access Point), an Authentication, Authorization and Accounting
Service (AAA) that could resides on the WTP and an IEEE 802.1x
[IEEE.802-1X.2010] supplicant that resides on the client. This
architecture is commonly deployed in small scale environments such as
consumer and commercial deployments, or in places where backend
resources are not available to provide a more distributed
architecture. The AAA service may reside on a separate server or may
be incorporated directly within the WTP. If a AAA server and 802.1x
are not deployed then 802.11 Pre-Shared Keys MAY be used as a
security mechanism.
client(s) WTP AAA Service
|-------------(1)----------------|
|-------(2)-------|
|------(3)-----|
Figure 1: Standalone WLAS Architecture
Each of the lines in Figure 1 denotes communication that MUST be
secured. The numbers are defined in (Section 3.4). This notation is
used throughout this note.
3.3. Centralized WLAS
The Centralized WLAS is similar to the Standalone AP architecture
with the addition of an Access Controller (AC) to manage the
collection of WTP's. This architecture utilizes [RFC5415] for
control and provisioning of wireless access points (CAPWAP).
Orr & Grieco Expires December 29, 2012 [Page 5]
Internet-Draft Wireless-LAN-Architectures June 2012
client(s) WTP Access Controller AAA Service
|-------(4)--------|
|------------------------(1)-------------------------|
|-------(2)---------|
|----(3a)------| or
|------------(3b)-----------------|
Figure 2: Centralized WLAS Architecture
3.4. Architectural Commonality
In each of the above architectures, there are necessary services that
we will describe in more details in the sections below. (1) describes
authentication and authorization communications that occurs between
the client and the AAA service in the form of an EAP method. (2)
describes additional communications that occurs in support of EAP, as
well as distribution of other keying material via the AAA service.
(3a) Describes the over the air cryptography security between the
client and WTP as addressed in the 802.11i specification
[IEEE.802-11I.2004], the 802.11i encryption/decryption can occur at
the AC as in (3b). (4) Describes the authentication and cryptography
security between the WTP and the access controller as specified in
CAPWAP [RFC5415].
Orr & Grieco Expires December 29, 2012 [Page 6]
Internet-Draft Wireless-LAN-Architectures June 2012
4. WTP to Access Controller Service Cryptographic Security
Specific to the Centralized WLAS Architecture is the establishment of
a secure channel between the WTP and the AC. This command channel
MUST be secured to insure the integrity of the communication between
the AC and the WTP. The IETF has defined CAPWAP [RFC5415] to
communicate between the WTP and the AC however other methods such as
IPSec [RFC4301] or TLS [RFC5246]/DTLS [RFC6347] can be implemented to
secure the command and control traffic in addition to the user data
channel. In the case of CAPWAP, two separate channels exist between
the AC and the WTP the CAPWAP Control and CAPWAP Data Channels. The
CAPWAP Control Channel encapsulates management messages between the
AC and WTP (i.e. WTP image, client Pairwise Transient Key, client
Groupwise Transient Key) and is secured by DTLS, while the CAPWAP
Data Channel encapsulates client wireless traffic from WTP to AC and
can also be secured via DTLS. In order to establish the Secure
CAPWAP Control Channel between the WTP and the AC, x.509 certificates
are installed on each device and used as part of the DTLS mutual
authentication process.
Orr & Grieco Expires December 29, 2012 [Page 7]
Internet-Draft Wireless-LAN-Architectures June 2012
5. Client to AAA Service Cryptographic Security
5.1. EAP Method
The 802.11i specification defines a Robust Security Network (RSN) as
one that utilizes IEEE 802.1x [IEEE.802-1X.2010] and the Extensible
Authentication Protocol [RFC3748] to provide authentication and key
management services between the client and WLAS. EAP Authentication
occurs between the client and the AAA service which may reside within
a component of the WLAS (WTP or AC) or as a standalone AAA Server.
It is not the intent of this document to specify the type of
transport for the authentication service (i.e RADIUS, Diameter
[RFC3588] etc) or the specific communication channel between the
Network Access Server (NAS) and the Authentication Service. Mutual-
Authentication is achieved through the establishment of a secure
channel for exchanging credentials between the client and the
Authentication Server utilizing an EAP method employing Transport
Layer Security (TLS) such as but not limited to EAP-TLS [RFC5216],
PEAP, EAP-FAST, EAP-TTLS [RFC5281]. The main output of the EAP
process is the generation of the Master Session Key (MSK) and
Extended Master Session Key (EMSK) known only to the Client
(supplicant) and the AAA server that will be used to generate the
keying material for the cipher suites. An in depth discussion on EAP
Key management can be found in EAP Key Management Framework document
[RFC5247].
5.2. Pre Shared Key Method
When 802.1x and an Authentication server are not used, Pre-Shared
Keys (PSK) or passphrases can also be employed as a method of
authenticating to a WLAS in a RSN in accordance with the Wi-Fi
Alliances Wi-Fi Protected Access Personal profile (WPA2-PSK). Unlike
Wired Equivalent Privacy (WEP) where the shared key (40 or 104 bits)
is concatinated with a 24 bit IV to be used as the RC4 stream cipher
key, the WPA2-PSK or passphrase is used by the client supplicant to
generate the 256 bit Pairwise Master Key (PMK) for keying material in
the selected cipher suite. However, operationally, PSK's are shared
by multiple devices simultaneously so this method is less secure than
the utilization of an EAP method and needs to be considered from an
overall security perspective.
Orr & Grieco Expires December 29, 2012 [Page 8]
Internet-Draft Wireless-LAN-Architectures June 2012
6. Authenticator to AAA Service Cryptographic Security
As stated in the previous section, the byproduct of EAP
authentication is the generation of keying material to be used in the
cryptographic process between the client and the WTP to secure the
over the air communications. The AAA server generates the AAA key
which will be forwarded directly to the WTP in a Standalone WLAS, and
forwarded to the AC in a Centralized WLAS where they will generate
the Pairwise Master Key (PMK) (bits 0-255 of the AAA key). The
transmission of the AAA key needs to be protected between the AAA
server and the WTP or the AAA server and the AC depending on which
architecture is deployed. NIST has previously made recommendations
on securely encrypting plain text keying material for transport over
insecure media with AES Key Wrap [AES_Key_Wrap] as well as industry
with the Advanced Encryption Standard Key Wrap Algorithm [RFC3394].
In addition to the transport of the keying material it is suggested
that all AAA traffic between the Authenticator (WTP or AC) and the
Authentication Service (AAA) be encrypted, methods such as but not
limited to utilizing IPSEC, TLS or DTLS to secure the protocol.
Orr & Grieco Expires December 29, 2012 [Page 9]
Internet-Draft Wireless-LAN-Architectures June 2012
7. Wireless Link Layer Cryptographic Security
Wireless link layer communication is protected through a series of
cryptographic operations defined by 802.11i: the Advanced Encryption
Standard Counter Mode with Cipher Block Chaining Message
Authentication Code Protocol (AES-CCMP) and The Temporal Key
Integrity Protocol (TKIP) which uses RC4 for encryption (TKIP has
been deprecated in the later 802.11n standard) . AES-CCMP is
currently the preferred cryptographic algorithm for both unicast and
multicast/broadcast traffic and the client MAY terminate the
encrypted session at the WTP or the AC . The PMK is independently
generated on both the Client and the AAA server as the by product of
EAP authentication. A Pair Wise Transient Key (PTK) is then
generated simultaneously on both the Client and the WTP/AC out of the
PMK and is used as the unicast session encryption key. A Groupwise
Transient Key (GTK) is computed out of the Group Master Key (GMK) by
the WTP/AC and is sent to each of the clients encrypted by the
individual session PTKs.
Orr & Grieco Expires December 29, 2012 [Page 10]
Internet-Draft Wireless-LAN-Architectures June 2012
8. Cryptographic profiles
In each of the above architectural areas, there are a number of
different security protocols that serve various functions needed to
build secure wireless LAN architectures. Each protocol has important
choices to be made in context of this overall cryptographic security
within that protocol and subsequently has significant impacts to the
overall security parameters of the system. The security mechanisms
are summarized in Table 1.
+--------+------------+---------------+------------+----------------+
| | Client | WTP | AC | AAA |
+--------+------------+---------------+------------+----------------+
| Client | | 802.11i; | 3rd Party; | EAP w/TLS |
| | | 802.11w | 802.1x | |
| | | | Supplicant | |
+--------+------------+---------------+------------+----------------+
| WTP | 802.11i; | | DTLS; | TLS, DTLS, |
| | 802.11w | | IPSEC | IPSec, AES |
| | | | | KeyWrap |
| | | | | (Standalone |
| | | | | Architecture) |
+--------+------------+---------------+------------+----------------+
| AC | 3rd Party; | DTLS; IPSEC | | TLS, DTLS, |
| | 802.1x | | | IPSec, AES |
| | Supplicant | | | KeyWrap |
+--------+------------+---------------+------------+----------------+
| AAA | EAP w/TLS | TLS, DTLS, | TLS, DTLS, | |
| | | IPSec, AES | IPSec, AES | |
| | | KeyWrap | KeyWrap | |
| | | (Standalone | | |
| | | Architecture) | | |
+--------+------------+---------------+------------+----------------+
Table 1: Cryptographic Security Interactions
8.1. DTLS and TLS
TLS and DTLS are well studied and documented from a cryptographic
strength perspective and there are a number of works that create
profiles for TLS and DTLS and its use within systems of varying
security requirements. Table 2 provides an example of the
cryptographic functional requirements necessary to define a TLS
CipherSuite and associated security of each. When profiling against
this document, authors MUST define cryptographic algorithms for each
function in Table 2
Orr & Grieco Expires December 29, 2012 [Page 11]
Internet-Draft Wireless-LAN-Architectures June 2012
+-------------+----------+------------+---------------+-------------+
| Function | Example | Cryptograp | Algorithm | Cryptograph |
| | Algorith | hic | Reference | ic Strength |
| | ms | Strength | | Reference |
+-------------+----------+------------+---------------+-------------+
| Authenticat | RSA 2048 | 112 | [RFC3447] | NIST SP |
| ion | | | | 800-57 |
| | | | | [NIST800-57 |
| | | | | ] |
+-------------+----------+------------+---------------+-------------+
| Key | RSA 2048 | 112 | [RFC3447] | NIST SP |
| Exchange | | | | 800-57 |
| | | | | [NIST800-57 |
| | | | | ] |
+-------------+----------+------------+---------------+-------------+
| Payload | AES 128 | 128 | [FIPS.197.200 | NIST SP |
| Protection | CBC | | 1] | 800-57 |
| | | | | [NIST800-57 |
| | | | | ] |
+-------------+----------+------------+---------------+-------------+
| Message | HMAC-SHA | 128 | [NIST.PUB.198 | NIST SP |
| Auth | -1 | | A] | 800-57 |
| | | | | [NIST800-57 |
| | | | | ] |
+-------------+----------+------------+---------------+-------------+
Table 2: DTLS and TLS Cryptographic Security Algorithms
Throughout the Wireless LAN Access System, TLS and DTLS are used in a
number of different places. Someone profiling wireless architectures
might require alternative algorithm definitions for different uses of
TLS/DTLS in the architecture. One example might be a place that
describes using TLS or DTLS to protect the transport of an ephemeral
key vs its use to protect a long lived secret. In this case, a
profile might be willing to trade off less security of the
cryptographic algorithms for the ephemeral key.
Table 3 shows the places in the wireless architectures described in
Section 3 that TLS or DTLS is used
Orr & Grieco Expires December 29, 2012 [Page 12]
Internet-Draft Wireless-LAN-Architectures June 2012
+---------------------+-----------+---------------------------------+
| Location in | Protocol | Used to Protect |
| Architecture | | |
+---------------------+-----------+---------------------------------+
| WTP To Access | CAPWAP | Management, session keys, user |
| Controller Service | using | traffic |
| (Section 4) | DTLS | |
+---------------------+-----------+---------------------------------+
| Client to AAA | EAP | session keys, authentication |
| Service (Section 5) | method | |
| | using TLS | |
+---------------------+-----------+---------------------------------+
| Authenticator to | DTLS/TLS, | Confidentiality and |
| AAA Service | IPSec | Authenticity of Radius traffic |
| (Section 6) | | (wrapped session keys) |
+---------------------+-----------+---------------------------------+
Table 3: DTLS and TLS Architectural Usage
8.2. X.509 Certificates
The security level provided by algorithm and key length choice for
X.509 Certificates is well studied solely in context of the
certificates itself. Table 4 lists the types of cryptographic
security functions used within X.509 Certificates and provides
examples for each. Any profile of Wireless LAN Architecture MUST
include definitions for each cryptographic security function used
within X.509 certificates.
+----------+-----------+--------------+-------------+---------------+
| Function | Example | Cryptographi | Algorithm | Cryptographic |
| | Algorithm | c Strength | Reference | Strength |
| | s | | | Reference |
+----------+-----------+--------------+-------------+---------------+
| Signatur | RSA with | 112 | [RFC3447] | NIST SP |
| e | 2048 bit | | | 800-57 |
| Algorith | public | | | [NIST800-57] |
| m | keys | | | |
+----------+-----------+--------------+-------------+---------------+
| Public | RSA 2048 | 112 | [RFC3447] | NIST SP |
| Key | | | | 800-57 |
| Algorith | | | | [NIST800-57] |
| m | | | | |
+----------+-----------+--------------+-------------+---------------+
| Hash | SHA256 | 128 | [FIPS-180-3 | NIST SP |
| Function | | | ] | 800-57 |
| | | | | [NIST800-57] |
+----------+-----------+--------------+-------------+---------------+
Orr & Grieco Expires December 29, 2012 [Page 13]
Internet-Draft Wireless-LAN-Architectures June 2012
Table 4: X.509 Certificate Cryptographic Security Functions
Throughout the Wireless LAN Access System, X.509 certificates are
used in a number of different places. Table 5 shows the places in
the wireless architectures described in Section 3 that X.509
Certificates are potentially used
+----------------------+----------------+---------------------------+
| Location in | Protocol | Used to Protect |
| Architecture | | |
+----------------------+----------------+---------------------------+
| WTP To Access | DTLS used | Authenticity of |
| Controller Service | within CAPWAP; | Management, session keys, |
| (Section 4) | IPSec | user traffic |
+----------------------+----------------+---------------------------+
| Client to AAA | TLS (Example | Authenticity of session |
| Service (Section 5) | EAP Method) | keys, authentication |
+----------------------+----------------+---------------------------+
| Authenticator to AAA | DTLS, TLS or | Authenticity of AAA |
| Service (Section 6) | IPSec | traffic (wrapped session |
| | | keys) |
+----------------------+----------------+---------------------------+
Table 5: X.509 Architectural Usage
8.3. Link Layer Encryption
Link Layer encryption for Wireless LAN Access Systems is well defined
by the IEEE 802.11i standard and superseded by IEEE 802.11-2012.
Future 802.11 standards need to address link layer encryption as an
integral part of the standard. Current 802.11 standards require the
implementation of 128 bit key length.
+------------+-----------+------------+----------------+------------+
| Function | Example | Cryptograp | Algorithm | Cryptograp |
| | Algorithm | hic | Reference | hic |
| | s | Strength | | Strength |
| | | | | Reference |
+------------+-----------+------------+----------------+------------+
| 802.1x 4 | AES Key | 128 | [IEEE.802-11I. | NIST SP |
| Way | Wrap with | | 2004] | 800-57 |
| Handshake | HMAC-SHA1 | | | [NIST800-5 |
| | -128 | | | 7] |
+------------+-----------+------------+----------------+------------+
| Message | HMAC-SHA- | 128 | [NIST.PUB.198A | NIST SP |
| Authentica | 1 | | ] | 800-57 |
| tion | | | | [NIST800-5 |
| | | | | 7] |
Orr & Grieco Expires December 29, 2012 [Page 14]
Internet-Draft Wireless-LAN-Architectures June 2012
| Pseudo-Ran | HMAC-SHA- | 128 | [NIST.PUB.198A | NIST SP |
| dom | 1 | | ] | 800-57 |
| Function | | | | [NIST800-5 |
| | | | | 7] |
+------------+-----------+------------+----------------+------------+
| 802.11 | AES-CCMP | 128 | [FIPS.197.2001 | NIST SP |
| Management | | | ] | 800-57 |
| Frame | | | | [NIST800-5 |
| Encryption | | | | 7] |
+------------+-----------+------------+----------------+------------+
| 802.11 | AES-CCMP | 128 | [FIPS.197.2001 | NIST SP |
| Payload | | | ] | 800-57 |
| Encryption | | | | [NIST800-5 |
| | | | | 7] |
+------------+-----------+------------+----------------+------------+
Table 6: Link Layer Security Algorithms
As a minimum, link layer encryption needs to be used in wireless
architectures as indicated in Table 7 to protect the data in transit.
When profiling against this document, authors MUST define
cryptographic algorithms for each function described in Table 7. In
addition to over the air link layer encryption, there are other
places where related, but different link layer encryption (i.e.
802.1ae) could be leveraged within the wireless architecture. Link
layer encryption in these alternative places MAY be profiled for use
in the overall cryptographic integrity of the system but are not
covered here.
+--------------+------------+---------------------------------------+
| Location in | Protocol | Used to Protect |
| Architecture | | |
+--------------+------------+---------------------------------------+
| Client to | AES-CCMP, | 802.1x 4-way handshake (stand alone |
| WTP | AES Key | configuration), 802.11 |
| (Section 7) | Wrap, | unicast/multicast data frames and |
| | HMAC-SHA-1 | Management Frame protection using the |
| | | Integrity Group Temporal Key (IGTK) |
+--------------+------------+---------------------------------------+
| Client to AC | AES-CCMP, | 802.1x 4-way handshake and optional |
| | AES Key | configuration where 802.11 |
| | Wrap, | unicast/multicast data frames and |
| | HMAC-SHA-1 | Management Frame protection using the |
| | | Integrity Group Temporal Key |
| | | (IGTK)encryption is performed on the |
| | | AC |
+--------------+------------+---------------------------------------+
Orr & Grieco Expires December 29, 2012 [Page 15]
Internet-Draft Wireless-LAN-Architectures June 2012
Table 7: Link Layer Encryption Architectural Uses
8.4. AAA
It is stringly suggested that traffic between the WTP/AC and the AAA
service be secured to provide confidentiality and integrity of the
user/device being authenticated as well as the key data used for the
encryption process. The use of the well documented cryptographic
protocols IPSEC (Section 8.5), TLS or DTLS (Section 8.1) can be used
to protect traffic between the WTP/AC and the AAA service. When
profiling against this document, authors MUST define the
cryptographic algorithms for each function in listed in Table 8
+---------------+----------------+----------------------------------+
| Location in | Protocol | Used to Protect |
| Architecture | | |
+---------------+----------------+----------------------------------+
| Authenticator | TLS/DTLS or | Used to secure all |
| to AAA | IPSec | authentication traffic between |
| (Section 6) | | the Authenticator (WTP or AC) |
| | | and the AAA service |
+---------------+----------------+----------------------------------+
| Authenticator | AES Key Wrap | Used to encrypt only the key |
| to AAA | [AES_Key_Wrap] | data between the Authenticator |
| (Section 6) | | (WTP or AC) and the AAA services |
+---------------+----------------+----------------------------------+
| Client to AAA | TLS | Used to secure EAP |
| (Section 5) | | authentication between Client |
| | | and AAA service (i.e. EAP-TLS, |
| | | EAP-FAST and PEAP) |
+---------------+----------------+----------------------------------+
Table 8: AAA Security Architectural Uses
8.5. IPSEC
IPSEC is well studied and documented from a cryptographic strength
perspective and there are a number of works that create profiles for
IPSEC and its use within systems of varying security requirements.
Table 9 provides an example of the cryptographic functional
requirements necessary to define an IPSEC CipherSuite and associated
security of each. When profiling against this document, authors MUST
define cryptographic algorithms for each function in Table 9
Orr & Grieco Expires December 29, 2012 [Page 16]
Internet-Draft Wireless-LAN-Architectures June 2012
+------------+-----------+------------+--------------+--------------+
| Function | Example | Cryptograp | Algorithm | Cryptographi |
| | Algorithm | hic | Reference | c Strength |
| | s | Strength | | Reference |
+------------+-----------+------------+--------------+--------------+
| IKE | RSA 2048 | 112 | [RFC3447] | NIST SP |
| Authentica | | | | 800-57 |
| tion | | | | [NIST800-57] |
+------------+-----------+------------+--------------+--------------+
| IKE | HMAC-SHA- | 256 | [RFC4868] | NIST SP |
| Pseudo-ran | 256 | | | 800-57 |
| dom | | | | [NIST800-57] |
| Function | | | | |
+------------+-----------+------------+--------------+--------------+
| IKE | Group 14 | 112 | [RFC3526] | NIST SP |
| Diffie-Hel | | | | 800-57 |
| lman group | | | | [NIST800-57] |
+------------+-----------+------------+--------------+--------------+
| IKE Hash | SHA-256 | 128 | [FIPS-180-3] | NIST SP |
| | | | | 800-57 |
| | | | | [NIST800-57] |
+------------+-----------+------------+--------------+--------------+
| IKE | AES 128 | 128 | [FIPS.197.20 | NIST SP |
| Encryption | CBC | | 01] | 800-57 |
| | | | | [NIST800-57] |
+------------+-----------+------------+--------------+--------------+
| ESP | AES-CBC | 128 | [FIPS.197.20 | NIST SP |
| Encryption | | | 01] | 800-57 |
| | | | | [NIST800-57] |
+------------+-----------+------------+--------------+--------------+
| ESP | HMAC-SHA1 | 128 | [FIPS-180-3] | [NIST.PUB.19 |
| Integrity | | | | 8A] |
+------------+-----------+------------+--------------+--------------+
Table 9: IPSEC Cryptographic Security Algorithms
IPSec in many cases has been superseded by other protocols for
security within the Wireless LAN Access System. However, IPSEC could
play a role and Table 10 describes places in the WLAN Access System
Architecture (Section 3) where it can be utilized.
Orr & Grieco Expires December 29, 2012 [Page 17]
Internet-Draft Wireless-LAN-Architectures June 2012
+----------------------+----------+---------------------------------+
| Location in | Protocol | Used to Protect |
| Architecture | | |
+----------------------+----------+---------------------------------+
| WTP To Access | IPSec | Authenticity of Management, |
| Controller Service | | session keys, user traffic |
| (Section 4) | | |
+----------------------+----------+---------------------------------+
| Authenticator to AAA | IPSec | Authenticity and |
| Service (Section 6) | | Confidentiality of AAA traffic |
| | | (wrapped session keys) |
+----------------------+----------+---------------------------------+
Table 10: IPSEC Architectural Usage
Orr & Grieco Expires December 29, 2012 [Page 18]
Internet-Draft Wireless-LAN-Architectures June 2012
9. Security Considerations
The cryptographic security level of a complex system is limited to
that of the weakest component in the system. The use of 128-bit
block ciphers with 128-bit keys is now common, but in many systems,
the security is limited by other factors, such as public keys with a
strength of just 80 bits, or keys that are manually configured. A
typical security protocol uses multiple cryptographic algorithms to
achieve different security goals: encryption to provide
confidentiality, data authentication to protect the integrity of
data, key derivation to provide the keys for those algorithms, key
establishment to determine shared keys, and digital signatures to
authenticate the entity on the other end of the wire. In order to
provide a high security level, a protocol needs to use algorithms and
parameters that consistently meet that security goal. Wireless
systems use multiple security protocols, thus requiring consistency
across multiple protocols. To achieve consistency, one must first
understand all of the cryptographic components in a wireless system.
This note makes that process easier, by cataloging the components
that appear in typical wireless architectures.
It is also important to note that not all secrets are equal. A
secret which gives you access to data for a short period of time
might be considered less important than one that exposes data for a
longer period of time. Depending on the system being built and
associated security constraints, the value of the secret being
protected can inform appropriate choices for the cryptographic
strength over sub components of a wireless architecture.
Finally, this note is intended to encourage the use of consistent
cryptographic strenghts of confidentiality, integrity and
authenticity within the entire wireless LAN architecture. While
profiles of this document might justify inconsistent algorithm
strength choices, the profiles need to use cryptography throughout
the architecture to provide end-to-end security.
9.1. Algorithm Choices
The choices of the algorithms to use in this document are left to the
profile authors discretion. However, it must be clear that profiles
need to avoid the use of known broken cryptographic algorithms (i.e.
WEP, TKIP, etc).
Orr & Grieco Expires December 29, 2012 [Page 19]
Internet-Draft Wireless-LAN-Architectures June 2012
10. IANA Considerations
None
Orr & Grieco Expires December 29, 2012 [Page 20]
Internet-Draft Wireless-LAN-Architectures June 2012
11. Acknowledgements
The authors would like to acknowledge David McGrew, Nancy Cam-Winget
and Carlos Pignataro for their constructive comments on this
document.
Orr & Grieco Expires December 29, 2012 [Page 21]
Internet-Draft Wireless-LAN-Architectures June 2012
12. References
12.1. Normative References
[IEEE.802-11.2007]
"IEEE Standard for Information technology--
Telecommunications and information exchange between
systems-- Local and metropolitan area networks-- Specific
requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", June 2007,
<http://standards.ieee.org/getieee802/download/
802.11-2007.pdf>.
[IEEE.802-11I.2004]
"Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications Amendment 6: Medium Access
Control (MAC) Security Enhancements", IEEE Standard
802.11i, July 2004, <http://standards.ieee.org/getieee802/
download/802.11i-2004.pdf>.
[IEEE.802-11n.2009]
"IEEE Standard for information technology--
Telecommunications and information exchange between
systems--Local and metropolitan area networks--Specific
requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications - Amendment
5: Enhancements for Higher Throughput", October 2009, <htt
p://standards.ieee.org/getieee802/download/
802.11-2007.pdf>.
[IEEE.802-1X.2010]
"IEEE Standard for Local and metropolitan area networks -
Port-Based Network Access Control", 2010, <http://
standards.ieee.org/getieee802/download/802.1X-2010.pdf>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And
Provisioning of Wireless Access Points (CAPWAP) Protocol
Specification", RFC 5415, March 2009.
Orr & Grieco Expires December 29, 2012 [Page 22]
Internet-Draft Wireless-LAN-Architectures June 2012
12.2. Informative References
[AES_Key_Wrap]
"", <http://csrc.nist.gov/groups/ST/toolkit/documents/kms/
key-wrap.pdf>.
[FIPS-180-3]
FIPS Publication 180-3, "Secured Hash Standard",
FIPS 180-3, October 2008.
[FIPS.197.2001]
National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", FIPS PUB 197, November 2001, <
http://csrc.nist.gov/publications/fips/fips197/
fips-197.pdf>.
[NIST.PUB.198A]
National Institute of Standards and Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
198A, March 2002, <http://csrc.nist.gov/publications/fips/
fips198/fips-198a.pdf>.
[NIST800-57]
Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
"Recommendations for Key Management", NIST SP 800-57,
March 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, September 2002.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
Orr & Grieco Expires December 29, 2012 [Page 23]
Internet-Draft Wireless-LAN-Architectures June 2012
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, March 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
Orr & Grieco Expires December 29, 2012 [Page 24]
Internet-Draft Wireless-LAN-Architectures June 2012
Authors' Addresses
Stephen Orr
Cisco Systems, Inc.
1 Paragon Drive
Suite 275
Montvale, NJ 07645
US
Email: sorr@cisco.com
Anthony H. Grieco
Cisco Systems, Inc.
7025 Kit Creek Road
RTP, NC 27709
US
Email: agrieco@cisco.com
Orr & Grieco Expires December 29, 2012 [Page 25]
