PKI AAA Authorization (IOS 12.4)

SuperVitya · ‎01-24-2011

Hi!

Now I am testing site-to-site VPN between two IOS 12.4 routers (2821 and 881) with IKE authorization by RSA-SIG.

Both routers successfully received certificates from the same CA.

Trustpoint configurations on both routers were also the same:

!

crypto pki trustpoint demo_CS
enrollment url http://10.10.0.100:80
serial-number
revocation-check crl none

!

After I sent traffic from a test user of 2821 router to 881 router the certificate exchange was successfull and the tunnel established correctly. Ping was successfull.

Then I decided to include RADIUS authentication for certificate credentials received from the peer.

I added the following on both routers:

!

aaa authorization network cert group radius

!

crypto pki trustpoint demo_CS
enrollment url http://10.10.0.100:80
serial-number
revocation-check crl none
authorization list cert
authorization username subjectname commonname

!

radius-server host 172.20.120.154 auth-port 1645 acct-port 1646
radius-server key cisco

!

The ACS interacts with both peers by RADIUS properly. Terminal users of the routers are authenticated on it.

I cleared the old isakmp session (rebooted 881) and turned on debugs on both routers.

Cisco-881#show debugging

General OS:

AAA Authentication debugging is on

AAA Authorization debugging is on

Radius protocol debugging is on

Radius packet protocol debugging is on

PKI:

Crypto PKI Msg debugging is on

Crypto PKI Trans debugging is on

Then I repeated the test. I sent ICMP echo from 2821 to 881. The ping was not successull and I received the following debug messages on 881.

Jan 24 12:16:49.734: CRYPTO_PKI: Trust-Point demo_CS picked up
Jan 24 12:16:49.734: CRYPTO_PKI: unlocked trustpoint demo_CS, refcount is 1
Jan 24 12:16:49.734: CRYPTO_PKI: locked trustpoint demo_CS, refcount is 2
Jan 24 12:16:49.786: CRYPTO_PKI: Added x509 peer certificate - (677) bytes
Jan 24 12:16:49.786: CRYPTO_PKI: validation path has 1 certs

Jan 24 12:16:49.786: CRYPTO_PKI: Found a issuer match
Jan 24 12:16:49.786: CRYPTO_PKI: Using demo_CS to validate certificate
Jan 24 12:16:49.794: CRYPTO_PKI: Starting CRL revocation
Jan 24 12:16:49.806: CRYPTO_PKI: Certificate validated
Jan 24 12:16:49.806: CRYPTO_PKI: Anticipate checking AAA list: 'cert'
Jan 24 12:16:49.806: CRYPTO-PKI: Cert has the following key-usage flags: Digital-Signature, Key-Encipherment
Jan 24 12:16:49.806: %PKI-3-CERTIFICATE_INVALID_UNAUTHORIZED: Certificate chain validation has failed. Unauthorized
Jan 24 12:16:49.806: CRYPTO_PKI: chain cert was anchored to trustpoint demo_CS, and chain validation result was: CRYPTO_PKI_CERT_NOT_AUTHORIZED
Jan 24 12:16:49.806: %CRYPTO-5-IKMP_INVAL_CERT: Certificate received from 10.10.0.1 is bad: certificate invalid
Jan 24 12:16:54.178: CRYPTO_PKI: unlocked trustpoint demo_CS, refcount is 1

There are only crypto PKI debug messages. Neither RADIUS nor AAA messages.

Debug messages on 2821 did not appear at all.

Please, help me find what I missed in the configuration.

Marcin Latosiewicz · ‎01-25-2011

Viktor,

I guess you're studying for your CCIE now? I've been working with IOS VPN for several years and I only saw this during CCIE ;-)

My suggestion - simplify and if it does not kick off try with tacacs instead of radius.

For example I don't believe that strictly speaking you need to set both subject name and CN as username ;-)

Example with tacacs:

http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_cfg_auth_rev_cert_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1081781

Right now I'm too lazy to check this, but I could dig into and find my lab setup.

Marcin

SuperVitya · ‎01-26-2011

Yes, Marcin. Now I am learning CCIE Security program.

Debugging this I found one interesting thing. i also turned on 'crypto isakmp' debugging on 2821 and noticed that certificate received from the peer is considered the following way:

next-payload : 6

type : 9

Dist. name : serialNumber=FCZ123012YN+hostname=Cisco-881

protocol : 17

port : 500

length : 56

I configured authorization on the trustpoint as 'authorization username subjectname commonname'. I expected the router to send Radius Access-Request packet with 'Cisco-881' as username. But the router can not distinguish the CN parameter from the received certificate. So it does not send anything to Radius and reports that authorization fails. When I changed 'authorization username subjectname commonname' to 'authorization username subjectname all' the router sent Radius Access-Request with 'serialNumber=FCZ123012YN+hostname=Cisco-881' as username.

Then I used the same trustpoint for IKE authentication for Cisco VPN Client. In 'crypto isakmp' debugging result a saw the following about the certificate received from the client.

next-payload : 6

type : 9

Dist. name : cn=vpntunnel,ou=vpngroup

protocol : 17

port : 500

length : 50

After that Radius Access-Request message was sent with correct username = 'vpntunnel'.

My conclusion is that IOS router receives certificate credentials from another IOS router incorrectly. Its string does not distinguish attributes. I do not know the reason why it happens. At the same time a similar certificate from a VPN Client is received with attributes distinguished one from another.

Is it a bug?

Marcin Latosiewicz · ‎01-26-2011

Viktor,

Good find!

Wellllllllllllllll it doesn not look like a bug. The certificate should at least contain CN (common name) and typically a OU - exactly like you have on VPN client. . In your case it looks like CN CSR you generated did not contain any of those fileds and you have on the 8xx router configured to include hostname and serial.

Can you re-enroll the router setting subject-name manually under trustpoint to cn=HOST.DOMAIN,ou=vpngroup ?

Marcin