Network Access Control (NAC) refers to methods used to authorize or deny network communications to particular systems or users. Defined by the IEEE, the 802.1X Port-Based Network Access Control (PNAC) standard is commonly used with TCP/
IP networks to support LAN security in enterprises, for both wired and wireless networks. The purpose of PNAC is to provide access to a network (e.g., intranet or the Internet) only if a system and/or its user has been authenticated based on the system’s network attachment point. Used in conjunction with the IETF standard Extensible Authentication Protocol (EAP) [RFC3748], 802.1X is sometimes called EAP over LAN (EAPoL), although the 802.1X standard covers more than just the EAPoL packet format.
The most common variant of 802.1X is based on the standard as published in 2004, however, [802.1X-2010] includes compatibility with 802.1AE (IEEE standard LAN encryption called MACSec) and 802.1AR (X.509 certificates for secure device identities). It also includes a somewhat complex MACSec key agreement protocol called MKA that we do not discuss further. In 802.1X, a system being authenti- cated implements a function known as a supplicant. The supplicant interacts with an authenticator and a backend authentication server to perform authentication and gain network access. VLANs (see Chapter 3) are often used in helping to enforce the access control decisions made by 802.1X.
EAP can be used with multiple link-layer technologies and supports multiple methods for implementing authentication, authorization, and accounting (AAA). EAP does not perform encryption itself, so it must be used in conjunction with some other cryptographically strong protocol to be secure. When used with link-layer
ptg999 encryption such as WPA2 on wireless networks or 802.1AE on wired networks,
802.1X is relatively secure. EAP uses the same concepts of supplicant and authen- tication server as does 802.1X, but with different terminology (EAP uses the terms peer, authenticator, and AAA server although even in EAP-related literature backend authentication server is sometimes used). An example setup is shown in Figure 18-5.
,QWHUQHW
&RUS9/$1
5HPHGLDWLRQ*XHVW 6HUYHU
$XWKHQWLFDWLRQ
$XWKRUL]DWLRQDQG$FFRXQWLQJ
$$$6HUYHU
5HPHGLDWLRQ 9/$1 :LUHOHVV3HHU
6XSSOLFDQW
$XWKHQWLFDWRU
; ($3R/
'LDPHWHURU 5$',86
,QWUDQHW 6HUYHU
L
:LUHG3HHU 6XSSOLFDQW
($3 3DVV7KURXJK
Figure 18-5 EAP, supported by 802.11i and 802.1X, allows for a peer (supplicant) to be authenticated by an authenticator that is separate from an AAA server. The authenticator can operate in “pass- through” mode in which it does little more than forward EAP packets. It can also participate more directly in the EAP protocol. The pass-through mode allows authenticators to avoid having to implement a large number of authentication methods.
In this figure we see a hypothetical enterprise network including wired and wireless peers, a protected network that includes the AAA server and another intranet server on a particular VLAN, and an unauthenticated or “remediation”
VLAN. The authenticator’s job is to interact with unauthenticated peers and the AAA server (via AAA protocols such as RADIUS [RFC2865][RFC3162] or Diameter [RFC3588]) to determine if each peer should be granted access to the protected net- work. If so, this can be accomplished in several ways. The most common approach is to make a VLAN mapping adjustment so that the authenticated peer is assigned to the protected VLAN or to another VLAN that provides connectivity to the protected VLAN using a router (layer 3). An authenticator may use VLAN trunking (IEEE 802.1AX link aggregation; see Chapter 3) and may be capable of assigning VLAN tags based on port number or forwarding VLAN tagged frames sent by the peer.
Note
In some EAP deployments, the authenticator is used without an AAA server, and the authenticator must evaluate the peer’s credentials on its own. When refer- ring to the location where authentication is determined, the term EAP server is used in the EAP literature. Generally, the EAP server is the AAA server (backend authentication server) when the authenticator acts in pass-through mode and is the authenticator otherwise.
ptg999 Section 18.7 Network Access Control: 802.1X, 802.1AE, EAP, and PANA 835
In 802.1X, the protocol between the supplicant and the authenticator is divided into a lower and upper sublayer. The lower layer is called the port access control protocol (PACP). The higher layer is ordinarily some variant of EAP. For use with 802.1AR, the variant is called EAP-TLS [RFC5216]. PACP uses EAPoL frames for communication, even if EAP authentication is not used (e.g., when MKA is used).
EAPoL frames use an Ethertype field value of 0x888E (see Chapter 3).
Moving to IETF standards, EAP is not a single protocol but rather a frame- work for achieving authentication using a combination of other protocols, some of which we discuss throughout the chapter, including TLS and IKEv2. The baseline EAP packet format is shown in Figure 18-6.
/HQJWK
,GHQWLILHU
&RGH 'DWD
Figure 18-6 The EAP header includes a Code field for demultiplexing packet types (Request, Response, Success, Failure, Initiate, Finish). The Identifier helps match requests to responses. For request and response messages, the first data byte is a Type field.
The EAP packet format is simple. In Figure 18-6, the Code field contains one of six EAP packet types: Request (1), Response (2), Success (3), Failure (4), Initiate (5), and Finish (6). The last two are defined by the EAP Re-authentication Protocol (see Section 18.7.2); the official field values are maintained by the IANA [IEAP].
The Identifier field contains a number chosen by the sender and is used to match requests with replies. The Length field gives the number of bytes in the EAP mes- sage, including the Code, Identifier, and Length fields. Requests and responses are used to perform identification and authentication with the peer, ultimately result- ing in a Success or Failure indication. The protocol is capable of carrying an infor- mative message so that human users can be given some instructions about what to do if their system is unable to authenticate. It is a reliable protocol that runs on a lower-layer protocol that is assumed to preserve order but is not assumed to be reliable. EAP itself does not implement other features such as congestion or flow control but may use protocols that do.
The typical EAP exchange starts with the authenticator sending a Request message to the peer. The peer responds with a Response message. Both messages use the same format, as shown in Figure 18-6. An overview of the exchange is shown in Figure 18-7.
The primary purpose of the Request and Response messages is to exchange whatever information is required to allow an authentication method to succeed.
Numerous methods are defined within [RFC3748], and several are defined in other standards. The particular method being used is encoded in the Type field of
ptg999
Request and Response messages using values of 4 or greater. Other special Type field values include Identity (1), Notification (2), Nak (“Legacy Nak”) (3), and an Expanded Type extension (254). The Identity type is used by an authenticator to ask the peer its identifying information and provide a method for the peer to respond. The Notification type is used to display a message or notification to a user or log file (not for errors, but for notifications). When a peer does not support a method requested by the authenticator, it replies with a negative ACK (either a Legacy Nak or an Extended Nak). Extended Naks include a vector of implemented authentication methods not present in Legacy Naks.
EAP is a layered architecture that supports its own multiplexing and demulti- plexing. Conceptually, it consists of four layers: the lower layer (for which there are multiple protocols), EAP layer, EAP peer/authenticator layer, and EAP methods
5HTXHVW 7\SH
$GGLWLRQDO 5HTXHVWV 5HVSRQVH 7\SH
3HHU
6XSSOLFDQW $XWKHQWLFDWRU
'DWD([FKDQJH
$GGLWLRQDO 5HVSRQVHV 'HSHQGVRQ
$XWKHQWLFDWLRQ 0HWKRG HJ0'&KDOOHQJH
($37/6
$$$6HUYHU
%DFNHQG$XWKHQWLFDWLRQ6HUYHU
3DVV7KURXJK 'LDPHWHU
5$',86 0HVVDJHV
6XFFHVV
'LDPHWHU 5$',86 0HVVDJHV
'LDPHWHU5$',86 0HVVDJHV
Figure 18-7 The baseline EAP messages carry authentication material between the peer and the authenticator. In many deployments, the authenticator is a relatively simple device that acts in a “pass-through” mode. In such cases, most of the protocol processing takes place on the peer and AAA server. IETF standard AAA-specific protocols such as RADIUS or Diameter may be used to encapsulate EAP messages carried between the AAA server and authenticator.
ptg999 Section 18.7 Network Access Control: 802.1X, 802.1AE, EAP, and PANA 837
layer (for which there are many methods). The lower layer is responsible for trans- porting EAP frames in order. Perhaps ironically, some of the protocols used to transport EAP are actually higher-layer protocols, many of which we have dis- cussed already. Examples of EAP “lower-layer” protocols include 802.1X, 802.11 (802.11i) (see Chapter 3), UDP with L2TP (see Chapter 3), UDP with IKEv2 (see Section 18.8.1), and TCP (see Chapters 12–17). Figure 18-8 shows how the layers are implemented in conjunction with a pass-through authenticator. A pass-through server would be the opposite but is not supported by RADIUS or Diameter.
($33HHU/D\HU
/RZHU/D\HU
/RZHU/D\HU
/RZHU/D\HU ($3/D\HU
($30HWKRG ($30HWKRG
$$$3URWRFRO ($3/D\HU
($3$XWK ($30HWKRG
3HHU 3DVV7KURXJK
$XWKHQWLFDWRU
$$$
6HUYHU
/RZHU/D\HU $$$3URWRFRO ($3/D\HU ($33HHU
/D\HU ($3$XWK
Figure 18.8 The EAP stack and implementation model. In the pass-through mode, the peer and AAA server are responsible for implementing the EAP authentication methods. The authenticator need only implement EAP message processing, the authenticator process- ing, and enough of an AAA protocol (e.g., RADIUS, Diameter) to exchange information with the AAA server.
In the “EAP stack” depicted in Figure 18-8, the EAP layer implements reliabil- ity and duplicate elimination. It also performs demultiplexing based on the code value in EAP packets. The peer/authenticator layer is responsible for implementing the peer and/or authenticator protocol messages, based on demultiplexing of the Code field. The EAP methods layer consists of all the specific methods to be used for authentication, including any required protocol operations to handle large mes- sages. This is necessary because the rest of the EAP protocol does not implement fragmentation and some methods may require large messages (e.g., containing certificates or certificate chains).
18.7.1 EAP Methods and Key Derivation
Given its architecture, many EAP authentication and encapsulation methods are available for use (more than 50). Some are specified by IETF standards, and others have evolved separately (e.g., from Cisco or Microsoft). Some of the more common
ptg999 methods include TTLS [RFC5281], TLS [RFC5216], FAST [RFC4851], LEAP (Cisco
proprietary), PEAP (EAP over TLS, Cisco proprietary), IKEv2 (experimental) [RFC5106], and MD5. Of these, only MD5 is specified in [RFC3748], but it is no longer recommended for use. Unfortunately, the complexity does not end when specifying one of these methods alone. Within each method there are sometimes different options for cryptographic suites or identity verification. With PEAP, for example, some versions of Microsoft Windows support MSCHAPv2 and TLS.
The reasons for having so many options are partly historical. As security and operational experience have evolved over time, some methods were found to be too insecure or insufficiently flexible. Some authentication methods require an operating PKI that can provide client certificates (e.g., EAP-TLS), while others (e.g., PEAP, TTLS) do not require such infrastructure. Older protocols (e.g., LEAP) were designed at a time when other standards such as 802.11 (incorporating 802.11i) were not yet mature. Consequently, depending on the particular environment, various combinations of smart cards or tokens, passwords, or certificates may be required to use EAP.
The purpose of the EAP methods is to establish authentication, and possibly authorization for network access. In some cases (e.g., EAP-TLS), the methods pro- vide bidirectional authentication, whereby each end acts as both an authenticator and a peer. The type of authentication provided by a method is often a conse- quence of the cryptographic primitives it employs.
Some methods provide more than authentication. Those that provide key deri- vation are able to agree upon and export keys in a key hierarchy [RFC5247] and must provide for mutual authentication between the EAP peer and EAP server.
The master session key (MSK, also called AAA-key) is used in deriving other keys using a KDF, either at an EAP peer or authenticator. MSKs are at least 64 bytes in length and are typically used to derive transient session keys (TSKs) that are used to enforce access control between a peer and an authenticator, often at lower layers.
Extended MSKs (EMSKs) are also provided along with MSKs but are made avail- able only to the EAP server or peer, not to pass-through authenticators, and are used in deriving root keys [RFC5295]. Root keys are keys associated with particular usages or domains. A usage-specific root key (USRK) is a key derived from an EMSK in the context with a particular usage. A domain-specific root key (DSRK) is a key derived from an EMSK for use in a particular domain (i.e., collection of systems).
Child keys derived from a DSRK are known as domain-specific usage-specific root keys (DSUSRKs).
During an EAP exchange, multiple peer and server identities may be used, and a session identifier is allocated. On completion of an EAP-based authentica- tion where key derivation is supported, the MSK, EMSK, peer identifier(s), server identifier(s), and a session ID are made available to lower layers. (A now-depre- cated initialization vector might also be provided.) Keys generally have an asso- ciated lifetime (8 hours is recommended), after which EAP re-authentication is required. For an in-depth discussion of EAP’s key management framework and an accompanying detailed security analysis, please see [RFC5247].
ptg999 Section 18.7 Network Access Control: 802.1X, 802.1AE, EAP, and PANA 839
18.7.2 The EAP Re-authentication Protocol (ERP)
In cases where EAP authentication has completed successfully, it is often desirable to reduce latency if a subsequent authentication exchange is required (e.g., a mobile node moves from one access point to another). The EAP Re-authentication Protocol (ERP) [RFC5296] provides the ability to do this independent of any particular EAP method. EAP peers and servers that support ERP are called ER peers and servers, respectively. ERP uses a re-authentication root key (rRK) derived from a DSRK (or the EMSK, but [RFC5295] suggests avoiding this) along with a re-authentication integrity key (rIK) derived from the rRK used to prove knowledge of the rRK.
ERP operates in a single round-trip time, which is consistent with its goal of reducing re-authentication latency. ERP begins with a full conventional EAP exchange, assumed to be in the “home” domain. The MSK generated is distrib- uted to the authenticator and peer as usual. However, the rIK and rRK values are also determined at this time and shared only between the peer and EAP server.
These values can be used in the home domain, along with rMSKs generated for each authenticator. When the ER peer moves to a different domain, different val- ues (DS-rIK and DS-rRK, which are DSUSRKs) are used. The domain of the ER server is contained in a TLV area in ERP messages, allowing peers to determine the domain of the server with which they are communicating. Details of the pro- tocol are given in [RFC5296].
18.7.3 Protocol for Carrying Authentication for Network Access (PANA)
While combinations of EAP, 802.1X, and PPP have all been used to support authen- tication of the client (and network, in some cases), they are not entirely link-inde- pendent. EAP tends to be implemented for particular links, 802.1X applies to IEEE 802 networks, and PPP uses a point-to-point network model. To address this con- cern, the Protocol for Carrying Authentication for Network Access (PANA) has been defined in [RFC5191], [RFC5193], and [RFC6345] based on requirements set out in [RFC4058] and [RFC4016]. It acts as an EAP lower layer, meaning it acts as a “car- rier” for EAP information. It uses UDP/IP (port 716) and is therefore applicable to more than a single type of link, and it is not limited to a point-to-point network model. In effect, PANA allows EAP authentication methods to be used on any link-layer technology for determining network access.
The PANA framework includes three main functional entities: the PANA Cli- ent (PaC), PANA Authentication Agent (PAA), and the PANA Relay Element (PRE).
Normal usage also involves an Authentication Server (AS) and Enforcement Point (EP). The AS may be a conventional AAA server accessed using access protocols such as RADIUS or Diameter. The PAA is responsible for conveying authentica- tion material from a PaC to the AS, and for configuration of the EP when network access is approved or revoked. Some of these entities may be colocated. The PaC and associated EAP peer are always colocated, as are the EAP authenticator and PAA. A PRE can be used to relay communications between a PaC and PAA when direct communication is not otherwise possible.
ptg999 The PANA protocol consists of a set of request/response messages including
an extensible set of attribute-value pairs managed by the IANA [IPANA]. The pri- mary payloads are EAP messages, sent in UDP/IP datagrams as part of a PANA session. There are four phases in a PANA session: authentication/authorization, access, re-authentication, and termination. The re-authentication phase is really a portion of the access phase wherein the session lifetime is extended by re-execut- ing EAP-based authentication. The termination phase is entered either explicitly or as the result of the session timing out (either because of lifetime exhaustion or failure of liveness detection). PANA sessions are identified by a 32-bit session identifier included in each PANA message.
PANA also provides a form of reliable transport protocol. Each message contains a 32-bit sequence number. The sender keeps track of the next sequence number to send, and receivers keep track of the next expected sequence number.
Answers contain the same sequence number as the corresponding request. Ini- tial sequence numbers are randomly selected by the sender of the message (i.e., PaC or PAA). PANA also implements time-based retransmission. PANA is a weak transport protocol—it operates in a stop-and-wait fashion, does not use an adap- tive retransmission timer, and cannot perform repacketization. It does, however, perform exponential backoff on its retransmission timer when faced with multiple packet losses.