1. US Higher Education PKI (Scott Rea) Net@EDU February 2007

2. Protecting the Institution
Identity theft if the fastest growing crime in the US, Institutions of Higher Education are a prime target - 43% of this activity results from Campus compromises
There has been an exponential increase in the number of reported cases each year
UCLA just had the worst computer breach ever at a US university (800,000 people impacted) in December 2006
Dartmouth too has already had a security breach (back in 2004)
Protecting sensitive data with passwords is no longer sufficient – Two Factor Authentication is recommended
“While debate continues on what type of technology is best suited to prevent identity theft, many experts believe that a combination of PKI infrastructure and two-factor authentication offers the greatest promise of protection” [Financial Services Technology, Preventing Identity Theft]

3. Authentication Factors
Three Factors of Authentication:
Something you know
e.g. password, secret, URI, graphic
Something you have
e.g. key, token, smartcard, badge
Something you are
e.g. fingerprint, iris scan, face scan, signature

4. Authentication Factors
Single Factor of Authentication is most common
Passwords (something you know) are the most common single factor
At least Two Factor Authentication is recommended for securing important assets
e.g. ATM card + PIN (have + know)
2 x Single Factor Authentication ≠ Two Factor Authentication
e.g. Password + Graphic is NOT equivalent to Smartcard + PIN (although it may be better than a single instance of One Factor Authentication)
Without Two Factor Authentication, some secure communications may be vulnerable to disclosure
Especially in wireless networks

5. Password Authentication
General issues with Authentication using Password technology
Passwords easily shared with others (in violation of access policy)
Easily captured over a network if no encrypted channel used
Vulnerable to dictionary attacks even if encrypted channels are used
Weak passwords can be guessed or brute forced offline
Vulnerable to keyboard sniffing/logging attacks on public or compromised systems
Cannot provide non-repudiation since they generally require that the user be enrolled at the service provider, and so the service provider also knows the user's password
Vulnerable to Social Engineering attacks
Single factor of Authentication only

6. A Strong Solution to Password Vulnerabilities
Public Key Infrastructure (PKI)
PKI consists of a key pair – 1 public, stored in a certificate, 1 private, stored in a protected file or smartcard
Allows exchange of session secrets in a protected (encrypted) manner without disclosing private key
PKI lets users authenticate without giving their passwords away to the service that needs to authenticate them
Dartmouth’s own password-hunting experiences, written up in EDUCAUSE Quarterly, shows that users happily type their user ID and password into any reasonable-looking web site, because so many of them require it already.
PKI is a very effective measure against phishing

7. A Strong Solution to Password Vulnerabilities
Public Key Infrastructure (PKI)
PKI lets users directly authenticate across domains
Researchers can collaborate more easily
Students can easily access materials from other institutions providing broader educational opportunities
PKI allows decentralized handling of authorization
Students on a project can get access to a web site or some other resource because Prof Smith delegated it to them
PKI simplifies this process – no need for a centralized bureaucracy, lowers overheads associated with research
Private key is never sent across the wire so cannot be compromised by sniffing
Not vulnerable to dictionary attacks
Brute force is not practical for given key lengths
Facilitates encryption of sensitive data to protect it even if a data stream or source is captured by a malicious entity

8. A Strong Solution to Password Vulnerabilities
Public Key Infrastructure (PKI)
1024-bit keys are better than 128 character passwords (they are not subject to a limited character input set)
This is far stronger than any password based authentication
As one researcher said recently “the Sun will burn out before we break these”
Quote from Prof Smith: “In the long run: user authentication and authorization in the broader information infrastructure is a widely recognized grand challenge. The best bet will likely be some combination of PKI and user tokens.”
Failing to look ahead in our IT choices means failing in our research and educational mission.

9. Advantages of PKI What are the drivers for PKI in Higher Education?
Stronger authentication to resources and services of an institution
Better protection of digital assets from disclosure, theft, tampering, and destruction
More efficient workflow in distributed environments
Greater ability to collaborate and reliably communicate with colleagues and peers
Greater access (and more efficient access) to external resources
Facilitation of funding opportunities
Compliance

