Cisco ACS 5.x - Radius Proxy Server to strip prefix or suffix 'user@domain'

The purpose of this document is to strip the domain from users that authenticate with the format: username@domain in ACS 5.x.

Wireless supplicants sometimes present the user creditials in different formats. One such device is the Motorola handhelds. They present the user ID as 'user@domain' to the radius server who then sends this to the AD server. In some cases if you didnt use a FQDN as your domain name (in the handheld) and you were on ACS 4.x it would still authenticate. ACS 4.x would strip this suffix and present the raw ID to AD.

But ACS 5.x doesnt do this easily. You actually have to create a PROXY ACS inside your ACS server. There is no easy check box to strip the prefix or the suffix in ACS 5.x.

If you use LDAP, different sorry. You have the option to strip both with a simple check box under external / ldap section of ACS 5.x.. Below is a document I received from Cisco TAC showing how to strip the prefix and or suffix in ACS 5.x within a ACS proxy.

RADIUS PROXY SERVER

Configure the ACS server as a network device and choose as the authentication option Radius.

 

Define the ACS server as an External Radius server under Network Resources. The external radius server on this case is the ACS itself.

Create a new access service and point the new policy to use the Radius Proxy service type.

 

Once the access service is enable configure the advance options of the new service selection rule to strip the domain after the @.

 

Go to service selection rule and create a new rule pointing to the Proxy Radius Server created previously and include a compound condition as follows:

 

With the previous configuration when we use the username@domain the user is able to authenticate because check the first rule pointing to the proxy radius server which is set up to strip the domian.

When the ACS first receives the request and strips the domain part from the username, the server will Proxy the request to itself in which case the ACS will act as a AAA client striping the domain and showing the passed authentication as follows:

 

On the previous screenshot you can see that once the ACS strips the domain is going to hit the second access service rule which just accept the radius request that does not contain any UPN format.

