Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Clear all filters
Answers

how to implement DOD CAC authetication?

I would like to know how to implement DOD CAC authentication with VIP. Also, OCSP setup with it.

0
Rate this Discussion

Replies to this Discussion

placeholder+image

First, certificate authentication is a pretty broad term and can imply a lot of things. At a minimum it involves consuming a client (smartcard) certificate and basic validation (expiration and trust). You can then add revocation checking (OCSP, CRLDP, or simple flat file CRL), and then once you have a known good, known non-revoked certificate, you can use the (x509) information within to provide actual authentication to an application (SSO). Beyond the basic validation though, everything else is as required for your environment. So because this thread could go on for many pages, I'll assume primarily that you just need to perform basic validation and revocation checking. Here's how that'd look for APM and LTM native:

LTM:

You want to start with a client SSL profile that has the following qualities:

  1. Server certificate and key - this is the server certificate presented to the client during the initial stages of the SSL handshake.

  2. Client Certificate Authentication option set to request or require - which option you choose depends on how deterministic you need it to be. Request will request a certificate, but not fail if any of the validation checks fail. Require will also request a certificate, but will fail the connection if validation is not perfect.

  3. Trusted Certificate Authorities option selected with a "bundle" of CA certificates - just as the browser validates its trust in the server's certificate based on an explicit trust established from its CA certificate "store", so to must the client SSL profile validate the client's certificate based on an established and explicit store of CA certificates. Generally this means creating a "bundle" of CA certificates and importing to the BIG-IP. A bundle is a text file that contains the PEM-formatted certificates of all of the CA certificates that would be used to establish a FULL chain of trust from the client certificate's issuer to a self-signed root.

  4. Advertised Certificate Authorities option selected with a "bundle" of CA certificates - this option is actually optional. When the BIG-IP requests the client's certificate as part of the SSL handshake, it can optionally insert "root hints" - a list of CA certificates that the client must key off of to select an appropriate certificate. So let's say for example you have a DoD CAC that has an identity certificate issued by one CA, and a few email certificate (signature and encryption) issued from an email CA. Because you may only want the user to select an email certificate (because it's the only one with the EDIPI number in the SAN UPN), you could create an advertized bundle that includes all of the email CAs, but none of the identity CAs or the self-signed root. In most browsers this will cause the certificate selection dialog to filter out anything that doesn't meet the right criteria.

With the client SSL profile created and applied to the virtual server, you now have basic client certificate "authentication". You can then optionally apply a revocation checking method to further validate the certificate. That could be:

  1. Flat file CRL - this is a CRL that you've uploaded to the BIG-IP and attached to the client SSL profile. Given that you're talking about DoD CAC though, there are many DoD CRLs and most are very large, so this isn't the best option.

  2. CRLDP - this is an authentication profile that reads the CRLDP extension in the client certificate, fetches the CRL from the specified remote URL, and then validates the client certificate based on that CRL. Thankfully the CRLs are cached for some length of time, but as before, DoD CRLs are quite large, so unless you have some mechanism to "prime the pump", you can guarantee that the first client (or more) will fail until these large CRLs are downloaded. Also, up until 11.4 HF5(?) CRLDP only worked with LDAP-based CRLDP URLs, which DoD CRLs are not. 11.4 HF5 and 11.5 now support HTTP-based CRLDP.

  3. OCSP - for DoD especially this is probably the best option. OCSP is a protocol that allows a "client" (the BIG-IP in this case) to make a very small request to an OCSP service (a service that has all of the CRLs in memory) containing the certificate serial and issuer information, and receive a very simple, very small response (good, revoked, or unknown). You can usually point directly to the DoD's established OCSP services, but I believe the current recommendation is to build your OCSP services and 1) cache the CRLs locally, and 2) only use the DoD's services directly as a backup.

At this point you've consumed a client certificate, provided basic validation and then revocation checking, and now have a known good, known non-revoked client certificate. What you do with the certificate after that depends entirely on how (or if) you want to integrate that into application authentication.

APM:

The idea is similar here, but implemented slightly different.

  1. Create the client SSL profile as above, but this time set the Client Certificate Authentication option to ignore - all other settings will still apply, but we'll let APM actually request the certificate.

  2. Create an OCSP or CRLDP AAA profile - this configuration will look eerily like the same LTM authentication profiles.

  3. Create a standard APM access profile, open the visual policy, and add 1) and On-Demand Certificate Auth agent (set to request or require), and then 2) an OCSP or CRLDP Auth agent - The On-Demand Cert Auth agent will trigger an SSL renegotiation and client certificate request. The properties of the client SSL profile will still apply to validation. After that, the OCSP or CRLDP auth agents will basically perform the same functions as the LTM auth profiles, but within the confines of APM.

From this point it actually gets really interesting. because you now have the X509 certificate properties in APM session variables, you can do some really cool things like additional LDAP/AD queries, Kerberos SSO to the application, and a lot of other flexible things. Again, this part could go on for many pages, so I'll leave it here for now.

1
Comments on this Reply
Comment made 11-Feb-2014 by songj2315 129
Another question is "Is there way to capture X509 certificate properties in APM session variables or iRule so I can pass that information to cold fusion server admin for create the authorization process? I really appreciate your answer. It will be BIG help on my project. THANKS !!!!!
0
Comment made 19-Feb-2014 by songj2315 129
Kevin, I have problem with APM On-Demand Certificate Auth agent. If I set to require, it didn't get to the message box that I created right after On-demand on VPE. Also, I got the CAC prompt but no prompt for PIN when I tested web page. Do I have to setup reverse proxy along with APM? Thanks, -James thanks, -James
0
placeholder+image