10. PKI Applications Potential Killer Apps for PKI in Higher Education
Secure/Private (S/MIME)
Paperless Office workflow (Digital Signatures)
Protection of sensitive data (EFS)
Strong SSO – VPN (IPSec), Wireless (EAP-TLS), & SSH authentication
Shibboleth/Federations
LionShare – P2P sharing application
GRID Computing Enabled for Federations
E-grants facilitation

11. US Higher Education PKI Initiatives
USHER – US Higher Education Root
Common set of policies or expected practices for a community of CAs operating under and subordinate to a common root CA
Sponsored by Internet2
HEBCA – Higher Education Bridge CA
Cross-certified CAs with mappings between their policies to determine equivalence
Sponsored by EDUCAUSE

12. USHER – Community Need Much discussion about our community
A replacement for the old CREN CA
Needs for a PKi trust mechanism
Quick convergence on a set of anticipated applications
Two-factor Credentialing
Web authentication
Electronic mail (S/MIME)
VPN (IPSec), Wireless (EAP-TLS), & SSH authentication
LionShare – P2P sharing application
Grid Authentication (Globus)
Digital Signatures

13. USHER PKI Certification Authority: A hierarchical root
USHER CA1
Campus A CA
Campus C CA
Campus B CA I
Campus A subCA 1
Campus A subCA 2
User
MACE & HEPKI TAG
User
User
Device
User
Campus B CA II
User
User
Device
User

14. USHER Policy Authority
Jim Jokl, University of Virginia, Chair
Michael Gettes, Duke
Mark Luker, EDUCAUSE
Barry Ribbeck, Rice
Jeff Schiller, MIT
Renee Shuey, Penn State
David Wasley, independent
Jan Gossaert

15. PA Defined Community Questions
What are the obstacles to PKI deployment in higher education?
What types of CAs do campuses operate?
What LoA do their practices support?
Formal documentation and audit?
What LoA should the overall system provide?
What type of agreement can a campus sign?
What are the potential liabilities to USHER, the PA, and the community?

16. Eventual Decision
Initially offer an USHER CA that minimizes campus-level requirements and leverages current campus best practices (PKi)
Later offer an USHER CA that enforces higher levels of assurance
Dirck van Baburen, 1623

17. USHER PKi Implementation & LoA
The USHER CA itself is operated at a strong level of assurance
Solid practices for protecting & operating CA
Strong process to identify designated campus officers via secure out-of-band communications
Campus LoA: as determined by the campus
PKI-Lite CP/CPS based systems expected to be common
Likely some stronger LoA PKIs too
Not imposed in USHER’s CP or Agreement
How to create a strong community?
Solution: detail expectations in a set of Expected Practices

18. BECCAFUMI
Cosimo Rosselli, 1481

19. USHER Expected Practices
When campuses join USHER, they are expected to adhere to the set of Expected Practices. If a campus cannot, expectation is either not to join or to leave.
Policy Authority does not audit or review campuses, but will take action if ever needed.

20. USHER Expected Practices
The campus will operate its PKI using processes that are at least as strong as the management of its central accounts for , calendaring, etc.
The campus may issue certificates only to entities normally affiliated with that campus.
The campus will not issue certificates intended or likely to confuse the Subject’s identity.

21. USHER Expected Practices (cont.)
The campus will actively maintain all services that it asserts in its certificates, e.g.,
CRLs
Policy and practices, if Policy OID is present
The campus is strongly encouraged to develop and publish a CP and CPS. PKI Lite is available as a starting point.
Delegation and multiple CAs are permissible
If it matches existing campus policy and the LoA of user identification is as strong as its other practices as mentioned in E.P.1.

22. USHER Expected Practices (cont.)
The campus will not issue certificates to third parties
Instead, sponsor the other entity for USHER membership
The campus CA infrastructure and private key will be as securely protected as other major campus authentication components.
In the event of key compromise, the campus CA will notify USHER as quickly as possible.

23. USHER Certificate Policies & Profiles
For the campus
PKI-Lite, developed by HEPKI-TAG, is likely a good solution. The campus decides.
For the USHER CA
Root and Campus certificate profiles are complete
CP…

