Use Case and Reference Architecture

Use Case Overview

Enterprise networks can be accessed through various ways by various client types. This triggers the need for some kind of federation of how you manage and grant access to those devices and define which resources of the network each client can use.

Figure 1: Network Access Use Cases

Architecture: Why Use the RADIUS Protocol?

Today, all central enterprise authentication schemas are based on the usage of the RADIUS protocol and using IEEE 802.1X for strong client authentication using various EAP methods.

There are two other authentication protocols sometimes used in the enterprise:

• TACACS and TACACS+ can be considered as legacy protocols. Today, they’re still sometimes used for administrative CLI access on a device but that can be done with RADIUS as well. Do not use it in new deployments. Juniper Mist Access Assurance does not support this protocol.
• Diameter is an evolved protocol that is more complex but adds a lot more features for protocol routing and robustness of the messaging. The main usage of the protocol is in mobile networks to replace the legacy SS7 protocol. Juniper Mist Access Assurance does not support this protocol.

The RADIUS Protocol is defined in IETF RFC 2865 and RFC 2866. It serves three main purposes:

• Authentication—of users and devices wishing to access the network. The authentication can be just a simple username and password check, or some certificate-based checking of rolled out PKI, checking of a Smartcard or mobile SIM and many more. Hence, the protocol itself is extensible for new authentication methods.
• Authorization—of users and devices after they have been successfully authenticated. As part of the authentication, there will be a decision made if a user or device can access the entire network without any restrictions or if access to the network is restricted in some way. What this restriction means depends on what access you can limit and how. The most common example is to assign a VLAN to a wired or wireless client in an enterprise network because the assigned VLAN limits what resources the user can access.
• Accounting—of users and devices. After the authentication has been performed and the authorization has been applied, the network will periodically provide statistics about the client’s usage of the network, such as time on the network and transferred bytes in and out. This has more relevance in a service provider network for billing purposes and is less commonly used in enterprise networks.

The following items are critical to understanding the RADIUS protocol. We are not reviewing the full details of the protocol and how it is implemented here, however. Consider reviewing the protocol’s original RFC or its Wikipedia Article if you need more information.

• The protocol uses UDP messages for exchange. If messages have been lost in transit, there is an automatic re-transmission happening a handful of times until a request is discarded.
• The RADIUS protocol is extensible by nature. The default Attribute Value Pairs (AVPs) are defined in the RFC but vendors can create new AVPs specific to their devices. Usually, such extensions are made to share more information about a device or enhance the authorization parameters to provide more granular enforcement points.
• The network access device is located at the edge of the network at the point of Traffic ingress:
  • In an enterprise network, this is an access switch or an AP.
  • It can be multiple instances in a remote branch or at the lowest level of a campus fabric.
  • The protocol a device uses when attaching to the network access device is not defined. Most commonly you will see:
    • Appearance of a new MAC address on an ethernet switch port.
    • A wired or wireless client starting an EAP authentication (more later in this chapter).
  • The enforcement of authorization of a user or client usually happens at this level.
  • The network access device has a RADIUS client implemented that encapsulates all messages into RADIUS UDP messages and sends them to the RADIUS server.
• The RADIUS server is typically located at a central location of the network and is reachable by the network access devices using a VPN (or public IP address) responding to the RADIUS client messages passively.
  • For redundancy reasons, there are typically two RADIUS servers deployed. However, the network access device chooses when to failover to another RADIUS server.
  • If a vendor has extended the standard RADIUS attributes, the vendor-specific attributes must be configured as well via a RADIUS dictionary from the vendors so that these RADIUS AVPs can be utilized.
  • The RADIUS server is the decision making point in the network for checking the authentication of a client.
    • Getting client credentials of some kind forwarded via the network access device.
    • Retrieving client credentials also from a credential database.
    • Comparing the two sets of information and deciding if they are valid, hence the client can pass or not.
  • The RADIUS server either has a local, built-in credential database or a credential database that can be accessed remotely using a standard protocol. These protocols are typically one of the following:
    • OAuth2 when authenticating using a public IdP.
    • Lightweight Directory Access Protocol (LDAP) when a local (Active) Directory is used.
    • SQL or HLR/HSS databases are more typically used by (mobile) service providers.
  • Along with the user record, the local or remote credential database also has information about the authorization profile to be used upon successful authentication of a client.
  • When authentication for a user completes successfully, the RADIUS server responds with an Access-Accept message that also can contain:
    • Dynamic cryptography key material to be used between the client device and the network access device further on to establish secure communication.
    • Authorization RADIUS AVPs to be enforced on the network access device to limit the access the client has to the network. Using vendor specific AVPs, the RADIUS server will only send those which are understood on the network access device.

