Standards for Secure-Network-Access

I’m amused at how often I hear negative comments about proprietary enhancements from Cisco.  I am one of many (many, many, many) employees of Cisco who is actively involved in standards body organizations, including the IETF.  Many of today’s networking standards have started out as proprietary solutions that are available years prior to the standard being complete.

As someone who is not only passionate about innovation in security but also in the standardization of those innovations, I thought I’d point a few of the recent ones out that I’ve either been involved in, or am just very interested in.

Tunneled EAP (TEAP):

In May of this year, the Tunneled EAP (TEAP) specification has officially been published as RFC-7170.  This RFC officially makes Cisco’s innovative of EAP-Chaining in EAP-FASTv2 a standard that may be implemented in any 802.1X supplicant or authentication server.  Note that, as with all EAP communication in a Dot1X environment, the EAP-Type is completely transparent to the authenticator (switch | wireless | etc.).  This means that it does not require Cisco switches or wireless controllers to use TEAP, just a supplicant and authentication that both support the protocol.

TEAP has some unique advantages over other authentication protocols.  It has the capability to do TLS version negotiation, it may use any inner-method supported by both the supplicant and authentication server (EAP-MSChapV2, EAP-GTC, EAP-TLS) along with the ability to chain the credentials of the machine and the user together in the single EAP-Transaction.

This meets a tremendous industry demand, with a standard way to authenticate and authorize that it is an authorized asset AND an authorized user, with a mixture of identity sources:  Certificates / Username & PWD / One-Time-Passwords / other 2-factor authentication mechanisms.


  • Device authentication with a Certificate (EAP-TLS), showing that the computer belongs to the company PLUS a username/password authentication to Active Directory (EAP-MSChapV2).
  • Device authentication using the Active Directory account & password (EAP-MSChapV2), which validates the machine is a domain member and is active PLUS a username/password authentication to Active Directory (EAP-MSChapV2).
  • Device authentication using a Certificate (EAP-TLS), showing the computer (laptop, desktop, tablet, phone, etc.) belongs to the company PLUS a username/password authentication to Active Directory (EAP-MSChapV2).

By using BOTH the machine and user authentications in a single Authorization, you are able to validate that it is an Authorized User AND an Authorized Machine.  Not just one or the other.

Other Advantages of TEAP:

  1. TEAP uses TLS Session Resumption without maintaining server state (similar to EAP-FAST) –  this allows servers to scale to handle much larger numbers of clients.
  2. Provisioning of Certificates within the tunnel.  This would allow certificate renewals within the TEAP channel, it could be an alternate way to provision initial certificates using BYOD if you first authenticate with an inner method (like username/password).  TEAP is essentially running Enrollment over Secure Transport (EST) inside of the TEAP channel.
  3. TEAP has EAP Channel Bindings to bind the context in which TEAP is used (wired, wireless, IKEv2, L3, etc.) into the TEAP exchange. << HOW Valuable is this???  Awesome!
  4. TEAP has an extensible Type Length Value (TLV) format that can be used to carry data for other purposes within the TEAP tunnel.  Such as PT-EAP (Posture Transport) for providing posture check data transport through the TEAP channel.  << Theoretically a real method for transporting this posture data within the EAP protocol (finally).

As with all standards, this one was written and contributed to by many individuals from many different companies, including but not limited to: Cisco, Juniper, Infineon and others.  I’d like to call out the efforts of my friends and colleagues, people I look up to and admire: Nancy Cam-Winget, Joe Salowey, Hao Zhou and Steve Hanna.

The next steps are for the customers who want TEAP and EAP-Chaining to call their sales reps from Cisco, Microsoft, Apple, Google, Juniper (soon to be Pulse), etc. (pick your flavor of endpoint and authentication server).  Tell your sales team(s) how much this functionality is needed and get it committed to their roadmaps.

Security Group Tagging (SGT) & Security group eXchange Protocol (SXP)

I’ve talked about this innovative technology on my blog in the past, see:  Security Group Tagging Basics.

Earlier this year, Cisco submitted an informational draft on SGT eXchange Protocol (SXP), opening the use of SGT’s to non-Cisco network and security application vendors.  Since then, they updated the submission with a new informational draft comprising the SGT eXchange Protocol (SXP) and the SGT Ethernet Frame Format. 

This used to be 100% Cisco proprietary, and required all Cisco networking infrastructure, security appliances and policy servers.  These submissions allow other vendors to implement inline tagging and exchange tags with Cisco products, either on the wire or through the peering protocol.

Many, many, many thanks to Kevin Regan, Mitsunori Sagae, Darrin Miller, Joe Salowey, Michael Smith, Sue Thomson & Rakesh Kandula for getting this incredible innovation published as an informational draft.



