1 / 33

Ongoing Efforts to Build The US Federal PKI Bridge

Ongoing Efforts to Build The US Federal PKI Bridge. From Presentations by Federal PKI Policy Authority Officials and Others Put together by J. Scott, 2006. HSPD-12 -- George Bush. On August 27, 2004, the White House issued Homeland Security Presidential Directive (HSPD) 12.

aderes
Download Presentation

Ongoing Efforts to Build The US Federal PKI Bridge

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ongoing Efforts to BuildThe US Federal PKI Bridge From Presentations by Federal PKI Policy Authority Officials and Others Put together by J. Scott, 2006

  2. HSPD-12 -- George Bush • On August 27, 2004, the White House issued Homeland Security Presidential Directive (HSPD) 12. • Primary objectives of HSPD 12 are: • To develop and deploy a Federal Government-wide common and reliable identification verification system • To use this system to interoperate between all Government agencies and serve as the basis for reciprocity between those agencies. J. Scott 2006

  3. HSPD-12 • Mandates all Federal Agencies issue ID credentials using FIPS-201 identity proofing procedures beginning 10/05 • Mandates all Federal Agencies begin issuing SmartCards with medium assurance digital certificates by 10/06 • Authorization remains a local prerogative within each participating agency J. Scott 2006

  4. Federal PKI Architectureafter HSPD-12 • Agency and other government PKIs required to cross-certify with the Federal Bridge CA • As of 12/05 no new agency PKIs; agencies procure PKI services from vendors participating in the Shared Service Provider (SSP) program • Architecture issues TLS/SSL certs to credential service providers who CAF, to provide mutual authentication • Federal Bridge CA serves as “point of insertion” for external PKIs and other bridges. J. Scott 2006

  5. Simplified Diagram of Federal PKI Federal Bridge CA Cross- Certified gov PKIs Common Policy CA Shared Service Provider PKIs (Common Policy OID And root Cert) C4 CA E-Gov CAs (3) Cross- Certified External PKIs eAuth CSPs J. Scott 2006

  6. Electronic Authentication • Initiatives • Assessment Framework for Credentials: evaluating the level of assurance (LOA) of identity of credential service providers • Membership in Liberty Alliance • Frequent meetings with Microsoft • Interfederation Interoperability Project with Cybertrust and Internet2/Shibboleth team J. Scott 2006

  7. Credentials Assessment Framework • Credential Assessment Framework consists of the following: • A structured methodology and procedures for evaluating the LOA of a CSP’s credentials • An assessment team that goes out and evaluates CSPs • A process for conflict resolution • Posting CSPs and their credential LOAs to a trust list (unfortunate term) on the website J. Scott 2006

  8. E-Authentication: Interfed Interop • inCommon Higher Education Identity Federation • Using Shibboleth middleware technical protocols • Policy-light • E-Authentication US Identity Federation • Using a variety of technical protocols • Policy intensive J. Scott 2006

  9. What Are Electronic Identity Federations? • Associations of electronic identity credential providers and credential consumers (electronic service providers) who: • Agree to trust each others’ credentials; • Agree to hold credential providers authoritative for the validity of their credentials; • Agree to use common communications protocols and procedures to enable interoperability • Agree to common business rules J. Scott 2006

  10. Purpose of Electronic Identity Federations • To enable trusted electronic business transactions between end users and service providers • The service provider does not have to issue and manage identity credentials, including attributes. • It’s all a matter of scaling.. • No, it’s also a matter of control J. Scott 2006

  11. Characteristics of Identity Federations • Standards and protocols for technical interoperability among credential providers, services providers, end users and infrastructure utilities • A governance mechanism to assert common business rules, ensure credentials can be used and trusted by all members of the federation and a central control point for entry and exit of members J. Scott 2006

  12. E-Auth Level 1 FPKI Rudimentary, C4 E-Auth Level 2 FPKI Basic E-Auth Level 3 FPKI Medium & Medium-cbp E-Auth Level 4 FPKI Medium/HW & Medium/HW-cbp FPKI High (government only) LOA Mapping: E-Auth to Fed PKI J. Scott 2006

  13. Federal Bridge CA Goals • Leverage emerging Federal Agency PKIs to create a unified Federal PKI and provide a cross-governmental, ubiquitous, interoperable Public Key Infrastructure. • Limit workload on Agency CA staff • Support Agency use of: • Any FIPS-approved cryptographic algorithm • A broad range of commercial CA products • Propagate policy information to certificate users in different Agencies • Support the development and use of applications which employ that PKI in support of Agency business processes. J. Scott 2006

  14. FBCA Certification Overview • Designed for the purpose of creating trust paths between among PKI domains • Issues cross-certificates to Member CAs only • Employs a distributed, NOT a hierarchical, model • Commercial products participate within the membrane of the Bridge OR interoperate with products within the membrane • Develops cross certificates within the membrane to bridge the gap among dissimilar products J. Scott 2006

  15. FBCA Management Hierarchy • Steering Committee oversees FBCA development and operations • Direct Operational Authority • Bridge Documentation • Enhancements • Policy Authority determines participants and levels of cross-certification • Administers Certificate Policy • Approves requests to cross-certify • Enforces compliance by member organizations • GSA named Operational Authority • Operates in accordance with Policy Authority and Steering Committee direction J. Scott 2006

  16. Generalized FBCA Architecture CA, Directory, End users Bridge CA And Directory Bridge CA And Directory Trustpaths Trustpaths Trustpaths CA,Directory, End users CA, Directory, End users J. Scott 2006

  17. A Snapshot of the U.S. Federal PKI CANADA PKI Illinois PKI DOD PKI Federal Bridge CA NASA PKI Higher Education Bridge CA DOA NFC PKI University PKI J. Scott 2006

  18. FBCA Membrane Architecture • Multiple commercial CAs within a “membrane” that cross-certify and interoperate • CyberTrust and Entrust Enterprise CA’s for cross-certification • CAs offline • No network connectivity • CA uses “Sneaker Net” to get to the directory • FBCA directory online 24 X 7 X 365 J. Scott 2006

  19. Federal Bridge CA Canada Cybertrust CA Entrust CA GSA/FTS NSA NIST 2 CYGNACOM PCA PCA DoD Bridge CA CYBERTRUST Entrust PCA PCA PCA PCA SFL Client Entrust Client CA CA CA CA NIST 1 GTRI NASA PCA PCA PCA CA CA CA CA Motorola Entrust Entrust Entrust Entrust Spyrus Entrust Client SFL Client SFL Client Entrust Client Entrust Client Entrust Client Entrust Client J. Scott 2006

  20. What Will It Take to Use the FBCA? • Policy mapping of certificate policies • Sharing annual audits • Careful management of cross-certificates to limit transitive trust (exclusion trees) • Directory interoperability and synchronization • Client software for certificate path discovery and processing J. Scott 2006

  21. Next Steps To Federal Bridge PKI • Continue to bring federal agencies into interoperability • Bring additional products into Bridge membrane • Pursue interoperability with State PKIs • Pursue interoperability with Nation of Canada • Pursue interoperability with non-government sector bridges J. Scott 2006

  22. Why A U.S. Federal PKI? • Mandates, such as HSPD-12, for e-government and implementing electronic signature technology • Demands for improved services at lower cost • International Competition • International Collaboration J. Scott 2006

  23. Why NOT a U.S. Federal PKI? • Concerns of Privacy Advocates • Agency internal politics • Vendor battles for market space • Cost J. Scott 2006

  24. Building A U.S. Federal PKI • Agencies implement their own PKIs • Create a Federal Bridge CA using COTS products to cross-certify individual Agency PKIs and bind them together • Establish a Federal PKI Policy Authority to oversee operation of the Federal Bridge CA • Ensure directory compatibility • Use ACES for transactions with the public J. Scott 2006

  25. FPKI Policy Authority • Determines participants and levels of cross-certification • Participants become voting members • Administers Certificate Policy • Enforces compliance by member organizations • General Services Administration serves as Operational Authority J. Scott 2006

  26. Policy Mapping • Candidate Certificate Policies evaluated against the FBCA CP for adequacy and levels of assurance: • Identity binding • CA security • Performed by the Federal Policy Management Authority Certificate Policy Working Group with contractor support • Requirements publicly available on NIST website J. Scott 2006

  27. Policy Equivalence Example Fed PKI High DoD 4 ISO Banking Can High Can Medium Fed PKI Med DoD 3 Can Basic DoD 2 Fed PKI Basic Can Rud Fed PKI Rud J. Scott 2006

  28. Bridge CA Canadian CA DOD CA Policy Mapping Example Federal High = DoD CLASS 4 Federal Medium = DoD CLASS 3 Federal High = Canadian High Federal Medium = Canadian Medium DoD CLASS 4 = Federal High DoD CLASS 3 = Federal Medium Canadian High = Federal High Canadian Medium = Federal Medium DoD CLASS 3 Subscriber DoD CLASS 3 Subscriber Can. HIGH Subscriber Can. MED Subscriber J. Scott 2006

  29. Cross Certifying with the Bridge • Applicant PKIs and Bridges may cross-certify with the Federal PKI at one or more of the five levels of assurance of the Federal Bridge CA • Rudimentary, basic, medium, medium hardware and high • Applicants can also cross certify at the Citizen and Commerce Class Certificate level of assurance. J. Scott 2006

  30. Requirements for Cross-Certifying • Managers of PKI’s that wish to Cross Certify with the Federal Bridge PKI should contact the Policy Authority prior to submitting any documentation, so that we can work with you actively to smooth the process. • Requirements for Cross-Certification and Interoperability with the Federal PKI: • Submit a copy of your PKI Certificate Policy for mapping, along with contact information for the individual tasked with seeing to the cross-certification. Please download a copy of the "mapping matrix" available on the web site to use as you prepare your Policy for mapping. • Submit an Application for Cross-Certification signed by the responsible executive in charge of the applicant PKI (e.g., CIO, VP for Systems, etc.) to the Federal PKI Policy Authority Chair. Usually, this individual is in charge of funding and budget for the applicant's PKI. J. Scott 2006

  31. More Bridge Requirements 3. Submit a copy of the summary of your PKI's audit, stating that your operations comply with your CPS and that your CPS is in conformance with your CP. Please download a copy of the Audit Review Requirements from this web site to ensure you understand what language we are looking for. • If steps 1 - 3 are accomplished successfully, the Federal PKI Policy Authority will enter into negotiations with you to sign a mutually-acceptable Memorandum of Agreement (MOA) that will spell out our mutual responsibilities and expectations. For Bridges cross-certifying with the Federal Bridge CA, there are additional requirements to be fulfilled mutually. • Once the MOA is signed, the Federal PKI Policy Authority Chair directs the Director of the Federal PKI Operational Authority to exchange cross-certificates with the new member PKI. • Detailed discussions of all of these steps may be found in the FPKI Criteria and Methodology document on this web site, as well as many other supporting documents. J. Scott 2006

  32. An FCBA Status Report • On Sept. 18, 2002, the FBCA cross-certified with the public key infrastructures to allow them to trust and validate the digital signatures on files issued and received from one another • The US Department of Defense • U.S. Department of the Treasury • U.S. Department of Agriculture • National Finance Center • National Aeronautics and Space Administration J. Scott 2006

  33. Cross Certified PKI’s March 2006 Organization Certified Certification Level Date Certified • NASA Medium September 18, 2002       • USDA/National Finance Center Medium September 18, 2002 • USDA/National Finance Center Basic October 20, 2003       • Department of Defense Medium* September 18, 2002       • Department of the Treasury High September 18, 2002 • Department of the Treasury Medium September 18, 2002       • Department of State High January 21, 2004       • State of Illinois Medium January 21, 2004  • State of Illinois Basic** March 8, 2005       • ACES/Digital Signature Trust Medium February 11, 2004       • Department of Energy Medium April 27, 2004       • DoD External Certification Authority Medium** February 8, 2005       • ACES/ORC, Inc. Medium** February 8, 2005       • US Patent & Trademark Office Medium June 1, 2005       • Department of Homeland Security Medium June 1, 2005  • Department of Homeland Security High June 1, 2005  • Department of Homeland Security Basic June 1, 2005       • Wells Fargo Basic* December 13, 2005       • Government Printing Office Medium** December 13, 2005       • Department of Justice High** December 15, 2005 *    FBCA issued cross-certificate allowing one-way trust **   This was the date the Federal PKI Policy Authority voted on and approved issuing a FBCA cross-certificate J. Scott 2006

More Related