CCNP Security SISAS 300-208 Official Cert Guide (2015)

1. Which of the following is required for ISE to trust a client certificate?

a. The client’s private key must be imported into ISE’s Certificate Store.

b. The signing CA’s public key must be imported to ISE’s Certificate Store.

c. The signing CA’s private key must be imported into ISE’s Certificate Store.

d. The signing CA must be part of the Internet’s master PKI hierarchy.

2. What determines a digital certificate’s validity period?

a. Any time leading up to the date listed in the Certificate Expiration field of the X.509 certificate.

b. A certificate is always valid until it is added to the Certificate Revocation List (CRL).

c. Any time leading up to the date listed in the Revocation Date field of the X.509 certificate.

d. The time span between the dates listed in the Valid-From and Valid-To fields of the X.509 certificate.

3. True or False? Certificate Revocation List (CRL) is the only revocation status mechanism supported by ISE.

a. True

b. False

4. True or False? ISE will ignore the CRL distribution point listed in the X.509 client certificate.

a. True

b. False

5. How does ISE validate proof of possession for a client’s certificate?

a. ISE encrypts data with a combination of ISE’s private key and the client’s public key.

b. ISE encrypts data with a combination of ISE’s public key and the client’s private key.

c. ISE sends a message to the end user, requesting a screen shot of the private key.

d. ISE encrypts data with a combination of ISE’s private key and the client’s private key.

6. Which of the following accurately describes how an Active Directory user is authorized when using certificate-based authentication?

a. When Active Directory is the certificate authority (CA), ISE sends the full certificate to the CA and it cross-references it to the end user to which the certificate was issued, returning the AD Group Membership and other attributes to ISE.

b. It is not possible to perform Active Directory user authorization when performing certificate-based authentication.

c. Cisco ISE uses CAP to identify the principle identity from the X.509 attributes and then performs the lookup in Active Directory using that identity. Active Directory returns the AD Group Membership and other attributes to ISE.

d. This process requires a dual authentication. The first authentication is for the digital certificate, and then the user is prompted for his username and password for the Active Directory component.

7. Which is the most common authentication protocol for network access when using certificates?

a. EAP-TTLS

b. EAP-TLS

c. EAP-FAST

d. EAP-GTC

8. Which of the following lists accurately describes the components required for ISE to process certificate-based authentications?

a. ISE is capable of processing certificate-based authentications by default, and no additional configuration is required.

b. EAP-TLS enabled in the Allowed Protocols, a CAP, Signing CA’s Public Certificate added to the Certificate Store with the Trust for Client Authentication attribute enabled, and either CRL or OCSP configured.

c. EAP-TLS enabled in the Allowed Protocols, a CAP, Signing CA’s Public Certificate added to the Certificate Store with the Trust for Client Authentication attribute enabled, and an authorization rule for the extracted identity.

d. EAP-TLS enabled in the Allowed Protocols, a CAP, Signing CA’s Public Certificate added to the Certificate Store with the Trust for Client Authentication attribute enabled.

9. What does the Download CA certificate chain link on the Microsoft CA provide an ISE administrator?

a. A form for the admin to fill out and request the CA administrator send its public key, including any intermediary CAs.

b. Configures the Windows client to provide the signer’s public key during the authentication process, along with its own (hence, its certificate chain).

c. Downloads a PKCS file, which is a certificate chain file that will contain the public certificates for the CA and any intermediate CA in the hierarchy.

d. Redirects the admin to a new page where she can purchase the public key from the certificate authority.

10. Live Log provides a glance at a lot of information, including a brief failure reason. What should an admin do to find a more detailed explanation of the failed certificate authentication and a possible resolution?

a. From Live Log, navigate to Operations > Reports > Failed Authentications.

b. From Live Log, click the Details icon, which will launch the authentication details report.

c. Immediately email Aaron Woland of Cisco and ask him why this isn’t working.

d. Call Cisco TAC because if the detail is not in Live Log, it doesn’t exist.

Foundation Topics

Certificate Authentication Primer

The subject of certificate authentication does not have to be scary; there are a few universal truths when discussing certificate-based authentications. Standard certificate authentication is the same, regardless of whether the certificate authority is built by Microsoft, Cisco, Symantec, Entrust, and so on.

Let’s start with a quick definition of a certificate. A certificate is a signed document that represents an identity. When thinking of a certificate, try to relate it to a passport, a driver’s license, or another personal identification card. That identification card is meant to represent you and prove you are who you say you are.

How does a business or security checkpoint know to trust that identification?

When presented with a certificate, an authentication server will perform the following checks (at a minimum):

1. Determine whether a trusted authority has signed the digital certificate.

2. Examine both the start and end dates to determine whether the certificate has expired.