24. CP is final!
Georges de La Tour, 1625

25. USHER: Current Status Key signing ceremony completed
A couple of authority certificates have been issued
Business components are approved and will leverage InCommon’s
Legal agreement
Registration Authority
Fees:
Initial I&A of trusted officers (700)
Annual Subscription (1000)
General availability: CPS, *very soon*

26. USHER: Some Q&A “Make-Install” CA project Eligibility
US Higher Education Institutions
Other entities sponsored by a US Higher Education member & approved by USHER PA
Will USHER be preloaded in browsers?
Not by default
Significant ongoing audit costs
Perhaps additional operational costs
Commercial server certificates are no longer expensive
A new root is not hard for your users to install
“Make-Install” CA project

27. LOA: Levels of Assurance
Not all CAs are created equal
Policies adhered to vary in detail and strength
Protection of private keys
Controls around private key operations
Separation of duties
Trustworthiness of Operators
Auditability
Authentication of end entities
Frequency of revocation updates

28. HEBCA : Higher Education Bridge Certificate Authority
Bridge Certificate Authority for US Higher Education
Modeled on FBCA
Provides cross-certification between the subscribing institution and the HEBCA root CA
Flexible policy implementations through the mapping process
The HEBCA root CA and infrastructure hosted at Dartmouth College
Facilitates inter-institutional trust between participating schools
Facilitates inter-federation trust between US Higher Education community and external entities

29. HEBCA What is the value presented by this initiative?
HEBCA facilitates a trust fabric across all of US Higher Education so that credentials issued by participating institutions can be used (and trusted) globally e.g. signed and/or encrypted , digitally signed documents (paperless office), etc can all be trusted inter-institutionally and not just intra-institutionally
Extensions to the Higher Education trust infrastructure into external federations is also possible and proof of concept work with the FBCA (via BCA cross-certification) has demonstrated this inter-federation trust extension
Single credential accepted globally
Potential for stronger authentication and possibly authorization of participants in grid based applications
Contributions provided to the Path Validation and Path Discovery development efforts

30. Solving Silos of Trust Institution FBCA Dept-1 Dept-1 Dept-1 HEBCA
CAUDIT
PKI
USHER CA CA CA
SubCA
SubCA
SubCA
SubCA
SubCA
SubCA
SubCA
SubCA
SubCA

31. HEBCA Project - Progress
What’s been done so far?
Operational Authority (OA) contractor engaged (Dartmouth PKI Lab)
MOA with commercial vendor for infrastructure hardware (Sun)
MOA with commercial vendor for CA software and licenses (RSA)
Policy Authority formed
Prototype HEBCA operational and cross-certified with the Prototype FBCA (new Prototype instantiated by HEBCA OA)
Prototype Registry of Directories (RoD) deployed at Dartmouth
Production HEBCA CP produced
Production HEBCA CPS produced
Preliminary Policy Mapping completed with FBCA
Test HEBCA CA deployed and cross-certified with the Prototype FBCA
Test HEBCA RoD deployed
Infrastructure has passed interoperability testing with FBCA

32. HEBCA Project - Progress
What’s been done so far?
Production HEBCA development phase complete
Issues Resolved
Discovery of a vulnerability in the protocol for indirect CRLs
Inexpensive AirGap
Citizenship requirements for Bridge-2-Bridge Interoperability
Majority of supporting documentation finalized
HEBCA Cross-Certification Criteria and Methodolgy
HEBCA Interoperability Guidelines
Draft Memorandum of Understanding
HEBCA Subscriber Agreement
HEBCA Certificate Profiles
HEBCA CRL Profiles
HEBCA Secure Personnel Selection Procedures
Business Continuity and Disaster Plans For HEBCA Operations
PKI Test Bed server instantiated
PKI Interoperability Pilot migrated
Reassessment of community needs
Audit process defined and Auditors engaged
Participation in industry working groups
Almost ready for audit and production operations

33. HEBCA Project – Next Steps
What are the next steps?
HEBCA to operate at multiple LOAs over its lifetime
Update of policy documents and procedures required to reflect the above
HEBCA to operate at Test LOA initially
Issue the limited production HEBCA Test Root
Purchase final items and bring the infrastructure online
Cross-certify limited community of interested early adopters and key federations
Validate the model and continue to develop tools for bridge aware applications

