Jun
15

A big shout out to all the students in the Raleigh Security CCIE bootcamp last week.   I had a blast!   Thank you for all your hard work, as well as the after hours discussions about the unknown, and why people feel they know it.  :)

I promised a few blog posts related to security over the next few weeks, and this one is regarding Certificate-based ACLs.

This blog may also serve as a review on how to configure the CA clients so that their certificates contain various fields and values, such as subject-name.

Let’s use this diagram for the backdrop of our discussion:

3 routers in a row-NO-user

R2 will be the NTP and CA server with R1 and R3 as IPSec VPN peers.  (Remember, with certificates we really do need time to be on “our side”).  :)

R1′s configuration for the trustpoint is as follows:

crypto pki trustpoint R2
enrollment url http://2.2.2.2:80
serial-number
ip-address 10.0.0.1
subject-name cn=R1,ou=ccsp,o=ine,st=NV,c=US
revocation-check none

R3′s configuration for the trustpoint is here:

crypto pki trustpoint R2
enrollment url http://2.2.2.2:80
serial-number
ip-address 23.0.0.3
subject-name cn=R3,ou=ccie,o=ine,st=NV,c=US
revocation-check none

The problem, is that any device that has a valid certificate from R2, would be able to authenticate with R1 and R3 (from a CA perspective regarding certificates).   If R3 wanted to limit the peers it would authenticate with, we can use a certificate map, which acts as Certificate based Access Control.  A certificate map looks for specific fields from the peers certificate, and values for those fields (specified by the certificate map).   The router will only accept a certificate from a peer if the certificate map specified fields/values from the would-be peer’s certificate match, and if they don’t match, then the IKE phase 1 won’t complete.     We could match several fields from the peers certificate.  The field-name is one of the following case-insensitive name strings or a date:

subject-name

issuer-name

unstructured-subject-name

alt-subject-name

name

valid-start

expires-on

The match-criteria is one of the following :

eq—equal (valid for name and date fields)

ne—not equal (valid for name and date fields)

co—contains (valid only for name fields)

nc—does not contain (valid only for name fields)

lt—less than (valid only for date fields)

ge—greater than or equal (valid only for date fields)

To begin, lets look at what is in R1′s certificate.

R1#show crypto pki certificates
Certificate
 Status: Available
 Certificate Serial Number: 0x2
 Certificate Usage: General Purpose
 Issuer:
 cn=R2
 ou=CA-OF-THE-WORLD
 o=INE
 st=NV
 c=US
 Subject:
 Name: R1.ine.com
 IP Address: 10.0.0.1
 Serial Number: XXXXXXXXXXX
 serialNumber=XXXXXXXXXXX+ipaddress=10.0.0.1+hostname=R1.ine.com
 cn=R1
 ou=ccsp
 o=ine
 st=NV
 c=US
 Validity Date:
 start date: 14:05:12 PDT Jun 15 2010
 end   date: 14:05:12 PDT Jun 15 2011
 Associated Trustpoints: R2

We have several choices, but let’s select the cn field in our example.    On R3, we will create a certificate map, that is looking for the subject-name to contain the value of “R1″.  The certificate map is inserted into the PKI trustpoint configuration.

R3:
crypto pki certificate map CERT-MAP 1
 subject-name co R1 exit 
crypto pki trustpoint R2
 match certificate CERT-MAP
 exit

With this in place, the IKE phase 1 works, and encrypted traffic flows between the peers.

If we change the Certificate Map to look for for the string R9 (which won’t match inside of R1′s certificate) and then test the VPN connection, we can see the debug messages and the certificate error:

R3(config)#crypto pki certificate map CERT-MAP 1
R3(ca-certificate-map)#no subject-name co r1
R3(ca-certificate-map)# subject-name co r9
R3#debug crypto isakmp
Crypto ISAKMP debugging is on

R3#clear crypto sa
R3#clear crypto isakmp

R3#ping 1.1.1.1 so lo 0 re 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3

IPSEC(sa_request): ,
 (key eng. msg.) OUTBOUND local= 23.0.0.3, remote= 10.0.0.1,
 local_proxy= 3.3.3.3/255.255.255.255/0/0 (type=1),
 remote_proxy= 1.1.1.1/255.255.255.255/0/0 (type=1),
 protocol= ESP, transform= esp-aes esp-sha-hmac  (Tunnel),
 lifedur= 3600s and 4608000kb,
 spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0
ISAKMP:(0): SA request profile is (NULL)
ISAKMP: Created a peer struct for 10.0.0.1, peer port 500
ISAKMP: New peer created peer = 0x66031B38 peer_handle = 0x80000009
ISAKMP: Locking peer struct 0x66031B38, refcount 1 for isakmp_initiator
ISAKMP: local port 500, remote port 500
ISAKMP: set new node 0 to QM_IDLE
ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 66033338
ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
ISAKMP:(0):No pre-shared key with 10.0.0.1!
ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
ISAKMP:(0): constructed NAT-T vendor-07 ID
ISAKMP:(0): constructed NAT-T vendor-03 ID
ISAKMP:(0): constructed NAT-T vendor-02 ID
ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
ISAKMP:(0):Old State = IKE_READY  New State = IKE_I_MM1

