Richard Bullington-McGuire presented this talk on PKI enabling web applications for the DoD at the 2009 MIL-OSS conference: http://www.mil-oss.org/ It is a case study that shares some of the challenges and solutions surrounding the implementation of the Forge.mil system.

1. August 12, 2009 Richard Bullington-McGuire, Director of Technology, Three Pillar Software http://threepillarsoftware.com/ Kevin Hourihane, Principal Collaborative Development Consultant, CollabNet http://www.collab.net/ Enabling Web Apps for DoD Security via PKI/CAC Enablement Presentation for MIL-OSS 2009 http://www.mil-oss.org/

2. Introduction Forge.mil Public Key Enablement of CollabNetTeamForge Faced many challenges Many solutions may be reusable Not a “how-to” or “everything you wanted to know” Sharing “lessons learned”

3. You’re here because… You are considering PKI enabling your DoD web app You are having issues with implementation You want to know how Open Source helped us Other reasons? (Please speak up)

4. Why use Public Key Enablement? You have to: Executive Directives Homeland Security Presidential Directive-12 DoD Directive 8500 Application Security STIG: comply or you’ll never go live You want to: Key benefits Better security through centralized x509 CA authentication Eliminates password management headaches Easy to revoke a compromised identity through CRLs

5. PKE Challenges Legacy systems use user names and passwords Adapting these systems to use certificates is difficult COTS integration: may need to wrap black-box systems Mapping certificates to principals has many tricky issues Cryptography library integration may be needed

6. Certificate Challenges Multiple identity mediums pose challenges Common Access Card (CAC) smart cards on NIPRNet government employees, some contractors get these DoD issued certs Smart card middleware on client computers mediates SSL handshake Soft certificates only on SIPRNet, smart cards coming soon

7. More Certificate Challenges ECA certificates (mostly software) for contractors Issuers: Verisign, IdenTrust, Operational Research Consultants Format of subject DNs vary, no EDIPI on ECA certificates Frequent DoS for Verisign ECA users due to annoyingly short expiration time on Verisign ECA CRL, and flakiness of crl.gds.disa.mil Getting ECA certificates Pay $100 Provide notarized forms Wait 1-2 weeks for issuance

8. Certificate-to-Identity mapping Where’s the unique ID? Why not use EDIPI? No, not in ECA certs Privacy concerns Subject and Issuer DN are insufficient Need serial # also, to record distinct certs $ # show JITC certificate for “Jon Jones” $ openssl pkcs12 -clcerts -nokeys -in Good.p12 | openssl x509 –text | less Certificate: Data: Version: 3 (0x2) Serial Number: 12356 (0x3044) Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=U.S. Government, OU=DoD, OU=PKI, CN=DOD JITC CA-19 Validity Not Before: Sep 16 16:39:58 2008 GMT Not After : Sep 17 16:39:58 2011 GMT Subject: C=US, O=U.S. Government, OU=DoD, OU=PKI, OU=Contractor, CN=Jones.Jon.1234567890

10. Open Source foundation: Apache HTTPD, mod_ssl, mod_python, JBoss, Tomcat, Subversion, Lucene, Apache James, PostgreSQL

11. Key insight: intercept request at Apache module level for PKI & SSO enablementsoftware.forge.mil Application Server svn.forge.mil Integration Server Single Sign On (SSO) Database Application Database

13. Web Rendering

14. SOAP Server

17. Subversion clients (DAV over https)

18. Custom SOAP clients

20. Lucene Indexes

21. SCM viewer (on integration server)External System (via SOAP) w/ x509 Server Cert, Reused as Client Cert PostgreSQL 8.2 Databases On Separate RHEL 5 VMs Red Hat Enterprise Linux 5 VmwareESXi PKE changes to baseline are listed in italics Forge.mil PKE: HTTPD modules

22. Development Challenges Both server-side and client-side work was required Apache httpd and mod_ssl (server-side) authenticate via SSL handshake, extracts SSL variables Handle CRLs (beware 1GB+ CRL memory footprint) mod_python (server-side) provides access to SSL variables SOAP clients SOAP.py and SUDS allow calls into JBoss layer

23. Subversion Client Development Subversion modified for smart card authentication (PKCS#11 support) Work complete: Windows command line Subclipse jsvn Ongoing challenges: Linux command line (CoolKey bug, GnuTLS version clash), Mac command line, TortoiseSVN new versions

24. Critical Cryptography Stacks Open Source cryptography libraries = big win Low-level crypto Present: OpenSSL, GnuTLS Future: NSS Web Server and Client SSL / HTTPS APIs Apache mod_ssl, neon, Python libhttp, Java PKCS#11 Smart Card integration Windows Crypto API / PKCS#11 / CoolKey / ActivClient Python language support mod_python, m2crypto, m2secret

26. Dealing with Change People will ultimately change certificates CAC certs expire in 3 years, ECA in 1 year People’s names change (e.g. by marriage), but people don’t Map certificates to users: many-to-one mapping Admin tools needed to support changes Mapping request support and management console User account request, review and approval process User self service – request to change/add mapping Shortcut to automatic mapping: match EDIPI or (subjectdn+isssuerdn), record new cert, and notify admins

27. SSO implementation SSO challenges Interoperable systems should share the same user store There is no centralized, mandated way to do this yet OpenLDAP & cert-based authentication: more work required to prove out integration path Pull model chosen for Forge.mil SSO capability Central PostgreSQL database stores SSO user mappings Single user name space in SSO DB identifies principals Users are demand-loaded into local Forge.mil instance If an enrolled certificate exists in the SSO database, that principal gets registered locally on the first visit 8/10/2009

28. Open Source tools: opportunities and challenges (part 1) Core open source components made for a win: Apache httpd, mod_ssl, OpenSSL, mod_python, OpenSSL, mod_ssl, m2crypto, Suds, SOAP.py, Key Manager RPM: a huge win for packaging application extensions RHEL 5: a great foundation, look to Fedora 7+ for SRPMS if you need a newer version of a library Python: a good tool for extending systems short test cycles, reasonable library availability, fast maturing as an integration tool. Limited support for SSL and PKI calls in core libraries. Multiple imperfect SOAP libraries, beware of limitations

29. Open Source tools: opportunities and challenges (part 2) PostgreSQL good integration characteristics overall client certificate authentication support just released in 8.4 Subversion Almost all clients support soft certificates out-of-the box Driving PKCS#11 / smart card support into client apps is a continuing challenge TortoiseSVN reverted their support, present in 1.5.4 & 1.5.5 Subclipse-CAC & jsvn & Windows CLI now on software.forge.mil

30. Useful Information JITC PKI team: http://jitc.fhu.disa.mil/pki/ JITC test certs are very useful for interoperability testing SmartCard Resources ActivClienthttp://www.actividentity.com/products/activclient_family__home.php Run your own OpenSSL CA http://sial.org/howto/openssl/ca/ Key Manager https://addons.mozilla.org/en-US/firefox/addon/4471 Sun Java PKCS#11 Provider http://java.sun.com/j2se/1.5.0/docs/guide/security/p11guide.html Python SUDS / HTTPS client cert auth http://threepillarsoftware.com/soap_client_auth SoftwareForge.mil projects Subversion https://software.forge.mil/sf/projects/subversion Community CAC https://software.forge.mil/sf/projects/community_cac

31. Any Questions?