34. Federal Initiatives
eAuthentication
HSPD-12
Related Initiatives

35. Provide electronic identity authentication services for online government applications
Manage the Federal Federation (new) – extends services to private sector credential providers and online services
Set standards for assertion-based authentication tools
Federal PKI provides PKI-based services for higher assurance credentials

36. HSPD-12
A Presidential Mandate for Federal Agencies to issue medium assurance (or better) identity credentials for access to physical and logical government resources - inside-the-firewall contractors, too
Medium Hardware or High Assurance digital certificates on SmartCards
Fast-tracked for implementation starting 10/2006
Led to new government standards for identity proofing and vetting (FIPS 201) and for PKI hardware tokens (NIST SP x)

37. Related Federal Initiatives
HIPAA for electronic records management in health care
Other HHS-led and VA-led electronic healthcare initiatives (HL-7, etc.), some of which will require PKI implementations
DoD CAC access for various services
Navy & Marine extranet
Procurement
Grants & Research funding applications

38. Real Interoperability Initiatives
SAFE PKI Bridge and services – supporting digitally-signed electronic forms and document management
CertiPath – Federal Bridge cross-certification under way
inCommon – EAI interoperability initiative under way (Internet2 push; assertion-based technology, LOA 1 & 2) – demonstration projects with NSF
Financial Sector Bridge underway

39. Outstanding Issues in Inter-domain Interoperability
Liability for use of electronic identity credentials
Which “standards” to follow (exception: PKI IS interoperable)
Transitive trust, e.g., “if A trusts B and B trusts A and C, is there degradation of trust if A trusts C through B?”
Lots of niggling technical and policy disconnects

40. Technology Standards Implications for Academe and Medicine
US Government LOA, standardized risk analysis, standards for PIV cards and identity proofing and vetting are here and INEVITABLY will migrate everywhere
Pickup already noted in aerospace contractor space, homeland security