ISAKMP:(0): beginning Main Mode exchange
ISAKMP:(0): sending packet to 10.0.0.1 my_port 500 peer_port 500 (I) MM_NO_STATE
ISAKMP:(0):Sending an IKE IPv4 Packet.
ISAKMP (0:0): received packet from 10.0.0.1 dport 500 sport 500 Global (I) MM_NO_STATE
ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(0):Old State = IKE_I_MM1  New State = IKE_I_MM2

ISAKMP:(0): processing SA payload. message ID = 0
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismat.
Success rate is 0 percent (0/1)
R3#ch
ISAKMP (0:0): vendor ID is NAT-T RFC 3947
ISAKMP : Scanning profiles for xauth ...
ISAKMP:(0):Checking ISAKMP transform 1 against priority 65535 policy
ISAKMP:      encryption DES-CBC
ISAKMP:      hash SHA
ISAKMP:      default group 1
ISAKMP:      auth RSA sig
ISAKMP:      life type in seconds
ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
ISAKMP:(0):atts are acceptable. Next payload is 0
ISAKMP:(0):Acceptable atts:actual life: 0
ISAKMP:(0):Acceptable atts:life: 0
%CRYPTO-4-IKE_DEFAULT_POLICY_ACCEPTED: IKE default policy was matched and is being used.
ISAKMP:(0):Fill atts in sa vpi_length:4
ISAKMP:(0):Fill atts in sa life_in_seconds:86400
ISAKMP:(0):Returning Actual lifetime: 86400
ISAKMP:(0)::Started lifetime timer: 86400.

ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch
ISAKMP (0:0): vendor ID is NAT-T RFC 3947
ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
ISAKMP:(0):Old State = IKE
R3#_I_MM2  New State = IKE_I_MM2

ISAKMP (0:0): constructing CERT_REQ for issuer cn=R2,ou=CA-OF-THE-WORLD,o=INE,st=NV,c=US
ISAKMP:(0): sending packet to 10.0.0.1 my_port 500 peer_port 500 (I) MM_SA_SETUP
ISAKMP:(0):Sending an IKE IPv4 Packet.
ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
ISAKMP:(0):Old State = IKE_I_MM2  New State = IKE_I_MM3

ISAKMP (0:0): received packet from 10.0.0.1 dport 500 sport 500 Global (I) MM_SA_SETUP
ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(0):Old State = IKE_I_MM3  New State = IKE_I_MM4

ISAKMP:(0): processing KE payload. message ID = 0
ISAKMP:(0): processing NONCE payload. message ID = 0
ISAKMP:(1008): processing CERT_REQ payload. message ID = 0
ISAKMP:(1008): peer wants a CT_X509_SIGNATURE cert
ISAKMP:(1008): peer wants cert issued by cn=R2,ou=CA-OF-THE-WORLD,o=INE,st=NV,c=US
 Choosing trustpoint R2 as issuer
ISAKMP:(1008): processing vendor id payload
ISAKMP:(1008): vendor ID is Unity
ISAKMP:(1008): pr
R3#ocessing vendor id payload
ISAKMP:(1008): vendor ID is DPD
ISAKMP:(1008): processing vendor id payload
ISAKMP:(1008): speaking to another IOS box!
ISAKMP:received payload type 20
ISAKMP:received payload type 20
ISAKMP:(1008):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
ISAKMP:(1008):Old State = IKE_I_MM4  New State = IKE_I_MM4

ISAKMP:(1008):Send initial contact
ISAKMP:(1008):SA is doing RSA signature authentication using id type ID_IPV4_ADDR
ISAKMP (0:1008): ID payload
 next-payload : 6
 type         : 1
 address      : 23.0.0.3
 protocol     : 17
 port         : 500
 length       : 12
