Embed Size (px)
Citation preview
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 Email (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
CACampus B
CA IUser
User
User
User
Campus A subCA 1
Device
User
Device
Campus A subCA 2
User
Campus B CA II
User
14
USHER Policy Authority
Jan Gossaert
•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
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
Dirck van Baburen, 1623
– 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
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
Cosimo Rosselli, 1481
• BECCAFUMI
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
1. The campus will operate its PKI using processes that are at least as strong as the management of its central accounts for email, calendaring, etc.
2. The campus may issue certificates only to entities normally affiliated with that campus.
3. The campus will not issue certificates intended or likely to confuse the Subject’s identity.
21
USHER Expected Practices (cont.)
4. The campus will actively maintain all services that it asserts in its certificates, e.g.,
– CRLs– Policy and practices, if Policy OID is present
5. The campus is strongly encouraged to develop and publish a CP and CPS. PKI Lite is available as a starting point.
6. 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.)
7. The campus will not issue certificates to third parties
– Instead, sponsor the other entity for USHER membership
8. The campus CA infrastructure and private key will be as securely protected as other major campus authentication components.
9. 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
Georges de La Tour, 1625
– CP is final!
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
• 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• http://pkidev.internet2.edu/rootcerts/
• “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 email, 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
Dept-1
Institution
Dept-1Dept-1
SubCA
CA
SubCASubCA SubCA
CA
SubCASubCA SubCA
CA
SubCASubCA
USHER
HEBCA
FBCA
CAUDIT PKI
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
• eAuthentication
• HSPD-12
• Related Initiatives
Federal 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
• 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 800- 7x)
HSPD-12
37
• 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
Related Federal Initiatives
38
• 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
Real Interoperability Initiatives
39
• 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
Outstanding Issues in Inter-domain Interoperability
40
• 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
Technology Standards Implications for Academe and Medicine
41
• 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.
Security and Online Services Implications for Academe and Medicine
42
Levels 1 &2 CSPs
Levels 3 &4 CSPs
-Banks-Universities-Agency Apps-Etc. Business Rules
CAF
Federal Agency PKIsOther Gov PKIsCommercial PKIs Bridges
FBCA
X-Certification
SAML Assertions
Digital Certificates
Levels 1 &2 OnlineApps & Services
Levels 3 &4 OnlineApps &Services
SDT
Digital Certificates
A Simplified View of E-AuthFederation Architecture
43
E-Auth Level 1
E-Auth Level 2
E-Auth Level 3
E-Auth Level 4
FPKI Rudimentary;C4
FPKI Medium/HW &Medium/HW-cbp
FPKI Basic
FPKI Medium & Medium-cbp
FPKI High (governments only)
44
• www.cio.gov/eauthentication
• http://csrc.nist.gov/pki
• www.cio.gov/ficc
• www.smartcardalliance.org
Fed Resources
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
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
EUGridPMA members and applicants
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
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)
General Membership• U. Hong Kong (China)• U. Hyderabad (India)• Osaka U. (Japan)• USM (Malaysia)
Map of the APGrid PMA
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– 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
ProposedInter-federations
FBCA
CA-1CA-2
CA-n
Cross-cert
HEBCADartmouth
Wisconsin
Texas
Univ-N
UVA
USHER
DSTACES
Cross-certs
SAFECertiPath
NIH
CA-1
CA-2 CA-3
CA-4
HE JP
AusCertCAUDIT PKI
CA-1
CA-2 CA-3HE BR
Cross-certs
OtherBridges
IGTF
C-4
FinanceSector
56
High
Medium Hardware CBP
Medium Software CBP
Basic
Rudimentary
C-4
High
Medium
Basic
Rudimentary
Foundation
Classic Ca
SLCS
MICS
FPKI
IGTF
HEBCA/USHER
Classic Strong
E-Auth Level 1
E-Auth Level 2
E-Auth Level 3
E-Auth Level 4
E-AUTH
