1 / 22

HEBCA: Higher Education Bridge Certificate Authority

HEBCA: Higher Education Bridge Certificate Authority. Michael R Gettes Georgetown University gettes@Georgetown.EDU. PKI is 1/3 Technical and 2/3 Policy?. Policy. Technical. Multiple CAs in FBCA Membrane. Survivable PKI Cross Certificates allow for “one-way policy”

Download Presentation

HEBCA: Higher Education Bridge Certificate Authority

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. HEBCA: Higher Education Bridge Certificate Authority Michael R Gettes Georgetown University gettes@Georgetown.EDU

  2. PKI is 1/3 Technical and 2/3 Policy? Policy Technical

  3. Multiple CAs in FBCA Membrane • Survivable PKI • Cross Certificates allow for “one-way policy” • Directories are critical in BCA world.

  4. A Snapshot of the U.S. Federal PKI DOD PKI Illinois PKI CANADA PKI Federal Bridge CA NASA PKI Higher Education Bridge CA University PKI NFC PKI

  5. EMA Challenge Architecture

  6. What is Cross Certification? • A Bridge signs a site PKI and vice-versa • Cross Certificates are published in directories and discovered via the network. BCA/CA may remain off-line. • Policy OIDs and Name Constraint controls are in the cross certificates • Policy OIDs could map to XML documents describing the policy (processed per Carmody)

  7. Path Validation • Application receives a Certificate • Finds a path back to signer of Certificate validating the path for policy mappings and name constraints. • Policy Mappings can be LOA (levels of assurance) or “we agree to be in club shib” or whatever • Name Constraints controls subjectName name space. I.E. a CA can only sign within dc=U,dc=edu

  8. On Policy • We have a draft HEBCA Certificate Policy • The HE CP and HEBCA CP are congruent • The HEBCA CP and FBCA CP are congruent • We need a HEPKI PA – EDUCAUSE is working this problem – granted “power” from ACE

  9. NIH- Educause PKI Pilot:Phase Two Electronic Grant Application With Multiple Digital Signatures Peter Alterman, Ph.D. Director of Operations Office of Extramural Research

  10. The Goals • Receive NIH research grant application in electronic form signed with two different digital certificates each; digital certificates issued by Institution, several different vendors represented; • Verify and validate digital signatures through ACES Certificate Arbitration Module (CAM). • (EDUCAUSE Funding and Administrative Support, Coordination and Marketing.)

  11. Intermediate Requirements • Stand up a Higher Education Bridge Certification Authority (HEBCA); • Cross-certify the Federal Bridge CA with the Higher Education Bridge CA; • Cross-certify Institutions with HEBCA;

  12. Participating Institutions • University of Alabama-Birmingham • University of Wisconsin-Madison • University of California, Office of the President • University of Texas – Houston • Dartmouth College • (Georgetown University – HEBCA issues)

  13. The Problem • Picture/s of piles of grant applications • About 20,000 6 ft high standing people of paper. • 1 forest per year just grant apps. • The Solution: signed, electronic grant application • Of course!

  14. HEBCA E-Lock Assured Office Digital Signed Grant Appl Certificate Validation University A NIH OER Mail Server University A FBCA Internet Certificate Validation University B E-Lock Assured Office Digital Signed Grant Appl University B NIH CAM Server Certificate Validation University C Cert Status NIH OER Recipient E-Lock Assured Office Digital Signed Grant Appl E-Lock Assured Office Digital Signed Grant Appl University C E-Lock Assured Office CAM-enabled Cert Status Phase Two Concept of Operations (CONOPS)

  15. Prototype Federal Bridge Certificate Authority Higher Education Trust Domain Firewall Cross Certified CAs RSA CA Entrust CA RSA CA i500 Directory FIP 140-1 L3 Crypto NIH Trust Domain FIP 140-1 L3 Crypto NIH Test CA • Cross certificates • CRL • Cross certificates • CRL Directory DST ARP Test CA iPlanet CA Directory • Cross certificates • ARL Verisign CA Directory System Agent NIH User Alabama Wisconsin California HEBCA Proof of Concept Architecture

  16. Prototype Federal Bridge Certification Authority Higher Education Bridge Certification Authority Entrust CA RSA CA RSA CA DST ARP Test CA Verisign CA NIH Test CA iPlanet CA Client Client Client California Alabama NIH Client Wisconsin HEBCA Proof of Concept CA Interoperability Configuration

  17. Prototype FBCA (Peerlogic) HEBCA (Critical Path) c=US; o=U.S. Government;ou=FBCA IP address: 198.76.35.155 DSP port: 102 LDAP port: 389 TSEL: TCP/IP c=US; o=edu; ou=HEBCA IP address: 207.123.140.5 DSP port: 102 LDAP port: 389 TSEL: TCP/IP Chaining cn=FBCA_Directory cn=HEBCA NIH Chaining Chaining California Wisconsin Alabama cn=nihstandin c=US; o=U.S. Government; ou=NIH IP address: 207.123.140.5 DSP port: 102 LDAP port: 389 TSEL: TCP/IP cn= cn= cn=ARP Test Client CA c= ; o= ; ou= IP address: DAP/DSP port: LDAP port: c=US; o=Digital Signature Trust Co; ou=ARP Testing IP address: 208.30.65.30 DAP/DSP port: 102 LDAP port:389 c= ; o= ; ou= IP address: DAP/DSP port: LDAP port: HEBCA Proof of Concept Directory Interoperability Configuration

  18. FBCA cross cert FBCA dir cross cert HEBCA HEBCA dir get Cert,CRL via directory chaining cross cert UA ca NIH ca UA dir NIH directory trust anchor ca DAVE issued CAM E-Lock directory sender (UA) receiver (NIH) software “DAVE” (Discovery and Validation Engine) New LDAP Registry of Directories for BCAs

  19. CML Libraries [Getronics] ASN1 parsing (SNACC) S/MIME parsing (SFL) Cryptographic engine LDAP and local directory retrieval (SFL) Path discovery engine (CPL) DAVE Functions Perform proper sequential calling of CML functions (i.e., the business logic) Provide call-back functions needed by CML functions Provide all CAM communications and protocol transformations Wraps CML functions into an NT service (multithreaded, failure and recovery modes, logging, etc.) DAVE Components

  20. Agency App = E-Lock Assured Office CAM-enabled CAM/CA Passing Certificate OCSP Certificate Authority/ Validation Request CAM Server • E-Lock Assured Office verifies the signature • Verifies the document has not been changed • Verifies the validity period of the certificate • Once verified, the certificate is sent to the • CAM for certificate validation to ensure that • it has not been revoked Msg Data Agency App/ CAM Discovery and Validation Engine (DAVE) • Search for issuer to validate • CRL • OSCP Responder • If chained, path reverses • If not chained, LDAP queries Verification & Validation Details

  21. Bridge CA vs. Shibboleth • PKI is hard to deploy to end users • Shib should use BCA aware PKI between servers • Club Shib will then scale using Policies and Relationships established by Bridge CA world • ONE Club Shib managed by policy • Java 1.4 is Bridge aware. Whistler supposed to be.

More Related