GEORGE STEFANICK - CWSP JOURNEY, (CHAPTER 4 –AAA, POST#8)- 2/11/2011

I’m back !!!!! On the study horse that is...

AAA – What is it ?

“Triple A”, as it is sometimes called, is a model for access control. It really is the model and basic frame work for security. There are 3 distinctive features in AAA, which are:

Authentication

Authorization

Accounting

Authentication

Authentication is the process to determine whether someone or something (entity) is, in fact, who they say they are.  This is commonly done with user credentials (logon and password). The credentials are then presented to a “server” for verification. Other means, such as tokens and digital certificates can also be used in place of or combined with user credentials. This is called multi layer authentication. It is used to enhance the authentication process.

Authentication uses UDP port 1812, prior to IANA allocation 1645

Authorization

Once the entity is authenticated. Authorization can then take place. Authorization is the process of granting access or permissions to the entity. You are allowing the entity the privilege to do or have access to something on your network.

Accounting

Accounting is a means of keeping track of the entity, while on the network. This is often used by security to track what the entity did, how long they were on the network, what commands they may have entered, etc.

Accounting uses UDP port 1813, prior to IANA allocation 1646

Radius Server

The radius server is sometimes called the AAA server. This is because most common radius servers support all three functions. The Cisco ACS server is an example of such a device.

Other Radius Servers Include:

Juniper Steel Belted Radius

Microsoft IAS (Server 2003)

Microsoft NAP (Server 2008)

Free Radius

Configuration Notes

Speaking from experience (also noted on page 121) there are 2 common mistakes that happen often when setting up a radius server. One is using the wrong port numbers. Two is using the incorrect shared secret between the radius server and the authenticator.  If you have issues in your initial setup, this is something you should check.

RFC

Radius Authentication and Authorization is defined in:

IETF RFC 2865

http://www.ietf.org/rfc/rfc2865.txt

Radius Accounting is defined in:

IETF RFC 2866

http://www.ietf.org/rfc/rfc2866.txt



GEORGE STEFANICK - CWSP JOURNEY, (CHAPTER 4 – EAP, EAP, EAP AND MORE EAP, POST#7)- 10/17/2010

Chapter 4 is one of my favorite chapters. Why you ask? It’s the very foundation to advance wireless security.  EAP is the process where it all begins and comes together. 

Have you ever talked to a vendor or colleague who is not familiar with EAP. You get that glazed look, as if you were from another planet? EAP is rather easy to understand once you know the structure. So lets cover the basics first. 

WHAT EAP (IS) AND (IS NOT)

EAP stands for “Extensible Authentication Protocol”. EAP is an authentication frame work that has been around for a long long time.. What EAP is NOT is an authentication mechanism. There is often confusion about this very statement. EAP doesn’t authenticate, but rather it provides the messaging system, the structure, for which authentication mechanisms like EAP-PEAP, EAP-TTLS, EAP-FAST, EAP-LEAP may operate.

EAP was developed long ago, It was used primarily in point to point authentication (PPP). Whereby clients were authenticated to a network using an EAP authentication. Today, EAP is commonly used in wireless authentication and this will be the focus of my notes.

EAP is defined in RF3748 (http://tools.ietf.org/html/rfc3748). As I just shared it is the frame work or the message systems whereby different flavors of EAP can be used.

“Abstract

   This document defines the Extensible Authentication Protocol (EAP),
   an authentication framework which supports multiple authentication
   methods.  EAP typically runs directly over data link layers such as
   Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP.  EAP
   provides its own support for duplicate elimination and
   retransmission, but is reliant on lower layer ordering guarantees.
   Fragmentation is not supported within EAP itself; however, individual
   EAP methods may support this.” 

.  Chapter 4 covers a rather broad range of information.

• ·         AAA (Authentication, Authorization, Accounting)
• ·         802.1X Process and structure
• ·         Supplicant Credentials; types and uses
• ·         Authentication Protocols
• ·         EAP

My next few post will be the break down of each section …

GEORGE STEFANICK - CWSP JOURNEY, (CHAPTER 5 – 4- WAY HANDSHAKE POST#5)- 10/03/2010

GEORGE STEFANICK - CWSP JOURNEY, (CHAPTER 5 – 4 WAY HANDSHAKE POST#5)- 10/03/2010

The 4-way handshake is a unique process and thus why I think it is important to cover in detail. But first lets recap.

We’ve learned  the MSK (Master Session Key)  is used for seeding material in the creation of the PMK (Pairwise Master Key) . The PMK (Pairwise Master Key) and GMK (Group Master Key)  are then seeding material for the PTK (Pairwise Transient Key) and GTK (Group Temporal Key).

The MSK and PMK are negotiated between the supplicant and the authentication server (AAA). Once created, these keys are then moved to the authenticator (access point) via a Radius packet.

In contrast, PTK (Pairwise Transient Key) is derived differently. It is derived between the supplicant and the authenticator (access point). The authentication server (AAA), at this stage, has completed it’s task and is out of the mix.

Since the supplicant and the authenticator have mutual information about each other (PMK) key . They both can derive their unique Temporal keys in a process called the “4-way handshake” .

The purpose of the 4-way handshake is to derive a unique PTK key that will be used to encrypt client unicast traffic between this station and the access point.  This key is unique. No two stations on an access point will have identical PTK keys.

So lets get started …

After a successful EAP authentication the 4-way handshake begins. Note, as I mentioned before, this is now between the supplicant and the authenticator. 

The 4-way handshake shares very unique and random information between the supplicant and the access point to derive the PTK key. There is something called PRF (pseudo-random function). It uses a combination of “randomness”, as I like to call it.

It includes the PMK+ Supplicant Mac Address + Authenticator Mac Address + random Nonces) Here is the formula, it can be found on page 199 of the CWSP.

It’s a great visual …

PTK = PRF (PMK + ANonce + SNonce + AA + SPA )

Here are the definitions for reference:

PRF (pseudo-random function) -  A collection of efficiently-computable functions which emulate a random oracle in the following way: no efficient algorithm can distinguish (with significant advantage) between a function chosen randomly from the PRF family and a random oracle (a function whose outputs are fixed completely at random). Pseudorandom functions are vital tools in the construction of cryptographic primitives, especially secure encryption schemes.

Nonce - is an abbreviation of number used once (it is similar in spirit to a nonce word). It is often a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks.

ANonce – A authenticator nonce

SNonce – A supplicant nonce

AA – Authenticators Mac Address (access point)

SPA – Supplicants Mac Address (wireless client)

The 4-way handshake looks like a simple 4-way frame exchange. But inside these frames “random” magic is happening before your very eyes. Below is a breakdown of each exchange:

4-way handshake message 1

In the first message, the authenticator sends the supplicant a nonce. This is referred to as the ANonce. Along with this ANonce, the frame includes the authenticators mac address. At this point the supplicant has all the goods to create the PTK. It has the Anonce, authenticators mac address as well as its own Snonce and mac address, of itself.

4-way handshake message 2

The supplicant creates its nonce. This is referred to as the SNonce. The supplicant can now calculate the PTK because it has all the goods from the first handshake. In the second message, the supplicant sends the SNonce to the authenticator. The supplicant also sends the security parameters (RSN) information. The entire message gets an authentication check using the (KCK/MIC) from the pairwise key hierarchy. The authenticator can then verify that the information, including the security parameters sent at association are valid.

4-way handshake message 3 

In the third message the authenticator derives the GTK key from the GMK key. The authenticator derives an ANonce, RSN information element info and a MIC. This information is then sent to the supplicant in a EAPOL-Key frame. This is kept  secret  from sniffing, because it is encrypted within the PTK.  

4-way handshake message 4 

The fourth message acts as a confirmation. It indicates that the temporal keys are installed.

The PTK is comprised into three keys which is important to know, I like to call them the “internal PTK” keys. These KCK, KEK, and TK component. These keys secure the 4-way handshake (KCK), provide data integrity during the 4-way handshake (KCK) and provide encryption used to encrypt and decrypt the MSDU payload of 802.11 data frames between the station and the access point.  

Key Confirmation Key (KCK) - The first key is the EAPOL-key confirmation key (KCK). The KCK is used by the EAPOL-key exchanges to provided data origin authenticity.

Key Encryption Key (KEK) - The second key is the EAPOL-key encryption key (KEK). The KEK is used by the EAPOL-key exchanges to provide for confidentiality.

Temporal Key (TK) - The third key is the temporal key, which is used by the data-confidentiality protocols (TKIP/CCMP)

GEORGE STEFANICK - CWSP JOURNEY, (CHAPTER 5 – KEYS POST#4)- 9/10/2010

  

GEORGE STEFANICK - CWSP JOURNEY, (CHAPTER 5 – KEYS POST#4)- 9/10/2010

First, this is a lot of information and it is very detailed at that. I encourage further reading and study for a complete step by step explanation. These are my notes for reference. I hope you find them useful. 

If you are new to wireless security especially 802.11i, one could be intimidated by all of these KEYS. I can remember thinking to myself, “Why in gods name is there so many keys and they do what again!?”

I would encourage you to read Chapter 5 of the official CWSP study guide, Devin’s ‘chicken egg’ white  paper and the 802.11 Wireless Networks ‘Definitive Guide 2^nd edition’ for a full explanation.

To simplify, I would like to reference fig 5.18 on page 194 of the CWSP study guide. The pyramid offers a great visual as to the RSN Key Hierarchy process.  Let’s break down each LAYER.

“Master Session Key - MSK”

The MSK is sometimes called the ‘AAA key’. The MSK is on top of the food chain and will provide “seeding  / keying material” for the PMK (Pairwise Master Key). MSKs are created during the 802.1X/EAP process.

802.1X/EAP –  The MSK is derived at the supplicant and the authentication server (AAA) during the EAP authentication process. The supplicant and the authentication server (AAA) will know information about each other during the “mutual” authentication exchange of credentials. I added a GREAT Peap Choreography at the end of this post.

(this is all black magic and is outside of the scope of the exam)

What is important to remember is that both the supplicant and authentication server (AAA) have both derived identical  MSK keys during this mutual authentication process which will later be used as seeding material for PMKs.

PSK -  In the case where PSK is used, whereby putting a static PSK key on a station and access point  there is no MSK keying material because there is no authentication server (AAA) in use to derive a MSK. So your PSK is your PMK.

Additional reading material

<RFC4017 states>
Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP
method. The MSK is at least 64 octets in length. In existing implementations, an AAA server acting as an EAP server 

transports the MSK to the authenticator.
<802.11 2007 states:> 
 3.80 master session key (MSK): Keying material that is derived between the Extensible Authentication Protocol (EAP) peer  and
 exported by the EAP method to the Authentication Server (AS). This key is at least 64 octets in length.

“Master Key Layer”

Next layer down on the food chain is the “Master Key Layer”. This is where your PMK (Pairwise Master Key) and GMK (Group Master Key) will be derived! 

PMK  (Pairwise Master Key)

The purpose of the PMK is to create seeding material for the PTK (pairewise transient key)

The PMK is derived by the station and authentication server (AAA). The PMK shall be computed as the first 256 bits (bits 0–255) of the MSK. Since the station and the authentication server (AAA) both have the same MSK, because of the 802.1X/EAP process, the PMKs derived will be identical.

The PMK that is derived at the authentication server (AAA) is sent to the authenticator. Once this occurs the station and authenticator  both have identical PMKs. The PMK is unique between the station and the authenticator. No other station will have identical PMKs. A new PMK is generated when a station authenticates or re-authenticates . PMKs are also used in ‘fast’ roaming, whereby a client can negate a full 802.1X authentication. More about that in a future blog post. Again, keep in mind that the PMK is used as seeding material to create the PTK. 

PSK -   In the case where you use a PSK (PreShare Key)  on a station and access point the Master Keys are derived by using a passphrase-to-PSK mapping.   So your PSK is your PMK key. 

Additional reading material

< IEEE Std 802.11 - 2007>
3.97 pairwise master key (PMK): The highest order key used within this standard. The PMK may be derived from a key generated by an Extensible Authentication Protocol (EAP) method or may be obtained directly from a preshared key (PSK).

< IEEE Std 802.11 - 2007>
The PTK shall not be used longer than the PMK lifetime as determined by the minimum of the PMK lifetime indicated by the AS, e.g., Session-Timeout + dot1xAuthTxPeriod or from the
dot11RSNAConfigPMKLifetime MIB variable. When RADIUS is used and the Session-Timeout attribute is not in the RADIUS Accept message, and if the key lifetime is not otherwise specified, then the PMK lifetime is infinite.

< IEEE Std 802.11 - 2007>
When not using a PSK, the PMK is derived from the MSK. The PMK shall be computed as the first 256 bits (bits 0–255) of the MSK: PMK L(MSK, 0, 256). When this derivation is used, the MSK must consist of at least 256 bits

< IEEE Std 802.11 - 2007> 5.8.2.2 Operations with PSK

The following AKM operations are carried out when the PMK is a PSK:
— A STA discovers the AP’s security policy through passively monitoring Beacon frames or through active probing (shown in Figure 5-11). A STA associates with an AP and negotiates a security
policy. The PMK is the PSK.

— The 4-Way Handshake using EAPOL-Key frames is used, just as with IEEE 802.1X authentication,
when an AS is present. See Figure 5-13.

— The GTK and GTK sequence number are sent from the Authenticator to the Supplicant just as in the
AS case. See Figure 5-13 and Figure 5-14.

GMK  (Group Master Key)

The GMK is randomly created by the authenticator. The purpose of the GMK is to create “seeding material” for the GTK. The GMK lives on the authenticator ONLY. Each authenticator will have it’s own unique GMK. Some vendors allow you to change the GMK dynamically.  I will share more on this in a future blog post.

“Temporal Key Layer”

In the temporal key layer we will discuss two keys. The PTK (Pairwise Transient Key) and  GTK (Group Temporal Key). Both have very unique tasks …. The temporal keys are derived via the 4-Way Handshake process.

PTK (Pairwise Transient Key)

The propose of the PTK keys is to encrypt unicast traffic between the station and access point. The PTK is a unique encryption key and no other station will have the same identical PTK key.

The PTK is composed of 3 parts"

Key Confirmation Key (KCK), Key Encryption Key (KEK), Temporal Key (TK)

GTK  (Group Temporal Key)

The purpose of the GTK key is to encrypt broadcast and multicast traffic between the client(s) and access point (BSS). ALL THE CLIENTS on the same BSS will share identical GTK keys.  That right, multicast and broadcast traffic are keyed separate from the unicast traffic. Keeping in mind this is WHY when using a transitional network, your lowest encryption type is used for your GTK key.

You may have heard about the recent buzz in the industry around “hole 196”. This was based on the exploitation of the GTK key. 

An important part of the PTK and GTK is the 4-way handshake. My next post will cover this in detail ..

 Great image of the frame exchange process