ISAKMP:(1008):Total payload length: 12
ISAKMP (0:1008): constructing CERT payload for serialNumber=XXXXXXXXXXX+ipaddress=23.0.0.3+hostname=R3.ine.com,cn=R3,ou=ccie,o=ine,st=NV,c=US
ISAKMP:(1008): using the R2 trustpoint's keypair to sign
ISAKMP:(1008): sending packet to 10.0.0.1 my_port 500 peer_port 500 (I) MM_KEY_EXCH
ISAKMP:(1008):Sending an IKE IPv4 Packet.
ISAKMP:(
R3#1008):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
ISAKMP:(1008):Old State = IKE_I_MM4  New State = IKE_I_MM5

ISAKMP (0:1008): received packet from 10.0.0.1 dport 500 sport 500 Global (I) MM_KEY_EXCH
ISAKMP:(1008): processing ID payload. message ID = 0
ISAKMP (0:1008): ID payload
 next-payload : 6
 type         : 1
 address      : 10.0.0.1
 protocol     : 17
 port         : 500
 length       : 12
ISAKMP:(0):: peer matches *none* of the profiles
ISAKMP:(1008): processing CERT payload. message ID = 0
ISAKMP:(1008): processing a CT_X509_SIGNATURE cert
ISAKMP:(1008): peer's pubkey isn't cached
%PKI-3-CERTIFICATE_INVALID_UNAUTHORIZED: Certificate chain validation has failed. Unauthorized %CRYPTO-5-IKMP_INVAL_CERT: Certificate received from 10.0.0.1 is bad: certificate invalid
ISAKMP:(1008):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(1008):Old State = IKE_I_MM5  New State = IKE_I_MM6

%CRYPTO-6-IKMP_MODE_FAILURE: Processing of Main mode failed with peer a
R3#t 10.0.0.1
ISAKMP:(1008): sending packet to 10.0.0.1 my_port 500 peer_port 500 (I) MM_KEY_EXCH
ISAKMP:(1008):Sending an IKE IPv4 Packet.
ISAKMP:(1008):peer does not do paranoid keepalives.

ISAKMP:(1008):deleting SA reason "Phase1 SA policy proposal not accepted" state (I) MM_KEY_EXCH (peer 10.0.0.1)
ISAKMP (0:1008): received packet from 10.0.0.1 dport 500 sport 500 Global (I) MM_KEY_EXCH
ISAKMP:(1008):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
ISAKMP:(1008):Old State = IKE_I_MM6  New State = IKE_I_MM6

ISAKMP:(1008):Input = IKE_MESG_INTERNAL, IKE_PROCESS_ERROR
ISAKMP:(1008):Old State = IKE_I_MM6  New State = IKE_I_MM5

ISAKMP:(1008):deleting SA reason "Phase1 SA policy proposal not accepted" state (I) MM_KEY_EXCH (peer 10.0.0.1)
ISAKMP: Unlocking peer struct 0x66031B38 for isadb_mark_sa_deleted(), count 0
ISAKMP: Deleting peer node by peer_reap for 10.0.0.1: 66031B38
ISAKMP:(1008):deleting node -1424120631 error FALSE reason "IKE deleted"
ISAKMP:(1008):Input
R3# = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
ISAKMP:(1008):Old State = IKE_I_MM5  New State = IKE_DEST_SA

IPSEC(key_engine): got a queue event with 1 KMI message(s)
ISAKMP (0:1008): received packet from 10.0.0.1 dport 500 sport 500 Global (I) MM_NO_STATE
R3#un all
All possible debugging has been turned off
R3#

This is another important technique to put in our ever expanding tool belt.   On an upcoming post, we will take a closer look at the  ID type, including:

ID type ID_KEY_ID
ID type ID_IPV4_ADDR
ID type ID_FQDN
ID type ID_USER_FQDN

Best wishes in your studies.


You can leave a response, or trackback from your own site.

7 Responses to “CCIE Security: Certificate-based ACLs”

 
  1. Bruno Silva says:

    Excelent post, in my opinion you guys should keep posting stuff on CCIE Security, doing more Vlectures on this.

    Keep the good working. Thank you.

  2. Amit says:

    This is a neat tip. I am hoping you will do a post on CRL too. Thanks.

  3. parvez says:

    I am very happy today because I learn NEW Type of ACL.

    Thanks.

  4. Pipatpong Samranpit, CCIE # 17451 (R&S, SP) says:

    Well done !!! It’s most clear and easier to understand after reading your post. Keep posting … Thanks

  5. Wendal says:

    Hey,

    great article. Just been running through the VPN labs (Workbook Vol I) again and this article helps alot to solidify what I’m learning.

    A couple of questions to better understand this:

    1. Are Certificate maps primarily used as ACLs to filter peers from attempting connections ? Is that their purpose. Its what I seem to understand from this post.

    2. In your configuration, you had

    crypto pki certificate map CERT-MAP 1
    subject-name co R1

    In the labs I’ve recently done, in the second line I’d have done

    subject-name co cn=R1

    Does it really matter that I placed “cn=R1″ versus just “co R1″ ? Is there any difference really, afterall its a “contains”

    And one last thing

    3. Whats the difference between subject-name and unstructured-subject-name ?

    Thanks

  6. Pawl0 says:

    Hi,

    Regarding you post Wendal,

    I think the subject name and issuer name fields in certificate are treated by certificate map as strings, and parsed against string provided in certificate map

    So this example should works:

    crypto pki certificate map Group 5
    issuer-name co ATT
    subject-name co IT
    crypto pki certificate map Group 10
    issuer-name co ATT
    subject-name co ou=WAN

    The difference is that IT can be placed as any X.500 AttributeType.

    Your second question:

    - subject-name—Case-insensitive string
    - unstructured-subject-name—Case-insensitive string.

    Regards

    Maciek

 

Leave a Reply

Categories

CCIE Bloggers