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 started out as proprietary solutions that were available years prior to the standards being completed.
As someone who is passionate not only about innovation in security but also about the standardization of those innovations, I thought I'd point out a few of the recent efforts 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 was officially published as RFC-7170. This RFC officially makes Cisco's innovative use 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); and it has the ability to chain the credentials of the machine and the user together in asingle 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:
- 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.
- 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.
- 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!
- 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 road maps.
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 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 (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. Its 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.
This article is published as part of the IDG Contributor Network. Want to Join?