HEPKI-TAG Activities & Globus and Bridges Jim Jokl University of Virginia Fed/ED PKI Meeting June 16, 2004

HEPKI-TAG Activities  Sponsors: I2, Educause,  Charter – Technical Activities Group (TAG) Certificate profiles, CA software Private key protection Mobility, client issues Interactions with directories Testbed projects Communicate results  Process Biweekly conference calls Sessions at higher education events

HEPKI-TAG Projects  Must-do items Support the USHER / InCommon projects Maintain & update existing documents and services  Potential projects discussed and ranked at our meeting Update work on S/MIME Windows domain authentication CA Audits - preparing your internal audit department EAP-TLS for wireless authentication Update on hardware tokens  survey, documentation, recommendations Introductory materials for sites getting started (CA software, applications, cookbook, etc) Other possibilities discussed more briefly  Grid integration  survey  bridge testing  Document and webform signing

One version of the US Higher Education Root (USHER) discussion USHER-Lite InCommon CA Shib Cert School CA USHER Basic/Medium School CA USHER Root

USHER/InCommon Profile Discussions no  Trivial root with no “dots” discussion: no AIA, CPS, CRL etc yes  Authority Information Access: yes both PKCS7 v.s. LDAP: both no  Domain Component Naming: no no  addresses: no yes  Key Usage and CRLs: yes  Validity 10 years for the roots, 3 for InCommon EE certs yes  CPS Pointer: yes (to a redacted version)

Certificate Profiles  InCommon EE Certificate InCommon EE Certificate  USHER Root Profile USHER Root Profile  InCommon Root Profile InCommon Root Profile  Profiles were derived from PKI-Lite EE profile PKI-Lite Root profile

Introductory Materials Aiding Initial Campus Deployments  Recall our PKI-Lite framework Using PKI for “standard” applications Merged policy and practices documentdocument Profiles with suggestions for implementers Profiles  Designed to support S/MIME, VPN, Web Authentication, etc  Validated on other apps (e.g. Globus, document signing applications, etc). New addition: PKI-Lite RecipePKI-Lite Recipe  by Steven Carmody at Brown Changes to Policy/Practices document  Feedback from NMI testbed sites on language on the use of subordinate CAs on campus

PKI-Lite never seems to be quite finished  Macintosh PKI and the PKI-Lite certificate profiles Working with early version of Apple PKI on MacOS 10 Attempts to import PKI-Lite CREN-rooted certificates into Macintosh development release to test S/MIME and EAP-TLS failed Problem: Basic Constraints not marked Critical Many other root certificates with the same issue  Result: Apple release does now accept these certificate profiles More importantly: we modified the PKI-Lite profiles to more closely follow the RFCsprofiles

EUDORA and S/MIME  Eudora is the only significant remaining client lacking native S/MIME support Mulberry and Apple now include support along with some WebMail products  Qualcomm just released Eudora 6.1 Assumption is that they are now setting functionality goals for the next major release  Plan HEPKI-TAG to coordinate as many parties as possible to endorse a letter to Qualcomm requesting S/MIME supportletter

Wireless LAN Access Control EAP- MD5 LEAPEAP-TLSEAP- TTLS PEAP Server Authentic ation NonePassword Hash Public Key Supplicant Authentica tion Password Hash Public Key CHAP, PAP, MS-CHAP(v2), EAP Any EAP, like EAP-MS- CHAPv2 or Public Key Dynamic Key Delivery NoYes Security Risks Identity exposed, Dictionary attack, MitM attack, Session hijacking Identity exposed, Dictionary attack Identity exposed MitM attack Source: wi-fiplanet.com

EAP-TLS Process  User verifies the Radius server’s identity using PKI  The Radius server verifies the user’s identity using PKI  An authorization step may happen  Association is allowed and dynamic session keys are exchanged User Access Point Radius Server LDAP AuthZ

Support for EAP-TLS  Operating System Support Windows XP, Windows 2000 SP-4* MacOS (10.3.3) 3 rd party software available  Should be very easy to use No account management, passwords, etc AuthZ step makes it easy to keep hacked machines off of the WLAN *  base OS functionality only

EAP-TLS and the Microsoft Clients  Microsoft field in certificate for AuthN Subject Alt Name / Other Name / Principal Name  OID If not present, uses CN  Uniqueness issues for many CAs Easy to add to your certificate profile  Impact on the PKI-Lite certificate profiles Agreed to add this extension to EE cert profileprofile

Other Projects on the “List”  Some progress Update of S/MIME work Grid integration Bridge application testing  In the queue CA audit preparation & education Windows smart card login Update hardware token work Document and web form signing Updated survey of schools and applications Insert your item here

Campus Globus Implementations  The Globus toolkit uses PKI for authentication of users and resources A proxy certificate is used internally  A file maps certificates to login names  Campus CA integration is complicated by the Globus interface Campus CAs and OS-exported certificates are generally in PKCS-12 format Globus expects raw PEM files for the certificate and the private key

Implementing Globus on Campus  Certificate profile Standard profile (e.g. PKI-lite) works well with Globus  Use of Campus CA with Globus Different research groups on campus can share resources  Prepares for intercampus applications Campus CA part of a hierarchy Cross certification

NMI Testbed Globus Project Goals  Support the use of native campus CAs in Globus so that users can do all of their work using one set of credentials  Create some tools and documentation to make this easier with Globus  Scope intercampus Grid trust issues preparing to leverage other Higher Education PKI efforts Higher Education Bridge CA (HEBCA) US Higher Education Root CA (USHER)

Schematic of Grid Testbed PKI Integration Goal Campus E Grid A’s PKI Testbed Bridge CA Shibbolized Testbed CA Campus B Grid Campus C Grid Campus D Grid Campus A Grid Campus F Grid B’s PKI C’s PKI Cross-cert pairs User Certs

PKI Bridge Path Validation

Globus and Bridges  Initial Result: Globus appears to work with cross-certificates All needed cross certificates must be loaded into the /etc/grid-security/certificates directory No directory-based discovery for cross certificates as in many bridge environments It appears that the certificates for intermediate CAs in a hierarchy that is then bridged must also be preloaded It would be great if Globus could use the Authority Information Access field to dynamically find needed certificates

Globus and Bridges  2 nd phase testing Built “production” bridge for testbed  Dedicated laptop/openssl  Cross-certified UVa, UAB, USC, and TACC Results (so far)  Bridge path validation ok for EE certs  Server certificate validation not working via bridge  Bridge itself is fine; e.g. XP validates both directions More work in progress  Just installed latest NMI R5 Globus

NMI Testbed Project  In addition to building the testbed grid via cross- certification, we plan to explore a few tools Credential converter web site that takes a PKCS-12 (as is available in most enterprise CAs) and returns the PEM files needed by Globus A tool to chase down cross-certificates from AIA fields and build the needed Globus links and signing policy files Potentially a Shibboleth-based CA that could provide certificates for campuses that are not yet operating an enterprise CA

 Where to watch middleware.internet2.edu/hepki-tag  Links to other sites, CA software, etc PKI for Networked Higher Ed  pkidev.internet2.edu PKI Labs  middleware.internet2.edu/pkilabs middleware.internet2.edu/pkilabs References