Quite some time ago Cisco’s SVP, Chris Young, announced a new innovation to share contextual security data between security applications, called pxGrid.

In July of this year, pxGrid was published as an internet draft, and presented at the IETF (and VERY well-received) at IETF 90 in Toronto.

pxGrid is a Cisco innovation and the world’s first scalable mechanism for multi-directional sharing of security-related data between security applications, who’s uses are extensible beyond security and into other management realms.

As with any proposed standard, there are more cooks in the kitchen than just Cisco.  The proposed standard is being jointly shaped by Cisco, Juniper (soon to be Pulse), McAfee, Boeing, NIST, and others. The proposal is moving forward and it’s looking quite possible that pxGrid will be a major contributor for the IETF standard around Security Automation and Continuous Monitoring (SACM).

Special thanks on this standards work belong to: Nancy Cam-Winget, Scott Pope, Lisa Lorensin, Cliff Kahn, Steve Venema, Steve Hanna, David Waltemire, and many many many others!!  It’s been an honor and a privilege to work along side such a talented group.

MAB with Non-Cisco Devices

I’m sure Cisco would love to be the only network device that its customer have, and to be honest, there are many companies where that is true. However, it is just not the reality of 100% of companies that deploy Cisco ISE or ACS.

One item in particular that I am asked about frequently is MAC Authentication Bypass (MAB).  This is the process of a non-authenticating device (a device without an 802.1X supplicant running on it) connecting to a network with 802.1X enabled.  Since there is no supplicant to answer the EAP identity requests from the authenticator (switch, wireless controller, etc) the authenticator will generate the authentication request FOR the endpoint using the endpoint’s MAC address as the username/password for the Access-Request message.

Background on MAB

Take a look at Figure-1.  This graphic is displaying a printer w/ a mac address of which is connected to a switch that has 802.1X enabled on its ports and sends the authentication requests to a RADIUS server.

MAB Example
Figure-1:  MAB Example

In Figure-1, the printer did not have a supplicant, and therefore is unable to participate in the 802.1X identity exchange.  Therefore the switch sends a RADIUS Access-Request to the RADIUS server, which determines if the device is allowed on the network.  Assuming it is allowed on the network, the server sends a RADIUS Access-Accept message to the switch, allowing the printer to participate on the network.

It is important to note that while 802.1X is a standard, MAB is not. MAB is something that each vendor could implement differently if they so choose, just as long as the RADIUS communication complies with the standard for RADIUS.

How does a switch (authenticator) know when the endpoint that is plugged into it does not have a supplicant? Following the 802.1X standard, the method is simply a timeout. The authenticator is meant to send EAP over LAN identity request frames every 30 seconds by default. After 3 timeouts (a period of 90 seconds by default) it is assumed that the endpoint must not have a supplicant. As with most Cisco switch features, timers are adjustable. Figure-2 shows the timeouts occurring three times before MAB begins.

802.1X Timeouts
Figure-2:  802.1X Timeouts

Keep in mind that MAB is inherently not a secure technology. When implementing MAB you are bypassing the stronger security of 802.1X by allowing specific MAC addresses to gain access without authentication. When using MAB, always follow a defense-in-depth approach. This means a device that has been authorized to use the network from a MAB request should be granted access to the networks and services that device is required to speak to only.

In other words: don’t provide full access to devices that have been MAB’d, instead provided them with an authorization that is more limited. Since MAB is a standard RADIUS authentication and the authorization decision is being sent from the authentication server (ISE), there really are no limitations to the type of authorization results that can be sent to the authenticator.

Examples are:

  • Downloadable ACLs (dACLs)
  • Dynamic VLAN assignment (dVLAN)
  • URL-redirection
  • Security Group Tag (SGT)
  • Smart port macros
  • Many more

Keep in mind that if an endpoint does not have a supplicant, it is never recommended to change its VLAN. When changing a VLAN assigned to an endpoint, that endpoint must know (somehow) to renew its IP Address. The best solution is to not use VLAN changes on open networks, because there is nothing on the client to detect the VLAN change & trigger the DHCP renewal. When the network uses 802.1X, there is a supplicant on the endpoint to do the VLAN change detection (is gateway reachable, etc.) & trigger the DHCP renewal.

If you still choose to change the VLAN on open networks, then you have only a few choices (none are considered a best-practice). You can set the DHCP lease time to something VERY low, so it will renew the address frequently. There is also an option to use an ActiveX or Java Applet on the portal that will do the VLAN change detection in lieu of a supplicant.

Cisco and non-Cisco MAB