Figure 2 shows where the RADIUS protocol is implemented in the network and how it is used.

Figure 2: Implementation and Use of the RADIUS Protocol

The example workflow in Figure 3 uses MAC address-based authentication at a switch to review how the framework works together.

1. A device wishing to access the wired network sends some messages (ARP/DHCP request).
2. The switch sees a new MAC address on the port and blocks all further communication to the network.
3. The newly detected MAC address is converted into a username and password and sent as a RADIUS Access-Request for approval. Other RADIUS AVPs are embedded as well, such as one describing the location (port information) about the request.
4. Upon receiving the RADIUS access request, the RADIUS server analyzes the content of the RADIUS message and extracts the RADIUS AVPs needed to perform the authentication. In our case, the username attribute is used, and a request is sent to an internal credential database to receive information about the username (which is identical to the MAC address of the client).
5. The credential database returns either an empty password if the user record has been found or, if valid, a password and an authorization profile (usually a string) to be used for this client.
6. The RADIUS server compares the passwords sent from client and the credential database. If they are a match, an Access-Accept message will be created as a response to the switch. As part of the successful authentication, the authorization profile is used to add the RADIUS AVPs stored for a particular network access device (the switch) and add them as well to the Access-Accept message. In our case, we want the client to use a particular VLAN, hence, the attribute “Tunnel-Private-Group-ID” contains the VLAN name on the switch configured as reference.
7. The RADIUS server returns the Access-Accept as well as the authorization information (VLAN to be assigned) back to the client.
8. The switch, acting as the network access device, upon receiving the Access-Accept message, allows the client to communicate further with the network by unblocking the port. Should the switch also receive authorization RADIUS AVPs, they are applied as well. In our case, the default VLAN assigned to the port is replaced by the one we have authorized the client to use.
9. Optional: A RADIUS Accounting-Start message is created and sent to the RADIUS server. Again, this is not required in enterprise networks.
10. Optional: The RADIUS server may store locally or forward this information in a database of some sort.
11. Optional: The RADIUS server will acknowledge the accounting message.
12. The client can now access the network. If authorization has been used, the switch will enforce it and limit access in some way.

Figure 3: A Typical Authentication Process Example

Architecture: 802.1X Authentication: What Is It?

• Standard for port-based network access control.
• Can provide very strong cryptographic authentication.
• Always involves three parties:
  • Supplicant—Device that wishes to access the LAN or WLAN. In this JVD, we have the following supplicants:
    • Windows 11 desktop client wired or wireless
    • Linux desktop client wired or wireless
  • Authenticator—A network access device that provides a data link between the client and the network that can allow or block traffic between the two. In this JVD, we have the following authenticators:
    • Juniper Networks® EX Series Switches
    • Juniper® Series of High-Performance Access Points
  • Authentication Server—Receives and responds to requests for network access. In this JVD, we have the following authentication server:
    • Juniper Mist Access Assurance
• Defines encapsulation methods of EAP:
  • The EAP methods used are exchangeable. They are negotiated between the supplicant (which offers the different encapsulation methods it supports one-by-one) and the authentication server (which acknowledges a method offered by the supplicant that it supports).
  • Most common transport between the supplicant and the authentication server is EAP over LAN (EAPoL). From NAS to authentication server, those messages get tunneled inside RADIUS.
  • The supplicant selects the outer EAP identity to be used called the Network Access Identifier (NAI) as described first in RFC 2486. This allows the receiving authentication server to proxy the request to another authentication server in case it is not responsible for a roaming client.
  • The NAS/authenticator is NOT involved in the authentication process itself. That process is only handled between the supplicant and the authentication server. The NAS/authenticator only forwards messages. This means that if the authenticator supports 802.1X, it will be capable of handling all the EAP protocols known. The question is always whether the supplicant and the authentication server both support a given EAP protocol.
  • Based on the EAP protocol used, the Access-Accept message sent by the authentication server to the authenticator can contain dynamically created cryptographic key material. This can then be used to establish an encrypted link between the supplicant and the authenticator. The most commonly used is enterprise-grade dynamic WPA2 and WPA3 encryption for WLAN access.

Figure 4: EAP Authentication Framework

The example in Figure 5 shows EAP-TTLS with an inner PAP authentication method which involves the following:

