idnits 2.17.1 draft-orr-wlan-security-architectures-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2012) is 4204 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Orr 3 Internet-Draft A. Grieco 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: April 18, 2013 D. Harkins 6 Aruba Networks 7 October 15, 2012 9 Cryptographic Security Characteristics of 802.11 Wireless LAN Access 10 Systems 11 draft-orr-wlan-security-architectures-00 13 Abstract 15 This note identifies all of the places that cryptography is used in 16 Wireless Local Area Network (WLAN) architectures, to simplify the 17 task of selecting the protocols, algorithms, and key sizes needed to 18 achieve a consistent security level across the entire architecture. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 18, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions Used In This Document . . . . . . . . . . . . . . 4 56 3. Architectures . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.2. Standalone WLAS . . . . . . . . . . . . . . . . . . . . . 5 59 3.3. Centralized WLAS . . . . . . . . . . . . . . . . . . . . . 5 60 3.4. Architectural Commonality . . . . . . . . . . . . . . . . 6 61 4. WTP to Access Controller Service Cryptographic Security . . . 7 62 5. Client to AAA Service Cryptographic Security . . . . . . . . . 8 63 5.1. EAP Method . . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.2. Pre Shared Key, or Password, Method . . . . . . . . . . . 8 65 6. Authenticator to AAA Service Cryptographic Security . . . . . 9 66 7. Wireless Link Layer Cryptographic Security . . . . . . . . . . 10 67 8. Cryptographic profiles . . . . . . . . . . . . . . . . . . . . 11 68 8.1. DTLS and TLS . . . . . . . . . . . . . . . . . . . . . . . 11 69 8.2. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 13 70 8.3. Link Layer Encryption . . . . . . . . . . . . . . . . . . 14 71 8.4. AAA . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 8.5. IPSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 74 9.1. Algorithm Choices . . . . . . . . . . . . . . . . . . . . 19 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 76 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 78 12.1. Normative References . . . . . . . . . . . . . . . . . . . 22 79 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 82 1. Introduction 84 Wireless LAN Access Systems (WLAS) are complex systems that involve 85 interworking many technology components defined by various standards 86 bodies. To ensure that the entire system is secure against 87 sophisticated, persistent, and well-funded adversaries, each 88 component MUST use strong cryptography. However, the architectural- 89 level cryptographic capabilities and relationships between the 90 various protocols and security mechanisms provide by each of the WLAS 91 architecture components have not been documented. 93 In this note, we define a series of architectures based on common 94 wireless LAN standards; IEEE 802.11 [IEEE.802-11.2012], Control and 95 Provisioning of Wireless Access Points [RFC5415], RADIUS [RFC2865], 96 IEEE 802.1x [IEEE.802-1X.2010], and the Extensible Authentication 97 Protocol [RFC5247]. Within each of these architectures, we describe 98 the uses of cryptography and in doing so, we capture an overall 99 understanding of the cryptographic security of the Wireless LAN 100 Access Systems. This document can also serve as a framework for 101 future specifications to define profiles that specify particular 102 cryptographic algorithms at each area of the architecture creating 103 detailed specifications for interoperability with well understood 104 cryptographic security properties. 106 This document does not define new protocols, nor cryptographic 107 algorithms. 109 2. Conventions Used In This Document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. Architectures 117 3.1. Overview 119 The Wireless LAN Access System (WLAS) architectures discussed in this 120 document describe host/user and network authentication, over the air 121 security, as well as various methods for managing the backend 122 processes to support that wireless LAN access system. These backend 123 processes include both distributed as well as non-distributed 124 infrastructures for doing access control, authentication and Radio- 125 Frequency management. 127 3.2. Standalone WLAS 129 The Standalone WLAS consist of a Wireless Termination Point (WTP or 130 Access Point) and a client. The client contains an IEEE 802.1x 131 [IEEE.802-1X.2010] supplicant and the client side of an EAP method 132 [RFC3748]. The WTP contains an IEEE 802.1x [IEEE.802-1X.2010] 133 authenticator. An Authentication, Authorization and Accounting 134 Service (AAA), which incorporates the server side of at least one EAP 135 method [RFC3748], resides either on the WTP or as a stand-alone 136 server. This architecture is commonly deployed in small scale 137 environments such as consumer and commercial deployments, or in 138 places where backend resources are not available to provide a more 139 distributed architecture. If 802.1x authentication is not deployed 140 then 802.11 SAE authentication SHOULD be used for secure 141 authentication using a pre-shared key or password. 143 client(s) WTP AAA Service 145 |-------------(1)----------------| 146 |-------(2)-------| 147 |------(3)-----| 149 Figure 1: Standalone WLAS Architecture 151 Each of the lines in Figure 1 denotes communication that MUST be 152 secured. The numbers are defined in (Section 3.4). This notation is 153 used throughout this note. 155 3.3. Centralized WLAS 157 The Centralized WLAS is similar to the Standalone AP architecture 158 with the addition of an Access Controller (AC) to manage the 159 collection of WTP's. By moving the IEEE 802.1x [IEEE.802-1X.2010] 160 authenticator off the WTPs and centralizing it on the Access 161 Controller, this architecture allows for large scale deployments of 162 secure wireless infrastructure. As with Section 3.2 the AAA service 163 can be incorporated on the AC or reside on a stand-alone server. 164 This architecture supports [RFC5415] for control and provisioning of 165 wireless access points (CAPWAP). 167 client(s) WTP Access Controller AAA Service 169 |-------(4)--------| 170 |------------------------(1)-------------------------| 171 |-------(2)---------| 172 |----(3a)------| or 173 |------------(3b)-----------------| 175 Figure 2: Centralized WLAS Architecture 177 3.4. Architectural Commonality 179 In each of the above architectures, there are necessary services that 180 we will describe in more details in the sections below. (1) describes 181 authentication and authorization communications that occurs between 182 the client and the AAA service in the form of an EAP method. (2) 183 describes additional communications that occurs in support of EAP, as 184 well as distribution of other keying material via the AAA service. 185 (3a) and (3b) describe the cryptographic security applied to 186 [IEEE.802-11.2012] frames. In (3a), the frames are terminated on the 187 WTP; in (3b) the frames are terminated on the AC. (4) Describes the 188 authentication and cryptography security between the WTP and the 189 access controller. 191 4. WTP to Access Controller Service Cryptographic Security 193 Specific to the Centralized WLAS Architecture is the establishment of 194 a secure channel between the WTP and the AC. This command channel 195 MUST be secured to insure both confidentiality and integrity of the 196 communication between the AC and the WTP. The IETF has defined 197 CAPWAP [RFC5415] to communicate between the WTP and the AC but there 198 are other, proprietary, tunneling protocols to perform the same task. 199 However, standards based security protocols such as DTLS, TLS or 200 IPSEC MUST provide the authenticity and integrity assurance for 201 securing any tunneling or encapsulation mechanism. 203 There are two channels between the WTP and AC that need security-- 204 the command and control channel; and, the data channel. Through the 205 command and control channel, the AC configures, queries and manages 206 the WTP, and the WTP reports status and airtime monitoring 207 information to the AC. Traffic sent between the client and the 208 network behind the AC goes through the data channel. 210 [RFC5415] defines using DTLS [RFC6347]to protect the control and data 211 channels. Other protocols such as IPSec [RFC4301] or TLS [RFC5246] 212 can also be implemented to secure the control traffic in addition to 213 the user data channel. 215 In order to establish secure connections between the WTP and AC 216 credentials MUST be deployed on each device. The most obvious choice 217 is an X.509 certificate which can be used to perform mutual 218 authentication with DTLS [RFC6347], IPsec [RFC4301] or TLS [RFC5246]. 220 5. Client to AAA Service Cryptographic Security 222 5.1. EAP Method 224 The [IEEE.802-11.2012]standard defines a Robust Security Network 225 (RSN). An RSN can utilizes IEEE 802.1x [IEEE.802-1X.2010] and the 226 Extensible Authentication Protocol [RFC3748], or it can use the SAE 227 protocol in [IEEE.802-11.2012] to provide authentication and key 228 management services between the client and WLAS. EAP Authentication 229 occurs between the client and the AAA service which may reside within 230 a component of the WLAS (WTP or AC) or as a standalone AAA Server. 231 It is not the intent of this document to specify the type of 232 transport for the authentication service (i.e RADIUS, Diameter 233 [RFC3588] etc) or the specific communication channel between the 234 Network Access Server (NAS) and the Authentication Service. Mutual- 235 Authentication is achieved through the establishment of a secure 236 channel for exchanging credentials between the client and the 237 Authentication Server utilizing an EAP method which satisfies the 238 requirements of [RFC4017]. The main output of the EAP process is the 239 generation of the Master Session Key (MSK) and Extended Master 240 Session Key (EMSK) known only to the Client (supplicant) and the AAA 241 server that will be used to generate the keying material for the 242 cipher suites. An in depth discussion on EAP Key management can be 243 found in EAP Key Management Framework document [RFC5247]. 245 5.2. Pre Shared Key, or Password, Method 247 When 802.1X is not used, a pre-shared key or password/passphrase can 248 be used with the SAE protocol from [IEEE.802-11.2012] to perform the 249 mutual authentication and key management functions required by an 250 RSN. SAE employs a zero-knowledge proof protocol that allows the 251 client and WTC/AC to prove knowledge of a shared secret (PSK or 252 password or passphrase) without disclosing the secret. It is 253 resistant to off-line dictionary attack. The result of the SAE 254 protocol is a cryptographically strong PMK based on discrete 255 logarithm cryptography. 257 An alternative to SAE is the pre-shared KEY mode of 258 [IEEE.802-11.2012] referred to by the Wi-Fi Alliance as Wi-Fi 259 Protected Access Personal (WPA2-PSK). With WPA2-PSK, the pre-shared 260 key repeatedly hashed to directly generate a 256-bit PMK. This 261 technique should be avoided, though, as is susceptible to off-line 262 dictionary attack and numerous attack tools to subvert WPA2-PSK exist 263 on the Internet. 265 6. Authenticator to AAA Service Cryptographic Security 267 As stated in the previous section, the byproduct of EAP 268 authentication is the generation of keying material to be used in the 269 cryptographic process between the client and the WTP to secure the 270 over the air communications. The AAA server generates the AAA key 271 which will be forwarded directly to the WTP in a Standalone WLAS, and 272 forwarded to the AC in a Centralized WLAS where they will generate 273 the Pairwise Master Key (PMK) (bits 0-255 of the AAA key). The 274 transmission of the AAA key needs to be protected between the AAA 275 server and the WTP or the AAA server and the AC depending on which 276 architecture is deployed. NIST has previously made recommendations 277 on securely encrypting plain text keying material for transport over 278 insecure media with AES Key Wrap [AES_Key_Wrap] as well as industry 279 with the Advanced Encryption Standard Key Wrap Algorithm [RFC3394]. 280 In addition to the transport of the keying material it is suggested 281 that all AAA traffic between the Authenticator (WTP or AC) and the 282 Authentication Service (AAA) be secured by standards based methods 283 such as, but not limited to: IPSEC, TLS or DTLS. 285 7. Wireless Link Layer Cryptographic Security 287 Upon completion of an authentication protocol, such as SAE or 288 [IEEE.802-1X.2010], the client and AC (or WTP) share a PMK. Since 289 the PMK may be been disclosed by an external AAA server to the AC (or 290 WTP) it is necessary to perform a key confirmation handshake. 291 [IEEE.802-11.2012] defines the 4-way Handshake to prove possession of 292 the PMK and to derive a transient session key, called the PTK, which 293 is used to secure the wireless link layer. During the 4-way 294 handshake, the WTP or AC also discloses a broadcast/multicast key, 295 called the GTK, to use for the wireless media. 297 Wireless link layer communication is protected through the Advanced 298 Encryption Standard Counter Mode with Cipher Block Chaining Message 299 Authentication Code Protocol (AES-CCMP). AES-CCMP is currently the 300 preferred cryptographic algorithm for both unicast and multicast/ 301 broadcast traffic. The client is the source and sink of a secure bi- 302 directional data flow. The other end of that flow can be either the 303 WTP or the AC, depending on whether it is a standalone WLAS 304 (Section 3.2) or a centralized WLAS (Section 3.3), respectively. 306 8. Cryptographic profiles 308 In each of the above architectural areas, there are a number of 309 different security protocols that serve various functions needed to 310 build secure wireless LAN architectures. Each protocol has important 311 choices to be made in context of this overall cryptographic security 312 within that protocol and subsequently has significant impacts to the 313 overall security parameters of the system. The security mechanisms 314 are summarized in Table 1. 316 +--------+------------+---------------+------------+----------------+ 317 | | Client | WTP | AC | AAA | 318 +--------+------------+---------------+------------+----------------+ 319 | Client | | 802.11 | 3rd Party; | EAP w/TLS | 320 | | | | 802.1x | | 321 | | | | Supplicant | | 322 +--------+------------+---------------+------------+----------------+ 323 | WTP | 802.11 | | DTLS; | TLS, DTLS, | 324 | | | | IPSEC | IPSec, AES | 325 | | | | | KeyWrap | 326 | | | | | (Standalone | 327 | | | | | Architecture) | 328 +--------+------------+---------------+------------+----------------+ 329 | AC | 3rd Party; | DTLS; IPSEC | | TLS, DTLS, | 330 | | 802.1x | | | IPSec, AES | 331 | | Supplicant | | | KeyWrap | 332 +--------+------------+---------------+------------+----------------+ 333 | AAA | EAP w/TLS | TLS, DTLS, | TLS, DTLS, | | 334 | | | IPSec, AES | IPSec, AES | | 335 | | | KeyWrap | KeyWrap | | 336 | | | (Standalone | | | 337 | | | Architecture) | | | 338 +--------+------------+---------------+------------+----------------+ 340 Table 1: Cryptographic Security Interactions 342 8.1. DTLS and TLS 344 TLS and DTLS are well studied and documented from a cryptographic 345 strength perspective and there are a number of works that create 346 profiles for TLS and DTLS and its use within systems of varying 347 security requirements. Table 2 provides an example of the 348 cryptographic functional requirements necessary to define a TLS 349 CipherSuite and associated security of each. When profiling against 350 this document, authors MUST define cryptographic algorithms for each 351 function in Table 2 352 +-------------+----------+------------+---------------+-------------+ 353 | Function | Example | Cryptograp | Algorithm | Cryptograph | 354 | | Algorith | h ic | Reference | i c Strengt | 355 | | m s | Strength | | h Reference | 356 +-------------+----------+------------+---------------+-------------+ 357 | Authenticat | RSA 2048 | 112 | [RFC3447] | NIST SP | 358 | i on | | | | 800-57 | 359 | | | | | [NIST800-57 | 360 | | | | | ] | 361 +-------------+----------+------------+---------------+-------------+ 362 | Key | ECC P256 | 128 | [RFC4492] | NIST SP | 363 | Exchange | | | | 800-57 | 364 | | | | | [NIST800-57 | 365 | | | | | ] | 366 +-------------+----------+------------+---------------+-------------+ 367 | Payload | AES 128 | 128 | [FIPS.197.200 | NIST SP | 368 | Protection | CBC | | 1 ] | 800-57 | 369 | | | | | [NIST800-57 | 370 | | | | | ] | 371 +-------------+----------+------------+---------------+-------------+ 372 | Message | HMAC-SHA | 128 | [NIST.PUB.198 | NIST SP | 373 | Auth | - 1 | | A ] | 800-57 | 374 | | | | | [NIST800-57 | 375 | | | | | ] | 376 +-------------+----------+------------+---------------+-------------+ 378 Table 2: DTLS and TLS Cryptographic Security Algorithms 380 Throughout the Wireless LAN Access System, TLS and DTLS are used in a 381 number of different places. Someone profiling wireless architectures 382 might require alternative algorithm definitions for different uses of 383 TLS/DTLS in the architecture. One example might be a place that 384 describes using TLS or DTLS to protect the transport of an ephemeral 385 key vs its use to protect a long lived secret. In this case, a 386 profile might be willing to trade off less security of the 387 cryptographic algorithms for the ephemeral key. 389 Table 3 shows the places in the wireless architectures described in 390 Section 3 that TLS or DTLS can be used 391 +---------------------+-----------+---------------------------------+ 392 | Location in | Protocol | Used to Protect | 393 | Architecture | | | 394 +---------------------+-----------+---------------------------------+ 395 | WTP To Access | CAPWAP | Management, session keys, user | 396 | Controller Service | using | traffic | 397 | (Section 4) | DTLS | | 398 +---------------------+-----------+---------------------------------+ 399 | Client to AAA | EAP | session keys, authentication | 400 | Service (Section 5) | method | | 401 | | using TLS | | 402 +---------------------+-----------+---------------------------------+ 403 | Authenticator to | DTLS/TLS, | Confidentiality and | 404 | AAA Service | IPSec | Authenticity of Radius traffic | 405 | (Section 6) | | (wrapped session keys) | 406 +---------------------+-----------+---------------------------------+ 408 Table 3: DTLS and TLS Architectural Usage 410 8.2. X.509 Certificates 412 The security level provided by algorithm and key length choice for 413 X.509 Certificates is well studied solely in context of the 414 certificates itself. Table 4 lists the types of cryptographic 415 security functions used within X.509 Certificates and provides 416 examples for each. Any profile of Wireless LAN Architecture MUST 417 include definitions for each cryptographic security function used 418 within X.509 certificates. 420 +----------+-----------+--------------+-------------+---------------+ 421 | Function | Example | Cryptographi | Algorithm | Cryptographic | 422 | | Algorithm | c Strength | Reference | Strength | 423 | | s | | | Reference | 424 +----------+-----------+--------------+-------------+---------------+ 425 | Signatur | RSA with | 112 | [RFC3447] | NIST SP | 426 | e | 2048 bit | | | 800-57 | 427 | Algorit | public | | | [NIST800-57] | 428 | hm | keys | | | | 429 +----------+-----------+--------------+-------------+---------------+ 430 | Public | RSA 2048 | 112 | [RFC3447] | NIST SP | 431 | Key | | | | 800-57 | 432 | Algorith | | | | [NIST800-57] | 433 | m | | | | | 434 +----------+-----------+--------------+-------------+---------------+ 435 | Hash | SHA256 | 128 | [FIPS-180-3 | NIST SP | 436 | Function | | | ] | 800-57 | 437 | | | | | [NIST800-57] | 438 +----------+-----------+--------------+-------------+---------------+ 439 Table 4: X.509 Certificate Cryptographic Security Functions 441 Throughout the Wireless LAN Access System, X.509 certificates are 442 used in a number of different places. Table 5 shows the places in 443 the wireless architectures described in Section 3 that X.509 444 Certificates are potentially used 446 +----------------------+----------------+---------------------------+ 447 | Location in | Protocol | Used to Protect | 448 | Architecture | | | 449 +----------------------+----------------+---------------------------+ 450 | WTP To Access | DTLS used | Authenticity of | 451 | Controller Service | within CAPWAP; | Management, session keys, | 452 | (Section 4) | IPSec | user traffic | 453 +----------------------+----------------+---------------------------+ 454 | Client to AAA | TLS (Example | Authenticity of session | 455 | Service (Section 5) | EAP Method) | keys, authentication | 456 +----------------------+----------------+---------------------------+ 457 | Authenticator to AAA | DTLS, TLS or | Authenticity of AAA | 458 | Service (Section 6) | IPSec | traffic (wrapped session | 459 | | | keys) | 460 +----------------------+----------------+---------------------------+ 462 Table 5: X.509 Architectural Usage 464 8.3. Link Layer Encryption 466 Link Layer encryption for Wireless LAN Access Systems is well defined 467 by the IEEE 802.11-2012 standard Future 802.11 standards need to 468 address link layer encryption as an integral part of the standard. 469 Current 802.11 standards require the implementation of 128 bit key 470 length. 472 +------------+-----------+------------+----------------+------------+ 473 | Function | Example | Cryptograp | Algorithm | Cryptograp | 474 | | Algorithm | h ic | Reference | h ic | 475 | | s | Strength | | Strength | 476 | | | | | Referenc | 477 | | | | | e | 478 +------------+-----------+------------+----------------+------------+ 479 | 802.1x 4 | AES Key | 128 | [IEEE.802-11.2 | NIST SP | 480 | Way | Wrap with | | 0 12] | 800-57 | 481 | Handshake | HMAC-SHA1 | | | [NIST800-5 | 482 | | - 128 | | | 7 ] | 483 +------------+-----------+------------+----------------+------------+ 484 +------------+-----------+------------+----------------+------------+ 485 | Message | HMAC-SHA- | 128 | [NIST.PUB.198A | NIST SP | 486 | Authentica | 1 | | ] | 800-57 | 487 | t ion | | | | [NIST800-5 | 488 | | | | | 7 ] | 489 +------------+-----------+------------+----------------+------------+ 490 | Pseudo-Ran | HMAC-SHA- | 128 | [NIST.PUB.198A | NIST SP | 491 | d om | 1 | | ] | 800-57 | 492 | Function | | | | [NIST800-5 | 493 | | | | | 7 ] | 494 +------------+-----------+------------+----------------+------------+ 495 | 802.11 | AES-CCMP | 128 | [FIPS.197.2001 | NIST SP | 496 | Management | | | ] | 800-57 | 497 | Frame | | | | [NIST800-5 | 498 | Encryption | | | | 7 ] | 499 +------------+-----------+------------+----------------+------------+ 500 | 802.11 | AES-CCMP | 128 | [FIPS.197.2001 | NIST SP | 501 | Payload | | | ] | 800-57 | 502 | Encryption | | | | [NIST800-5 | 503 | | | | | 7 ] | 504 +------------+-----------+------------+----------------+------------+ 506 Table 6: Link Layer Security Algorithms 508 As a minimum, link layer encryption needs to be used in wireless 509 architectures as indicated in Table 7 to protect the data in transit. 510 When profiling against this document, authors MUST define 511 cryptographic algorithms for each function described in Table 7. In 512 addition to over the air link layer encryption, there are other 513 places where related, but different link layer encryption (i.e. 514 802.1ae) could be leveraged within the wireless architecture. Link 515 layer encryption in these alternative places MAY be profiled for use 516 in the overall cryptographic integrity of the system but are not 517 covered here. 519 +--------------+------------+---------------------------------------+ 520 | Location in | Protocol | Used to Protect | 521 | Architecture | | | 522 +--------------+------------+---------------------------------------+ 523 | Client to | AES-CCMP, | 802.1x 4-way handshake (stand alone | 524 | WTP | AES Key | configuration), 802.11 | 525 | (Section 7) | Wrap, | unicast/multicast data frames and | 526 | | HMAC-SHA-1 | Management Frame protection using the | 527 | | | Integrity Group Temporal Key (IGTK) | 528 +--------------+------------+---------------------------------------+ 529 +--------------+------------+---------------------------------------+ 530 | Client to AC | AES-CCMP, | 802.1x 4-way handshake and optional | 531 | | AES Key | configuration where 802.11 | 532 | | Wrap, | unicast/multicast data frames and | 533 | | HMAC-SHA-1 | Management Frame protection using the | 534 | | | Integrity Group Temporal Key | 535 | | | (IGTK)encryption is performed on the | 536 | | | AC | 537 +--------------+------------+---------------------------------------+ 539 Table 7: Link Layer Encryption Architectural Uses 541 8.4. AAA 543 It is strongly suggested that traffic between the WTP/AC and the AAA 544 service be secured to provide confidentiality and integrity of the 545 user/device being authenticated as well as the key data used for the 546 encryption process. The use of the well documented cryptographic 547 protocols IPSEC (Section 8.5), TLS or DTLS (Section 8.1) can be used 548 to protect traffic between the WTP/AC and the AAA service. When 549 profiling against this document, authors MUST define the 550 cryptographic algorithms for each function in listed in Table 8 552 +---------------+----------------+----------------------------------+ 553 | Location in | Protocol | Used to Protect | 554 | Architecture | | | 555 +---------------+----------------+----------------------------------+ 556 | Authenticator | TLS/DTLS or | Used to secure all | 557 | to AAA | IPSec | authentication traffic between | 558 | (Section 6) | | the Authenticator (WTP or AC) | 559 | | | and the AAA service | 560 +---------------+----------------+----------------------------------+ 561 | Authenticator | AES Key Wrap | Used to encrypt only the key | 562 | to AAA | [AES_Key_Wrap] | data between the Authenticator | 563 | (Section 6) | | (WTP or AC) and the AAA services | 564 +---------------+----------------+----------------------------------+ 565 | Client to AAA | EAP | Used to perform authentication | 566 | (Section 5) | | between Client and AAA server | 567 +---------------+----------------+----------------------------------+ 569 Table 8: AAA Security Architectural Uses 571 8.5. IPSEC 573 IPSEC is well studied and documented from a cryptographic strength 574 perspective and there are a number of works that create profiles for 575 IPSEC and its use within systems of varying security requirements. 576 Table 9 provides an example of the cryptographic functional 577 requirements necessary to define an IPSEC CipherSuite and associated 578 security of each. When profiling against this document, authors MUST 579 define cryptographic algorithms for each function in Table 9 581 +------------+-----------+------------+--------------+--------------+ 582 | Function | Example | Cryptograp | Algorithm | Cryptographi | 583 | | Algorithm | h ic | Reference | c Strength | 584 | | s | Strength | | Reference | 585 +------------+-----------+------------+--------------+--------------+ 586 | IKE | RSA 2048 | 112 | [RFC3447] | NIST SP | 587 | Authentica | | | | 800-57 | 588 | t ion | | | | [NIST800-57] | 589 +------------+-----------+------------+--------------+--------------+ 590 | IKE | HMAC-SHA- | 256 | [RFC4868] | NIST SP | 591 | Pseudo-ran | 2 56 | | | 800-57 | 592 | d om | | | | [NIST800-57] | 593 | Function | | | | | 594 +------------+-----------+------------+--------------+--------------+ 595 | IKE | Group 14 | 112 | [RFC3526] | NIST SP | 596 | Diffie-Hel | | | | 800-57 | 597 | l man grou | | | | [NIST800-57] | 598 | p | | | | | 599 +------------+-----------+------------+--------------+--------------+ 600 | IKE Hash | SHA-256 | 128 | [FIPS-180-3] | NIST SP | 601 | | | | | 800-57 | 602 | | | | | [NIST800-57] | 603 +------------+-----------+------------+--------------+--------------+ 604 | IKE | AES 128 | 128 | [FIPS.197.20 | NIST SP | 605 | Encryption | CBC | | 0 1] | 800-57 | 606 | | | | | [NIST800-57] | 607 +------------+-----------+------------+--------------+--------------+ 608 | ESP | AES-CBC | 128 | [FIPS.197.20 | NIST SP | 609 | Encryption | | | 0 1] | 800-57 | 610 | | | | | [NIST800-57] | 611 +------------+-----------+------------+--------------+--------------+ 612 | ESP | HMAC-SHA1 | 128 | [FIPS-180-3] | [NIST.PUB.19 | 613 | Integrity | | | | 8 A] | 614 +------------+-----------+------------+--------------+--------------+ 616 Table 9: IPSEC Cryptographic Security Algorithms 618 IPSec in many cases has been superseded by other protocols for 619 security within the Wireless LAN Access System. However, IPSEC could 620 play a role and Table 10 describes places in the WLAN Access System 621 Architecture (Section 3) where it can be utilized. 623 +----------------------+----------+---------------------------------+ 624 | Location in | Protocol | Used to Protect | 625 | Architecture | | | 626 +----------------------+----------+---------------------------------+ 627 | WTP To Access | IPSec | Authenticity of Management, | 628 | Controller Service | | session keys, user traffic | 629 | (Section 4) | | | 630 +----------------------+----------+---------------------------------+ 631 | Authenticator to AAA | IPSec | Authenticity and | 632 | Service (Section 6) | | Confidentiality of AAA traffic | 633 | | | (wrapped session keys) | 634 +----------------------+----------+---------------------------------+ 636 Table 10: IPSEC Architectural Usage 638 9. Security Considerations 640 The cryptographic security level of a complex system is limited to 641 that of the weakest component in the system. The use of 128-bit 642 block ciphers with 128-bit keys is now common, but in many systems, 643 the security is limited by other factors, such as public keys with a 644 strength of just 80 bits, or keys that are manually configured. A 645 typical security protocol uses multiple cryptographic algorithms to 646 achieve different security goals: encryption to provide 647 confidentiality, data authentication to protect the integrity of 648 data, key derivation to provide the keys for those algorithms, key 649 establishment to determine shared keys, and digital signatures to 650 authenticate the entity on the other end of the wire. In order to 651 provide a high security level, a protocol needs to use algorithms and 652 parameters that consistently meet that security goal. Wireless 653 systems use multiple security protocols, thus requiring consistency 654 across multiple protocols. To achieve consistency, one must first 655 understand all of the cryptographic components in a wireless system. 656 This note makes that process easier, by cataloging the components 657 that appear in typical wireless architectures. 659 It is also important to note that not all secrets are equal. A 660 secret which gives you access to data for a short period of time 661 might be considered less important than one that exposes data for a 662 longer period of time. Depending on the system being built and 663 associated security constraints, the value of the secret being 664 protected can inform appropriate choices for the cryptographic 665 strength over sub components of a wireless architecture. 667 Finally, this note is intended to encourage the use of consistent 668 cryptographic strengths of confidentiality, integrity and 669 authenticity within the entire wireless LAN architecture. While 670 profiles of this document might justify inconsistent algorithm 671 strength choices, the profiles need to use cryptography throughout 672 the architecture to provide end-to-end security. 674 9.1. Algorithm Choices 676 The choices of the algorithms to use in this document are left to the 677 profile authors discretion. However, it must be clear that profiles 678 need to avoid the use of known broken cryptographic algorithms (i.e. 679 WEP, TKIP, etc). 681 10. IANA Considerations 683 None 685 11. Acknowledgements 687 The authors would like to acknowledge David McGrew, Nancy Cam-Winget 688 and Carlos Pignataro for their constructive comments on this 689 document. 691 12. References 693 12.1. Normative References 695 [IEEE.802-11.2012] 696 "IEEE Standard for Information technology-- 697 Telecommunications and information exchange between 698 systems-- Local and metropolitan area networks-- Specific 699 requirements Part 11: Wireless LAN Medium Access Control 700 (MAC) and Physical Layer (PHY) Specifications", 701 March 2012, . 704 [IEEE.802-1X.2010] 705 "IEEE Standard for Local and metropolitan area networks - 706 Port-Based Network Access Control", 2010, . 709 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 710 "Remote Authentication Dial In User Service (RADIUS)", 711 RFC 2865, June 2000. 713 [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And 714 Provisioning of Wireless Access Points (CAPWAP) Protocol 715 Specification", RFC 5415, March 2009. 717 12.2. Informative References 719 [AES_Key_Wrap] 720 "", . 723 [FIPS-180-3] 724 FIPS Publication 180-3, "Secured Hash Standard", 725 FIPS 180-3, October 2008. 727 [FIPS.197.2001] 728 National Institute of Standards and Technology, "Advanced 729 Encryption Standard (AES)", FIPS PUB 197, November 2001, < 730 http://csrc.nist.gov/publications/fips/fips197/ 731 fips-197.pdf>. 733 [NIST.PUB.198A] 734 National Institute of Standards and Technology, "The 735 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 736 198A, March 2002, . 739 [NIST800-57] 740 Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 741 "Recommendations for Key Management", NIST SP 800-57, 742 March 2007. 744 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 745 Requirement Levels", BCP 14, RFC 2119, March 1997. 747 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 748 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 750 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 751 Standards (PKCS) #1: RSA Cryptography Specifications 752 Version 2.1", RFC 3447, February 2003. 754 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 755 Diffie-Hellman groups for Internet Key Exchange (IKE)", 756 RFC 3526, May 2003. 758 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 759 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 761 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 762 Levkowetz, "Extensible Authentication Protocol (EAP)", 763 RFC 3748, June 2004. 765 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 766 Authentication Protocol (EAP) Method Requirements for 767 Wireless LANs", RFC 4017, March 2005. 769 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 770 Internet Protocol", RFC 4301, December 2005. 772 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 773 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 774 for Transport Layer Security (TLS)", RFC 4492, May 2006. 776 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 777 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 779 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 780 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 782 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 783 Authentication Protocol (EAP) Key Management Framework", 784 RFC 5247, August 2008. 786 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 787 Security Version 1.2", RFC 6347, January 2012. 789 Authors' Addresses 791 Stephen M. Orr 792 Cisco Systems, Inc. 793 1 Paragon Drive 794 Suite 275 795 Montvale, NJ 07645 796 US 798 Email: sorr@cisco.com 800 Anthony H. Grieco 801 Cisco Systems, Inc. 802 7025 Kit Creek Road 803 RTP, NC 27709 804 US 806 Email: agrieco@cisco.com 808 Dan Harkins 809 Aruba Networks 810 1322 Crossman ave 811 Sunnyvale, CA 94089 812 US 814 Email: dharkins@arubanetworks.com