As mentioned previously: there is no standard for MAB. Different vendors will implement MAB in different ways, using different RADIUS values.  There is a key RADIUS attribute that is used to determine what type of authentication request is being sent:  Service-Type.  Some common values for Service-Type with Cisco network access devices are listed here:

  • Service-Type=Framed (signals an 802.1X authentication)
  • Service-Type=Login (signals WebAuth)
  • Service-Type=Call-Check (signals MAB)

Since MAB is not a standard, some vendors will send a RADIUS service-type of “Login” with MAB, some will send a RADIUS service-type of “framed”.  So, why would Cisco use service-type of “Call-Check” if no other vendor does? Why does Cisco perform MAB differently than everyone else? Quick answer: security.

Many years ago, before Cisco released Cisco ISE or the Cisco ACS 5.x server, there was a possible security vulnerability with MAB. That security vulnerability is still possible with other solutions and other network devices. The issue was/is the lack of differentiation between a MAC Authentication Bypass request and a Local Web Authentication request. Both requests will come from the network device with the same service-type and the same format. There was no database separation of user-id’s from endpoint-id’s (mac-addresses). As displayed in Figure-3, a malicious user could enter a mac-address into the username and password fields of a web authentication or maybe even into the endpoint supplicant, and gain access to the network.

Security Issue without Call-Check
Figure-3:  Security Issue without Call-Check

In an effort to close this security hole, and make MAB a bit more secure, Cisco changed the way it does MAB. The Key Differences are listed here:

  • For authentication requests to be processed as MAB (by default), service-type must be Call-Check
  • RADIUS Servers (ACS & ISE) maintain a separate Endpoint Database
  • The calling-station-id is the value that will be compared to the Endpoint Database, ignoring the username and password fields of the MAB request

Figure-4 illustrates the concept of a Cisco compliant MAB.  A packet capture is listed on the left side to highlight the fields of importance.

Cisco MAB
Figure-4: Cisco MAB

All supported Cisco Network Access Devices will use a service-type of “call-check” for MAB requests. They will also ensure the calling-station-id is populated with the mac-address of endpoint. Lastly, Cisco ISE uses a simple check-box within the allowed-protocols configuration as another method to permit or deny the access into the endpoint database for the MAB request, as seen in Figure-5.

Allowing Non-Cisco MAB
Figure-5: Allowing Non-Cisco MAB

Configuring Cisco ISE for 3rd Party MAB

While Cisco ISE allows for the acceptance of non-Cisco MAB, it is not typically something you should or would want to do for all incoming requests, only where absolutely necessary.  I recommend that you separate this out by using a different policy set for non-Cisco switches. I normally do this by creating a Network Device Group (NDG) for all NADs that are non-Cisco, as seen in Figure-6.

NDG's for Non-Cisco
Figure-6: NDG’s for Non-Cisco













Once you have your NDG’s setup and the non-Cisco NADs added to those NDG’s; you can then build the new policy set.  Figure-7 shows the policy set, and the rule that matches the policy set, which is translated as: “if NDG starts-with ThirdParty then use the ThirdParty policy set”.

3rd Party Policy Set
Figure-7: ThirdParty Policy Set

Each network device may have different capabilities with sending usernames/passwords and even filling in the calling-station-id field with the MAC address of the endpoint.  In my personal tests I have found the following:

  • Juniper EX Switch:  Leave both Calling-Station-ID and Password options checked.
  • HP (H3C) Switch:  Uncheck Calling-Station-ID.  Leave Password option checked.
  • RuggedCom Switch:  Uncheck Calling-Station-ID.  Leave Password option checked.
  • Avaya (Nortel) Switch:  Uncheck BOTH Calling-Station-ID and Password options.
  • Alcatel Switch:  Uncheck BOTH Calling-Station-ID and Password options.

Next, you will need to have an “Allowed Protocols” set that is configured for the 3rd party product you are using.  You may need to create one for each vendor, which would be the most explicit and secure way to configure the options. Figure-8 shows an example 3rd Party Allowed Protocol set that would work for Juniper EX switches (in my testing).

Least Secure Allowed Protocols set
Figure-8: Example Allowed Protocols set

Once you have created all the “Allowed Protocol” sets that you need, you will then create the authentication rule(s) for each one.  Figure-9 illustrates an authentication rule that would work for both Nortel and Alcatel switches, based on my testing.

Nortel & Alcatel AuthC Rules
Figure-9: Nortel & Alcatel AuthC Rules


Figure-10 illustrates an authentication rule that would work for Juniper EX Switches, based on my testing results.  It also includes the new default rule at the bottom of the ThirdParty policy set that deny’s all non-matching traffic.

 Juniper EX Switch AuthC Rules
Figure-10: Juniper EX Switch AuthC Rules

Well that about covers MAB with 3rd Party devices.  I hope you found this blog post useful!  As always, I look forward to reading & responding to any comments you may have.