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 authenticated 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 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 authentication 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.
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 “passthrough” mode in which it does little more than forwarding 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.
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 network. 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 referring 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.
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 framework 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.
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 message, including the Code, Identifier, and Length fields. Requests and responses are used to perform identification and authentication with the peer, ultimately resulting in a Success or Failure indication. The protocol is capable of carrying an informative 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.
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.
[View full size image]
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 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 demultiplexing. Conceptually, it consists of four layers: the lower layer (for which there are multiple protocols), EAP layer, EAP peer/authenticator layer, and EAP methods layer (for which there are many methods). The lower layer is responsible for transporting EAP frames in order. Perhaps ironically, some of the protocols used to transport EAP are actually higher-layer protocols, many of which we have discussed 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.
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 processing, and enough of an AAA protocol (e.g., RADIUS, Diameter) to exchange information with the AAA server.
[View full size image]
In the “EAP stack” depicted in Figure 18-8, the EAP layer implements reliability 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 messages. 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 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 provide bidirectional authentication, whereby each end acts as both an authenticator and a peer. The type of authentication provided by a method is often a consequence of the cryptographic primitives it employs.
Some methods provide more than authentication. Those that provide key derivation 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 available 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 authentication 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-deprecated initialization vector might also be provided.) Keys generally have an associated 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].
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 distributed 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 values (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 protocol 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 authentication of the client (and network, in some cases), they are not entirely link-independent. 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 concern, 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 “carrier” 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 Client (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 authentication 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.
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 primary 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-executing 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. Initial 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 adaptive retransmission timer, and cannot perform repacketization. It does, however, perform exponential backoff on its retransmission timer when faced with multiple packet losses.
We’ll use the Telnet service for our example. Since Telnet is an insecure protocol that must sometimes be supported due to legacy applications and systems, using inline authentication here is an additional layer of security that we can apply to our connection.
juniper@SRX5800# edit access firewall-authentication pass-through
[edit access firewall-authentication pass-through]
juniper@SRX5800# set default-profile web-allow-group
[edit access firewall-authentication pass-through]
juniper@SRX5800# set telnet banner success "PLEASE ENTER IN YOUR ACCOUNT INFO.
FOR SUPPORT PLEASE CALL THE NOC AT 1-800-555-1212"
[edit access firewall-authentication pass-through]
juniper@SRX5800# top
[edit]
juniper@SRX5800# edit security policies from-zone trust to-zone web-dmz
[edit security policies from-zone trust to-zone web-dmz]
juniper@SRX5800# set policy permit-telnet match source-address any
destination-address any
[edit security policies from-zone trust to-zone web-dmz]
juniper@SRX5800# set policy permit-telnet match application junos-telnet
[edit security policies from-zone trust to-zone web-dmz]
juniper@SRX5800# set policy permit-telnet then permit firewall-authentication
pass-through access-profile web-allow-group
And here is what that configuration looks like all together:
juniper@SRX5800# show | compare
[edit security policies from-zone trust to-zone web-dmz]
policy web_deny { ... }
+ policy permit-telnet {
+ match {
+ source-address any;
+ destination-address any;
+ application junos-telnet;
+ }
+ then {
+ permit {
+ firewall-authentication {
+ pass-through {
+ access-profile web-allow-group;
+ }
+ }
+ }
+ }
+ }
We can view active authenticated information about the SRX’s authentications using the following output:
juniper@SRX5800# show security firewall-authentication users
Firewall authentication data:
Total users in table: 1
Id Source Ip Src zone Dst zone Profile Age Status User
4 10.3.0.12 Trust Internet webauth- 4 Success Tim
The show security firewall-authentication history command shows all active and authenticated users currently passing through the SRX:
juniper@SRX5800> show security firewall-authentication history
History of firewall authentication data: Authentications: 2 Id Source Ip
Date Time Duration Status User
1 10.1.0.120 2010-01-12 18:20:02 0: 00:22 Failed bob
2 10.1.0.125 2010-01-13 12:22:48 0: 00:21 Success bill
Firewall authentication provides an additional layer of security as well as logs. It can be used to enforce company access policies or better protect network boundaries and access. It is a very simple way to improve the overall security strategy of anything from the smallest home office to a large corporate network.
What is the difference between DMZ and IP Pass-through?
Question asked by colton_w24 on Feb 5, 2017
Latest reply on Oct 15, 2018 by emmawatsun
Like • Show 1 Like1 Comment • 6
I have a PS4 and Xbox One, I'm looking to avoid all NAT issues and possibly improve performance. Would it be better to use a DMZ or use IP Pass-through?
corbin
corbin
Feb 7, 2017 11:37 AM
Correct Answer
DMZ
DMZ is a Router NAT function. When you put a device in the DMZ then all packets received by your router, that don't match an existing NAT connection, are forwarded to the DMZ device. So any unsolicited traffic sent to your router is no longer dropped by NAT if it doesn't match a port forwarding rule, but instead is forwarded to the DMZed device. You'll want a firewall installed on this device unless it is a game console (and maybe even then?), as it will now be subjected to all kinds of scans and probes from the internet.
IP Passthrough
IP Passthrough removes the device (by switch port, or MAC address depending on device and configuration) from any routing or NAT functions. All traffic from that device is switched/bridged through the router right to the ISP. The IP Passthrough-ed device will have to pull its own public IP address from the ISP DHCP server. This device is no longer on a private network behind a Router/Firewall/NAT, it now lives directly on the public internet (I suggest you should have a firewall installed on it).
No comments:
Post a Comment