Network Access Control

Network Access Control (NAC) is an umbrella term for managing access to a network:

  • Users logging into the network are authenticated and determined what data they can access and actions they can perform
  • The health of the user’s computer or mobile device is checked

Network Access Enforcement Methods:

  • Network access enforcement methods are the actions that are applied to Access Requestors to regulate access to the enterprise network.
  • Many vendors support multiple enforcement methods simultaneously, allowing the customer to tailor the configuration by using one or a combination of methods.
  • Common methods include:
    • Layer 2: IEEE 802.1X (switches and WLAN access points)
    • Layer 2: Virtual Local Area Networks (VLAN)
    • Layer 3: VPN (IKEv2)
    • Layer 4: VPN proprietary over TLS
    • Firewall
    • DHCP Management

Port-Based Network Access Control (IEEE 802.1X)

Access Control Using EAP Methods

  1. The User provides their Credentials:

    Supplicants and Authenticators are both Port Access Entities (PAEs)

  2. MSK is established between Supplicant and Authenticator after successful authentication.

Participants

  • Authentication Server
    • The authentication server is the device that handles authentication, authorization, and accounting (AAA) services on a network.
    • User accounts are created and stored.
    • Privileges and Policies are applied.
  • Authenticator
    • The network device that is attempted to be accessed
      • e.g. wireless router/access point or a network switch
    • The switch or WLC has no idea of what EAP type is in use, or if the user’s credentials are valid.
    • It simply takes the unmodified EAP frame and encapsulates it within the RADIUS packet sent to the authentication server and authorizes the port if the authentication server tells it to.
  • Supplicant
    • The client device, such as a smartphone or laptop computer, that wants to access the network.

Authentication

The authentication can be initiated by either authenticator or supplicant:

  • The authenticator:
    • Initiates authentication if the link state changes from down to up or periodically as long as the port remains up and unauthenticated.
    • The switch sends an EAP-request/identity frame to the endpoint to request its identity.
  • The supplicant triggers the authenticator to request an identity by sending an EAPoL_Start message at any time.

Extensible Authentication Protocol (RFC 3748, RFC 5247)

Provides a protocol to encapsulate different authentication methods:

Modes: Native

  • EAP-MD5
    • Uses the MD5 message-digest algorithm to hide the credentials in a hash.
    • EAP-MD5 does not have a mechanism for mutual authentication.
      • That means the server validates the client, but the client does not authenticate the server.
  • EAP-TLS
    • Uses TLS to provide the secure identity transaction.
    • Open IETF standard
    • Uses X.509 certificates.
      • Digital certificates provide strong authentication.
    • Authentication occurs automatically, with no intervention by user.
      • Nice for IoT devices, because it can authenticate itself without human input.
    • No dependency on user password.

Modes: Tunneled

Whereas the native EAP types send their credentials immediately, tunneled EAP types form an encrypted tunnel first and then transmit the credentials with native EAP within that tunnel.

Selecting the appropriate EAP type is dependent on the:

  • operating system
  • 802.1X supplicant
  • supported back-end credential database or identity store
Modes
  • PEAP: Protected EAP
    • Forms an encrypted TLS tunnel between the client and server, using the X.509 certificate on the server.
    • After the tunnel has been formed, PEAP uses one of the following EAP types as an inner method for authenticating the client using EAP within the outer tunnel.
      • MSCHAPv2 is the most common inner method, as it allows for simple transmission of username and password, or even computer name and computer password, to the RADIUS server.
      • PEAP is capable of using EAP-TLS as an inner method but it is rarely used.
  • EAP-FAST: Flexible Authentication via Secure Tunneling (FAST)
    • Created by Cisco Systems as an alternative to PEAP to allow for faster re-authentications and support faster wireless roaming.
    • FAST forms a TLS outer tunnel and then transmits the client credentials within this TLS tunnel.
    • It has the ability to use Protected Access Credentials (PACs). A PAC can be thought of like a secure “cookie,” stored locally on the host as “proof” of a successful authentication.
      • EAP-MSCHAPv2 is the most common inner method.
      • EAP-FAST is capable of using EAP-TLS as an inner method.
        • This has become quite popular with EAP-Chaining.
EAP Types
  • With tunneled EAP types, there is a concept of inner and outer identities.
  • The inner identity is the user or device’s actual identity credentials sent with the native EAP protocol.
  • The outer identity is typically set to “anonymous”.
    • It’s the identity that is used between the supplicant and the authentication server for the initial TLS tunnel setup.
    • Cisco ISE is able to read that outer identity and use it to help make identity store selection decisions.
    • Most supplicants will hide this option from the end user, and only administrators see the outer identity.
    • One supplicant that does expose it to the end user is the native Android supplicant.
EAP Master Session Key & RADIUS
  1. Key established between supplicant and Authentication Server
  2. Authentication Server sends key to Authenticator
  3. Result:

Secure Device Identity (IEEE 802.1AR)

A Secure Device Identifier (DevID) is cryptographically bound to a device and supports authentication of the device’s identity. An Initial Device Identifier (IDevID) provide by the supplier of a device can be supplemented by Local Device Identifiers (LDevIDs) facilitating enrollment (provisioning of authentication and authorization credentials) by local network administrators.

Secure Device Identifier

  • DevID
    • Secure Device Identifier
  • IDevID
    • Initial Device Identifier
    • Created during manufacturing and cannot be modified
    • Either reaches end of lifetime (certificate) or can be disabled
  • LDevID
    • Locally Significant Device Identifier
    • One or several may be created by network administrator
  • DevID Module
    • Hardware module which stores the DevID secrets, credentials and the entire credential chain up to the root certificate
    • Contains a strong Random Number Generator (RNG)
    • Implements Asymmetric Algorithms (2048 bit RSA and/or 256 bit ECDSA)
    • Implements SHA-256 Hash Function

DevID Module

Source: https://www.ieee802.org/1/files/public/docs2021/60802-Pfaff-et-al-Background-for-802-1AR-Adoption-1121-v01.pdf

Use of DevIDs

  • DevID use in EAP-TLS Authentication
    • Device authentication can be based on its DevID certificate.
  • DevID use in Consumer Devices
    • Similar but more secure than access control based on a MAC address list which can easily be spoofed.
    • A switch, router or access point can allow access based on a registered commonName (CN), serialNumber (SN) or a subjectAltName contained in the DevID certificate.
  • DevID use in Enterprise Devices
    • Similar to the consumer device use case but the DevID is usually registered with a central AAA server (white-listing).
  • DevID Module based on Trusted Platform Module (TPM)
    • Each TPM has a unique non-erasable Endorsement Key (EK) to which DevID secrets and credentials can be bound.

Relevant Note(s): Trusted Network Connect