Protected Access Credential (PAC) and TrustSec

[iores]

Hi,

I am little confused how PAC works.

With TrustSec, a PAC key is manually configured on the switch instead of the RADIUS key.

By looking at how PAC works, it seems that ISE generates PAC Random Key, PAC-Opaque and A-ID. This all together is called PAC and it is then sent to the switch.

Why now two PAC keys? When is the first key used then? Is it used maybe do encrypt the newly generated PAC sent from ISE to the switch?

Is the second PAC key used as some kind of session key which switch uses to encrypt the PAC-Opaque when sent back to ISE?

What am I missing?

[Flavio Miranda]

@iores 

They both have PAC due the mutual authentication and the server will not share it PAC. This similar to the concept of public and private key used in certificate authentication. 

PAC Overview
 The PAC is a unique shared credential used to mutually
authenticate the client and server. It is associated with a specific
client username and a server authority identifier (A-ID). A PAC
removes the need for Public Key Infrastructure (PKI) and digital
certificates.

https://www.cisco.com/c/dam/en/us/td/docs/switches/lan/catalyst3850/software/release/16-2/workflows/Cisco_trustsec_feature_guide.pdf

[iores]

@Flavio Miranda Why does the server create PAC Random key for each client?

[Flavio Miranda]

  It would be similar to a private x public key concept in PKI infrasctructure. 

1. Server A-ID maintains a local key (master key) that is only known by
the server.
2. When a client, which is referred to in this context as an initiator
identity (I-ID), requests a PAC from the server, the server generates a
randomly unique PAC key and PAC-Opaque field for this client.
3. The PAC-Opaque field contains the randomly generated PAC key along
with other information such as an I-ID and key lifetime.
4. PAC Key, I-ID, and Lifetime in the PAC-Opaque field are encrypted with
the master key.

[iores]

@Flavio Miranda And this (PAC random key, PAC-Opaque, A-ID) is sent to I-ID? Server then forgets everything about this PAC. When the client or I-ID sends the PAC-Opaque again to server, the server uses the master key to decrypt and validate the content of the PAC-Opaque field?

[Flavio Miranda]

Correct. 

[iores]

@Flavio Miranda So is the PAC shared key (instead of RADIUS shared key), which is configured on the switch, used to encrypt this initial communication between A-ID and I-ID when the PAC-Random, PAC-Opaque, and A-ID info is being exchanged between them? The PAC-Random is used in later stages as some kind of session key?

[Flavio Miranda]

Not exactly. PAC process is a mutual authentication prior to EAP-FAST be stablished. Once PAC accomplish its goal it will not be used anymore. 

  I would interpreter the PAC-Random and  PAC-Opaque more like a public key. Based, for example, on this description

"The PAC-Opaque field format and contents are specific to the PAC server on which it is issued. The RADIUS server obtains the PAC Key from the PAC-Opaque field and derives the shared secret the same way clients do. Secure RADIUS only modifies the way shared secret is derived and not its usage."

You probably already heard the famous store about Alice and Bob in cryptography, dont you? 

Alice wants to send a message to Bob but she suspicious  that the  postman is reading her messages. So, she decided to put the pessages inside a box with locker. However, Bob does not have the key to open the locker and read the message! How does Alice overcome this problem? 

 Alice send a copy of the key to Bob. The postman will see the key but it will not mean anything to him. The key is delivered. 

Now Alice and Bob have a key that opens the locker.

Later, Alice send a message to Bob inside a box and lock the box with the locker. Ship the box to Bob.

The postman see the box but it is locked. Then, he hand the box to Bob and can´t see the message. 

Bob receive the box and he has the key to open the locker because Alice send to him the key previously. 

Now they can exchange messages securely 

[iores]

@Flavio Miranda So why do we need to configure PAC key on switch? What it is used for? How exactly mutual authentication happens between the switch and the server? What part of PAC switch presents to server, and which server to the switch?

[Flavio Miranda]

@iores  I am not sure I will be able to explain to you.

"The RADIUS server obtains the PAC Key from the PAC-Opaque field and derives the shared secret the same way clients do"

The client, the switch on this case, need to follow the same process because is a mutual process. 

[iores]

@Flavio Miranda So you are saying that the PAC Random key, and PAC-Opaque is generated by the client which is then sent to server which then remembers this for every and each of the clients? I did not find any source mentioning this.

[Arne Bier]

I tend to zone out when I read discussions about how PAC works and why we even have it.  I have yet to find a sensible discussion about this topic, and also a pragmatic approach to using PAC, or even what the risks are by NOT using PAC. Here are some key points that I think don't get discussed:

1. Admins don't choose to use PAC for their RADIUS key obfuscation - it's most likely there because Network Devices have been provisioned by DNAC.  DNAC will push this config to your Catalysts, whether you like it or not. I personally don't like it - see point 2
2. PAC mechanism requires EAP-FAST.  PAC implements TLS 1.0 during the EAP-FAST tunnel establishment.  That alone sets us back 10 years in security terms because we want to get rid of TLS 1.0 - it means I cannot disable TLS 1.0 in my ISE deployment.
3. When the PAC/CTS mechanism fails (and it happens randomly with IOS versions) then you are flooded with errors and have to sort out that mess. DNAC offers no help in this effort.

My advice.  If you don't provision devices with DNAC, then don't use PAC unless you want to manage all this stuff on top of everything else.  Rather use AES to create Type 6 RADIUS keys(and keep your AES passphrase safe in your Password Manager). Type 6 is the best you can do for TACACS/RADIUS - you can't use Type 8/9 because these aren't reversible in software (required for RADIUS/TACACS).

password encryption aes

If security is of utmost concern, then use DTLS to secure your RADIUS traffic.

If you're using DNAC and have devices provisioned with PAC, and you want to run a network without TLS 1.0 - then you need ISE 3.4 which supports PAC-less provisioning, as well as IOS-XE 17.15+ - sadly, DNAC has not yet come to the party. But it's a good sign that even Cisco recognises this pain. How does one migrate all the network devices away from TLS 1.0/PAC mess?  That remains to be seen - hopefully future versions of DNAC will make this a little easier to manage.

[iores]

@Arne Bier I was looking at the configuration guide for TrustSec, not necessarily under the DNA C. I cannot understand exactly what is the purpose of manually entered shared key (PAC) on the switch, and what is the purpose of the provisioned one which is received from the server/ISE. In addition, I don't understand how exactly are client and server mutually authenticated via PAC.

[Arne Bier]

you should not have to enter and PAC stuff on a switch.  If you have ISE, you can add a PAC username and password into the Network Device TrustSec section, click save. And then on the IOS device that is CTS enabled to ISE, you issue a command to refresh the PAC. That sorts it out. Using TLS 1.0 and EAP-FAST etc. 

[iores]

@Arne Bier 

Here (Configuring Credentials and AAA for a Cisco TrustSec Seed Device) it says that PAC shared key shoud be configured on the switch.