3. Verify whether the certificate has been revoked (you could use OCSP or CRL check).

4. Validate that the client has provided proof of possession.

Let’s examine these four items one at a time:

Determine Whether a Trusted Authority Has Signed the Digital Certificate

The signing of the certificate really has two parts.

The first part is that the certificate must have been signed correctly (following the correct format and so on). If it is not, it will be discarded immediately. Next, the signing certificate authority’s (CA’s) public key must be in the list of trusted certificates, and that certificate must be trusted for purposes of authentication. Using Cisco ISE as an example, a copy of the signing CA’s public key must be stored at Administration > System > Certificates > Certificate Store, and it must have the Trust for client authentication use-case.

Figure 16-1 shows ISE’s certificate store and the Trust for Client Auth field.

Figure 16-1 Administration > System > Certificates > Certificate Store.

Figure 16-2 shows the details of the public key belonging the Active Directory CA and has the Trust for Client Authentication check box enabled.

Figure 16-2 Active Directory CA certificate details.

So not only does ISE “trust” certificates that have been signed by this CA, but it also trusts those certificates for a specific use-case (client authentication). If a client presents a certificate and that certificate has not been signed by a CA that is trusted for client authentication, then the authentication will fail. It’s exactly like someone entering the wrong password or a bartender spotting a fake ID. Access rejected!

Examine Both the Start and End Dates to Determine Whether the Certificate Has Expired

Continuing to use the driver’s license or passport as an example, two dates are usually listed on the document: the date issued and the date it expires. If you try to use an expired license or an expired passport, it should be denied. For example, if you were trying to get through security at an airport and presented the TSA agent with an expired driver’s license, he is not supposed to allow you through the gate.

The picture on the identity is still clearly you, and it was obviously a valid identification card once, so why would they ever reject it? Ultimately, because the signing authority (DMV) is no longer warrantying that the document is valid, that’s why.

A certificate will also have two dates listed in it: a date issued and date it is valid until (when it expires). The authentication server performs a similar check to what the TSA agent does and should reject any certificate that is not within its validity range. In other words, it will check to see whether the certificate is valid for the date and time at which the authentication request comes in.

This is one reason Network Time Protocol (NTP) is so important when working with certificates. Many of us have seen problems where time was out of sync. For example, a certificate was presented on January 10, 2014, at 11:11 a.m., but its “valid-from” value started on January 10 at 11:30 a.m. In this example, the certificate was issued for a time 19 minutes in the future. This was because of a time sync issue where the CA thought it was 20 minutes later than the authentication server, so the brand-new certificate was not valid yet! This type of problem is so common you would laugh (or cry).

Figure 16-3 shows a certificate and highlights the Valid-From and Valid-To attributes.

Figure 16-3 Certificate validity period.

Verify Whether the Certificate Has Been Revoked

Pretend for a moment that you are driving down the road and are pulled over by a police officer. The officer asks for your driver’s license and proof of insurance. You hand him a driver’s license, which is immediately checked for evidence of authenticity—that is, does it look like a valid driver’s license or a forgery? Okay, it’s not a forgery. Check. Next, expiration? It is not expired. Check. Now the officer asks you to wait while he goes back to his squad car.

While in the squad car, the officer performs some authorization checks (are you a registered owner of the car you were driving, and so on). Those are not important for this hypothetical scenario, though. What is important is that the officer must make sure your valid driver’s license was not revoked by the Department of Motor Vehicles. A quick lookup on the computer into the DMV records shows that your driver’s license was revoked for too many DWIs. The cold steel of the handcuffs and the rough shove into the back of the squad car as you are hauled off to jail make you reevaluate your life choices.

Certificate authentication has the same capability (not the handcuffs, I’m talking about the lookup into the DMV to check on revocation status). Every CA should also have a service to publish a list of certificates that have been revoked. The two main ways to do this today are

Certificate Revocation List (CRL)—This is basically a signed list that the CA publishes on a website that can be read by authentication servers. The file is periodically downloaded and stored locally on the authentication server; when a certificate is being authenticated, the server examines the CRL to see whether the client’s cert was revoked. A CRL could be compared to the police officer having a list of suspended drivers in his squad car. Much like that list, the CRL is downloaded and cached for a period of time and therefore might not be valid in some cases (such as a certificate that has been reinstated).

Online Certificate Status Protocol (OCSP)—This is the preferred method for revocation checks in most environments today because it provides near real-time updates. OCSP allows the authentication server to send a real-time request (similar to an HTTP web request) to the service running on the CA or another device and checking the status of the certificate right then and there. OCSP could be compared to the police officer using the computer in the squad car and doing a lookup into the DMV’s database.

If the certificate has been revoked, then access is denied. Enjoy the lights and sirens on the way to jail.