41. Security and Online Services Implications for Academe and Medicine
DHS first responders, DEA PKIs and CMS moves to online services and payments management will drive medical schools, hospitals and insurance chains to adopt Federal models for electronic identity authentication
Financial services firms under SEC regulation are already falling in line, both within and outside the eAuthentication federation participation
DEA issuing digital certs to pharmaceutical supply chain entities and plans to do so to service providers (MDs, PAs, NPs, etc.

42. A Simplified View of E-Auth Federation Architecture
-Banks
-Universities
-Agency Apps
-Etc.
Levels 1 &
2 Online
Apps &
Services
Levels 1 &
2 CSPs
SAML Assertions
Business Rules
CAF
SDT
Levels 3 &
4 Online
Apps &
Services
Levels 3 &
4 CSPs
Digital Certificates
Digital Certificates
X-Certification
FBCA
Federal Agency PKIs
Other Gov PKIs
Commercial PKIs
Bridges

43. FPKI High
(governments only)
E-Auth Level 4
FPKI Medium/HW &
Medium/HW-cbp
E-Auth Level 3
FPKI Medium &
Medium-cbp
E-Auth Level 2
FPKI Basic
E-Auth Level 1
FPKI Rudimentary; C4

44. Fed Resources www.cio.gov/eauthentication http://csrc.nist.gov/pki

45. International Grid Trust Federation
IGTF founded in Oct, 2005 at GGF 15
IGTF Purpose:
Manage authentication services for global computational grids via policy and procedures
IGTF goal:
harmonize and synchronize member PMAs policies to establish and maintain global trust relationships
IGTF members:
3 regional Policy Management Authorities
EUgridPMA
APgridPMA
TAGPMA
50+ CAs, 50,000+ credentials

46. IGTF

47. IGTF general Architecture
The member PMAs are responsible for accrediting authorities that issue identity assertions.
The IGTF maintains a set of authentication profiles (APs) that specify the policy and technical requirements for a class of identity assertions and assertion providers.
The management and continued evolution of an AP is assigned by the IGTF to a specific member PMA.
Proposed changes to an AP will be circulated by the chair of the PMA managing the AP to all chairs of the IGTF member PMAs.
Each of the PMAs will accredit credential-issuing authorities and document the accreditation policy and procedures.
Any changes to the policy and practices of a credential-issuing authority after accreditation will void the accreditation unless the changes have been approved by the accrediting PMA prior to their taking effect.

48. EUGridPMA members and applicants
Green: EMEA countries with an Accredited Authority
23 of 25 EU member states (all except LU, MT)
+ AM, CH, HR, IL, IS, NO, PK, RU, TR
Other Accredited Authorities:
DoEGrids (.us), GridCanada (.ca), CERN, SEE catch-all

49. EUgridPMA Membership
Under “Classic X.509 secured infrastructure” authorities
accredited: 38 (recent additions: CERN-IT/IS, SRCE)
active applicants: 4 (Serbia, Bulgaria, Romania, Morocco)
Under “SLCS”
accredited: 0
active applicants: 1 (SWITCH-aai)
Under MICS draft
none yet of course, but actually CERN-IS would be a good match for MICS as well
Major relying parties
EGEE, DEISA, SEE-GRID, LCG, TERENA

50. Map of the APGrid PMA General Membership U. Hong Kong (China)
U. Hyderabad (India)
Osaka U. (Japan)
USM (Malaysia)
Ex-officio Membership
APAC (Australia)
CNIC/SDG, IHEP (China)
AIST, KEK, NAREGI (Japan)
KISTI (Korea)
NGO (Singapore)
ASGCC, NCHC (Taiwan)
NECTEC, ThaiGrid (Thailand)
PRAGMA/UCSD (USA)

51. APgridPMA Membership 9 Accredited CAs In operation
AIST (Japan)
APAC (Australia)
ASGCC (Taiwan)
CNIC (China)
IHEP (China)
KEK (Japan)
NAREGI (Japan)
Will be in operation
NCHC (Taiwan)
NECTEC (Thailand)
1 CA under review
NGO (Singapore)
Will be re-accredited
KISTI (Korea)
Planning
PRAGMA (USA)
ThaiGrid (Thailand)
General membership
Osaka U. (Japan)
U. Hong Kong (China)
U. Hyderabad (India)
USM (Malaysia)

52. TAGPMA

53. TAGPMA Membership Accredited Relying Parties In Review Argentina UNLP
Brazilian Grid CA
CANARIE (Canada)*
DOEGrids*
EELA LA Catch all Grid CA
ESnet/DOE Office Science*
REUNA Chilean CA
TACC – Root
In Review
FNAL
Mexico UNAM
NCSA – Classic/SLCS
Purdue University
TACC – Classic/SLCS
Venezuela
Virginia
USHER
Relying Parties
Dartmouth/HEBCA
EELA
OSG
SDSC
SLAC
TeraGrid
TheGrid
LCG
*Accredited by EUgridPMA

54. TAGPMA Bridge Working Group
Recognition that there are different LOAs
in the way some credential service providers operate
Required by different applications
More efficient ways of distributing Trust Anchors
Interoperation with other trust federations
Scott Rea is Chair, representatives from each regional PMA included

55. Proposed Inter-federations CA-2 CA-1 HE BR AusCert CAUDIT PKI CA-n NIH
HE JP
FBCA
Cross-cert
Cross-certs
C-4
DST
ACES
Texas
Dartmouth
HEBCA
Cross-certs
IGTF
Wisconsin
UVA
Univ-N
USHER
CertiPath
SAFE
Finance
Sector
CA-4
Other
Bridges
CA-1
CA-2
CA-3

56. E-Auth Level 4 E-Auth Level 3 E-Auth Level 2 E-Auth Level 1
FPKI
E-Auth Level 4
High
HEBCA/USHER
Medium Hardware CBP
High
E-Auth Level 3
Medium Software CBP
Medium
Basic
Classic Strong
Basic
E-Auth Level 2
Rudimentary
Rudimentary
C-4
IGTF
Classic Ca
Foundation
E-Auth Level 1
SLCS
MICS

57. Questions
Scott Rea -