• An enterprise Public Key Infrastructure (PKI) is used for this EAP method to generate and pre-deploy the following certificate information:
  • The root CA, any intermediate signing CA, and the TLS server certificate (with public and private keys) on the RADIUS server.
  • The root CA and any intermediate signing CA via some enterprise device management method to the supplicant. This is needed to validate the certificate offered by the server.
• The supplicant then starts sending EAPoL messages that the authenticator forwards inside RADIUS messages to the authentication server to perform the following:
  • Build a secure TLS tunnel between the supplicant and the RADIUS server.
  • Inside the TLS tunnel (not shown in the below figure) username and password credentials are exchanged.
• Like the previous MAC address-based authentication, these credentials are exchanged against a credential database and verified on the authentication server.
• Should the credential check validate optional authorization, RADIUS AVPs may be added to the returned Access-Accept message. In the example, we enforce a certain VLAN to be used.
• The authenticator then oversees opening the access for the supplicant when it receives an Access-Accept message back from the authentication server and enforces all received authorization parameters (granting access to the client to a specific VLAN, in this example).

Figure 5: Example EAP-TTLS Authentication

In an enterprise network, you should use a strong EAP method where it is technically possible. Review the figure below to be able to select the best method.

Where it is technically not possible to use EAP, consider the options shown in the figure below.

Architecture: Using a RadSec Tunnel Between the Authenticator and the RADIUS Server

The Juniper Mist Access Assurance solution uses an additional protocol/tunnel wrapped around the RADIUS UDP messages between the authenticator and the RADIUS server.

• This tunnel is based on the TLS V1.2 and V1.3 protocol, such as that used to protect a web server connection via HTTPS.
• The TCP destination port towards the RADIUS server is 2083.
• The RADIUS server, that is part of the Juniper Mist authentication cloud can be reached via the FQDN radsec.nac.mist.com.
• The Juniper Mist authentication cloud is responsible for creating a certificate and loading it on to the authenticator so that the TLS connection can be built with the authentication cloud. For this reason, Juniper Mist creates its own PKI for every organization.

Figure 6: Figure 14:RadSec Tunnel Usage

The reason for choosing this RadSec design has several technical reasons.

• It’s a more robust transport when the RADIUS server is remote on the Internet.
• Credentials and client information is secured from eavesdropping and man-in-the-middle attacks such as blastradius due to the RadSec TLS tunnel. This also relaxes the need for strong and individual shared-secrets defined between the RADIUS client and server.
• Enterprise firewall administrators are more confident when opening a TLS connection than opening remote UDP ports.
• The usage of a fixed FQDN enables the solution to select the nearest Juniper Mist authentication cloud via a global DNS load balancer. RadSec termination always happens to the nearest available Juniper Mist authentication cloud to optimize the latency.
• Should a third-party device or a Juniper switch not managed by the Juniper Mist cloud be used, then an additional proxy needs to be planned. This proxy acts like a replacement of the legacy on-site RADIUS and translates between RADIUS and RadSec towards the Juniper Mist authentication cloud. The Juniper Mist™ Edge appliance can be used to host this proxy service.
• Future usage of RADIUS Change of Authorization messages is very easy to embed as the Juniper Mist RADIUS server can use the existing TLS tunnel for those messages.

The important take away is that the legacy RADIUS server is no longer local and needs to be reachable via the corporate VPN. It’s now a function of the Juniper Mist authentication cloud offer. Credential databases are also usually not local as customers start to embrace public IdPs such as Azure AD and Okta since nowadays not only client credentials need to be authenticated. The RadSec tunnel and configuration are managed by the Juniper Mist authentication cloud to enable this seamlessly.

Architecture: Juniper Mist Access Assurance Framework

The entire resulting framework for Juniper Mist Access Assurance is highlighted in the figure below. Note that the Access Assurance administrator uses and only sees the same Juniper Mist portal that he uses to manage switches and APs.

Figure 7: Overview Access Assurance Framework

With reference to the first authentication example shown in this chapter with a local RADIUS server and credential database (Figure 3), compare it to Figure 8. Note the differences in Figure 8:

• The Juniper Mist authentication cloud oversees creating and loading the certificate onto the authenticator device for building the RadSec tunnel.
• The RADIUS server and credential database have been moved to the Juniper Mist authentication cloud.
• RadSec as TLS tunnel is now used between the authenticator and Juniper Mist Access Assurance (RADIUS server).
• All the remaining workflow is untouched and does not change the way it operates.

Figure 8: RadSec Implementation for MAB