Figure 16-4 shows an example of the configuration screen for a trusted certificate in the Cisco ISE GUI. With each trusted certificate, you have the ability to configure where to check for OCSP or CRL on a per-trusted CA basis. When ISE is authenticating a certificate that has been signed by that particular root (or it’s subordinates), ISE will use the configured service to lookup revocation status.

Figure 16-4 Configuration for certificate revocation checking.

It’s very important for you to understand that checking for certificate revocation is an option. You’ll notice that neither check box for CRL or OCSP are on by default; they require the admin to configure the URL or the service location. It is also critical to understand what behavior will happen if the service is not available or the status of the certificate is unknown—that is, how does the authentication policy handle exceptions? Is it configured to “fail-open” or “fail-closed”?

The client’s certificate itself will have an extension called CRL Distribution Points, which can be populated with the URI where the authentication server may locate the CRL. Figure 16-5 illustrates this certificate attribute. However, it is important to note that Cisco ISE will ignore this field and use only the configured CRL point shown in Figure 16-4.

Figure 16-5 CRL distribution points attribute.

Another interesting factoid about managing revocation lists is that in the previous section where we discussed the certificate expiration, we looked at the fields Valid-From and Valid-To. These fields form the validity period, which defines the period of time that the signing CA warrants it will maintain revocation information regarding that certificate. When the certificate expires, the CA is no longer responsible for maintaining a record of its revocation status. This helps keep CRL and OCSP lists at manageable sizes.

Validate That the Client Has Provided Proof of Possession

Is there a way for an authentication server to be sure the client truly owns the certificate? Think of the example of being pulled over by a police officer for speeding (yes, again). You hand the officer a driver’s license, and she evaluates it. The results of the evaluation are as follows:

It is a valid driver’s license, and has it been issued by a trusted signer (the state DMV)?

It has not expired yet, so that is no problem.

The police officer uses the computer to validate with the DMV that the driver’s license has not been revoked.

All three of those have passed their evaluation checks. However, the picture on the driver’s license is a picture of a woman with long, flowing brown hair and hazel eyes, yet you yourself are a bald, elderly man. OOPS! This “valid” driver’s license was not issued to you—the proof of possession has failed! Again—jail time!

Certificate authentications do something similar. There will be some throwaway piece of data that must be encrypted and decrypted. Successfully encrypting and decrypting that data ensures that the client has both the public and private keys, and therefore it is the proof of possession. This ensures that someone did not just grab the client’s public key and try to present that as being his own. If the client cannot provide proof of possession, then the authentication will fail—Access-Reject.

Certificates (specifically, X.509 certificates) are part of a Public Key Infrastructure (PKI) and can be used for asymmetric encryption. Each certificate is really part of a key-pair consisting of a public key and a private key. The public key is a certificate that is seen by anyone and everyone. The private key is one that only the owner should ever see or possess.

What makes this interesting is that something that has been encrypted using the private key can be decrypted only by using the public key. Additionally, if something was encrypted using the public key, it can be decrypted only by using the private key. These public and private keys are mathematically married. That is why the proof of possession works to ensure the endpoint truly has the full key-pair and not just a copy of the public key. The throwaway data is encrypted with the combination of the authentication server’s private key and the client’s public key (the certificate sent for authentication). Then the endpoint must decrypt the data with the combination of its private key and the server’s public key.

A Common Misconception About Active Directory

Microsoft Active Directory (AD) has a certificate authority built in to it that can be enabled as a full enterprise-wide PKI. In fact, it’s the single most common CA type used today. When the AD certificate authority is used to issue the certificates, many administrators think this is the same as an Active Directory authentication. This is not the case.

What can often confuse people with regard to Authentication Authorization and Accounting (AAA) is the difference between authentication and authorization. They often blend so much. A certificate issued by Active Directory Certificate Services is still just an X.509 certificate. It will go through all the authentication validation of any other certificate, regardless of the fact that the CA was integrated into AD. Authenticating the certificate itself is not using Kerberos, such as AD authentications do; it doesn’t retrieve any Active Directory attributes, such as group membership; and no AD permission/rights are assigned because of the certificate itself.

What is possible, however, is to examine a field of the certificate and then to do a separate lookup into AD based on that field during the authorization phase. For example, a certificate with a subject of Aaron is sent via EAP-TLS. The certificate is validated through the four functions of certificate authentication, and it passes all four. Now it’s time for the authorization. ISE will take the certificate subject (Aaron) and do a lookup into AD for that username. This is where group membership and other policy conditions are examined and the specific authorization result issued.

Cisco ISE uses something called a Certificate Authentication Profile (CAP) to examine a specific field and map it to a username for authorization. Figure 16-6 shows a sample CAP.

Figure 16-6 Allowed Protocols Services.