Are you referring to a pure LTM configuration, or with APM? You can do some pretty cool stuff with either in regards to DoD smartcards.

0
Comments on this Reply
Comment made 11-Feb-2014 by songj2315 129
Could you let me know both way? I would like go with easy way. thanks in advance
0
Comment made 11-Feb-2014 by songj2315 129
If its' possible, I would like to have your guide with APM.
0
placeholder+image

Is there way to capture X509 certificate properties in APM session variables or iRule so I can pass that information to cold fusion server admin for create the authorization process?

A resounding YES.

For LTM, the X509 certificate properties are exposed using the X509:: set of commands:

https://devcentral.f5.com/wiki/iRules.X509.ashx

Example:

[X509::subject [SSL::cert 0]] 

For APM, the x509 values are stored in a set of session.ssl.cert.* session variables. Example:

session.ssl.cert.subject
session.ssl.cert.issuer
0
placeholder+image

If I set to require, it didn't get to the message box that I created right after On-demand on VPE.

What DOES it do? Do you by chance have the request or require option also set in the client SSL profile?

Also, I got the CAC prompt but no prompt for PIN when I tested web page.

That's a client side thing and highly dependent on your environment. Understand that there are several "compartments" on the smartcard chip. One of those compartments is used to store and keep safe the private key. Another compartment is a tiny little computer, in most cases a Java virtual machine, that performs crypto functions with that private key. When you digitally sign something, as in when you present a smartcard certificate to a server, the crypto for that process happens on the card and the private key never leaves its cozy little home. In order to be able to access that private key, however, the JVM needs a PIN. The middleware software that you install (ActivClient?) is designed to perform the negotiation between the user/browser/system crypto services and the card itself, and that is what prompts you for your PIN. Now, given that SSL renegotiation happens pretty frequently within a single HTTPS session, most users would choose not to have to reselect their certificate each time this happens, so browsers will automatically and silently reselect the same cert from the first request, and likewise the middleware software is designed (by default) to cache the user's PIN for some length of time, and will typically do so for the span of a single application's use, but in a lot of cases for any application that needs access to the smartcard, for some length of time. The odd thing about this, is that there appears to be a lot of variables that affect that behavior (OS version, middleware version, local settings, group policy settings, etc.). From experience, ActivClient defaults to caching the user's PIN for 15-20 minutes. The middleware agent built into Win7 (I believe) only caches the PIN for the life of a single running application (but is configurable). So long story short, you're most likely not getting a PIN prompt because the middleware has cached it from some previous request.

Do I have to setup reverse proxy along with APM?

By default, you'll probably want to use APM in a revers proxy configuration (remote client's presenting a smartcard to access some local resource), so yes. You have an LTM VIP with a client SSL profile, HTTP profile, access profile, and a pool (at a minimum). That is a traditional F5 reverse proxy configuration.

0
Comments on this Reply
Comment made 20-Feb-2014 by songj2315 129
Kevin, I have set auth mode as require and no brance rule and irule event ID sets CERTPROC. Please see below for CERTPORC irule. Also, I have configure OCSP responder on local traffic profile authentication and AAA server section on access policy. Do I need to use local traffic OCSP to virtual server or just OCSP on access policy section? If I want to add OCSP check through APM, can I add client inspection with OCSP auth right after the on-demand-cert? current VPE is set as below: start -fallback- On-demand cert auth -fallback- irule event - fallback- allow ACCESS::session data set session.ssl.cert.upn [findstr [ACCESS::session data get session.ssl.cert.x509extension] "othername:UPN<" 14 ">"] } } } } when ACCESS_ACL_ALLOWED { HTTP::header replace CERTUPN [ACCESS::session data get session.ssl.cert.upn] HTTP::header replace CERTSUBJECT [ACCESS::session data get session.ssl.cert.subject] }
0
Comment made 20-Feb-2014 by songj2315 129
I have parsed out APM debug output if you need to go through it for me. I am still not getting PIN section after click from the CAC selection prompt.
0
placeholder+image

I have parsed out APM debug output if you need to go through it for me. I am still not getting PIN section after click from the CAC selection prompt.

Just to be clear, you say you're getting the prompt to elect a certificate, but not the subsequent PIN prompt. Correct? If so, that is completely expected. The PIN prompt mechanism is controlled by the smart card middleware as it accesses the card to request cryptographic functions (digital signature). When a server requests a cert from a client, the server doesn't care where the client stores that cert, nor is there any RFC-based mechanism to control it. In this case, because the private key and crypto functions are actually stored in a chip and require a PIN code for access, the middleware software handles the interface to the user to get that PIN code. After that the middleware can cache that PIN for some length of time so that it doesn't have to ask again. How, and how long the middleware performs that caching is a configurable option within the software itself (a config setting or registry key usually). Again, there is absolutely nothing that you can do on the server side of an SSL session to control how and if a client caches the smart card pin.

0
placeholder+image

At server side, client certificate verification is done with the help of CRLs provided by the authority(where client issued the certificate). To perform this CRL check do server downloads the CRLs every time a client connects to the server or Does server maintains a local CRLs cache which have certain expiry time to avoid the CRLs file downloading every time ???

How can I implement that CRL cache in server side to verify client certificate using tomcat server ?

0
placeholder+image

Battalian,

In 13.1 and below CRLs are binary files that you upload to the BIG-IP. There is no mechanism built in to maintain/refresh/update the CRLs automatically, so you'd need an out-of-band process to download and update the CRLs. This is usually done with a management plane script.

If, however, you're actually talking about CRLDP (from LTM auth profiles or APM), the CRLDP function does actually download and cache the CRL from the client certificate CRLDP attribute.

0