Figure 9 adds a Juniper Mist Edge device as proxy for the above Figure 8. This is in case you have third-party devices (switches and APs), or Juniper EX Switches not managed by the Juniper Mist cloud. If you have an existing RADIUS server, then you can use the Mist Edge proxy as a drop-in replacement without the need to change anything on the existing switch or AP configuration.

Figure 9: RadSec via Proxy and MAB

Figure 10 shows what happens to EAP authentication methods when implementing RadSec and Juniper Mist Access Assurance:

• The Juniper Mist authentication cloud oversees creating and loading the certificate onto the authenticator device for building the RadSec tunnel.
• The RADIUS server has been moved to the Juniper Mist authentication cloud.
• The credential database has been moved to a public IdP.
• RadSec as TLS tunnel is used now between the authenticator and Juniper Mist Access Assurance (RADIUS server).
• All the remaining workflow is untouched and does not change the way it operates.

Figure 10: RadSec with EAP Authentication and Public IdP

In Figure 11, you can see the inclusion of a Juniper Mist Edge device as proxy for the above figure as previously shown.

Figure 11: RadSec via Proxy for EAP-Authentication with Public IdP

Implementation into Branch and Campus Fabric Designs

NAC solutions always take place where a client ingresses a network. You must be able to block traffic for unauthenticated devices or limit access via authorization enforcement at the lowest entry level of the network. By design, NAC solutions are independent from the transport that happens after network access. The NAC solution is not concerned with whether forwarding is based on VLANs, VXLAN, or routing. The table below lists the possible permutations:

Figure 12 describes the most common deployment options using Access Assurance.

Figure 12: Device Deployments with Access Assurance

Once the network access devices have been configured for RadSec (or RADIUS with Juniper Mist Edge proxy) the integration of the NAC solution according to customer requirements can begin. Here is an example of the typical tasks:

• Currently, the Juniper Mist Access Assurance solution supports the following authentication methods:
  • Password Authentication Protocol (PAP)—Mostly used for MAC address-based authentication.
  • Extensible Authentication Protocol-Transport Layer Security (EAP-TLS)—Mostly used for machine authentication as it needs certificates from an enterprise PKI pre-deployed to the supplicant.
  • Extensible Authentication Protocol-Tunneled Transport Layer Security (EAP-TTLS) with PAP as inner authentication—Mostly used for user authentication when usernames and passwords need to be checked against an IdP.
  • Less common: Protected Extensible Authentication Protocol-Transport Layer Security (PEAP-TLS) (note that PEAP-MS-CHAPv2 is NOT supported as backend methods such as OAuth2 do not support NTLM hashes).
  • Less common: Tunnel Extensible Authentication Protocol (TEAP) with TLS. Consider moving to EAP-TLS.

Methods not on this list need to be discussed with the customer and how the devices using them can be changed. These methods are typically used by legacy devices and properly supporting them needs to be evaluated.

• Discuss which credential databases exist and how they can be integrated into the authentication and authorization process.
  • For MAC address-based authentication, Juniper Mist Access Assurance hosts a list of allowed MACs (you can also choose to identify a vendor by the OUI).
  • Public IdPs most commonly used include the following:
    • Azure AD
    • Okta leveraging OAuth2 between the Juniper Mist authentication cloud and the IdP.
    • Google Workspace leveraging LDAP over SSL (LDAPS) between the Juniper Mist authentication cloud and the IdP.
    • For other IdPs using OAuth2, contact your Juniper representative.
• Discuss the need for authorization profiles and how they can be applied to the network access device (especially when third-party vendor attributes are used).
• Discuss the need for an enterprise PKI:
  • Most customers have an existing PKI that can be used. Obtain the public root CA, any intermediate Cas, and ask the IT personnel to generate a public/private key for a TLS server in PEM format for the Juniper Mist Access Assurance RADIUS server.
  • The Juniper Mist PKI that is generated for each organization and used for the RadSec can be reused for EAP-TTLS when the supplicant is introduced to the Juniper Mist root CA.
  • All methods using a user or machine certificate (EAP-TLS, PEAP-TLS and TEAP-TLS) are expected to get certificates from the customer’s enterprise PKI by the customer’s mobile device management (MDM).
• Discuss the need for IoT devices as they usually do not leverage strong EAP authentication methods due to heavy battery usage for the computation required. The fallback is usually MAC-based authentication or MPSK for WLAN.
• Discuss the need for BYOD integration and portal pages.
• In educational environments, there may be a need for supporting roaming like Eduroam.
• Discuss the need of APs needing to act as a supplicant to be authenticated on a switch port. This is supported on non-EOL Juniper APs with newer firmware.