Zeepkist Jens Jensen STFC SurfNet, Utrecht, 24-26 Jan 2011.

Slides:



Advertisements
Similar presentations
EGEE-II INFSO-RI Enabling Grids for E-sciencE EGEE and gLite are registered trademarks MyProxy and EGEE Ludek Matyska and Daniel.
Advertisements

Robots Jens Jensen, STFC RAL GridNet2/ UK e-Science CA /NGS/GridPP/
Private Key Protection. Whats it about Without the private key, the certificate is useless One of two main purposes of cert: –Prove possession of private.
Experiences with Massive PKI Deployment and Usage Daniel Kouřil, Michal Procházka Masaryk University & CESNET Security and Protection of Information 2009.
Chapter 7: Key Process Areas for Level 2: Repeatable - Arvind Kabir Yateesh.
Identity Standards (Federal Bridge Certification Authority – Certificate Lifecycle) Oct,
David Groep Nikhef Amsterdam PDP & Grid Evolving Assurance – IGTF LoA generalisation David Groep Interoperable Global Trust Federation IGTF Documents at.
Sponsored by the National Science Foundation GENI Clearinghouse Panel GEC 12 Nov. 2, 2011 INSERT PROJECT REVIEW DATE.
Public Key Infrastructure (PKI) Providing secure communications and authentication over an open network.
E-Procurement: Digital Signatures and Role of Certifying Authorities Jagdeep S. Kochar CEO, (n)Code Solutions.
\ Grid Security and Authentication1. David Groep Physics Data Processing group Nikhef.
Creating a Secured and Trusted Information Sphere in Different Markets Giuseppe Contino.
Copyright © Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE CSci530: Computer Security Systems Authentication.
Controller of Certifying Authorities Public Key Infrastructure for Digital Signatures under the IT Act, 2000 : Framework & status Mrs Debjani Nag Deputy.
Digital Signature Technologies & Applications Ed Jensen Fall 2013.
Introduction to Secure Messaging The Open Group Messaging Forum April 30, 2003.
Tweaking the Certificate Lifecycle for the UK eScience CA John Kewley NGS Support Centre Manager & Service Manager for the UK e-Science CA
NENA Development Conference | October 2014 | Orlando, Florida Security Certificates Between i3 ESInet’s and FE’s Nate Wilcox Emergicom, LLC Brian Rosen.
On Robots J Jensen STFC Rutherford Appleton Lab OGF 20, Manchester, May 2007.
+1 (801) Standards for Registration Practices Statements IGTF Considerations.
Chapter 23 Internet Authentication Applications Kerberos Overview Initially developed at MIT Software utility available in both the public domain and.
March 27, 2006TAGPMA - Rio de Janeiro1 Short Lived Credential Services Profile Tony J. Genovese The Americas Grid PMA DOEGridsATF/ESnet/LBNL.
National Institute of Advanced Industrial Science and Technology Brief status report of AIST GRID CA APGridPMA Singapore September 16 Yoshio.
NECTEC-GOC CA Self Audit 7 th APGrid PMA Face-to-Face meeting March 8 th, 2010 Large-Scale Simulation Research Laboratory Sornthep Vannarat Large-Scale.
Revocation in MICS §4.4 May 11-13, 2009 Zürich, Switzerland.
Ning Zhang, the University of Manchester, UK David Groep, National Institute for Nuclear and High Energy Physics, NL Blair Dillaway, OGF Security Area.
Lecture 13 Page 1 Advanced Network Security Authentication and Authorization in Local Networks Advanced Network Security Peter Reiher August, 2014.
Public Key Infrastructure (X509 PKI) Presented by : Ali Fanian
Profile for Portal-based Credential Services (POCS) Yoshio Tanaka International Grid Trust Federation APGrid PMA AIST.
HEPSYSMAN UCL, 26 Nov 2002Jens G Jensen, CLRC/RAL UK e-Science Certification Authority Status and Deployment.
© 2003 The MITRE Corporation. All rights reserved For Internal MITRE Use Addressing ISO-RTO e-MARC Concerns: Clarifications and Ramifications Response.
Who’s watching your network The Certificate Authority In a Public Key Infrastructure, the CA component is responsible for issuing certificates. A certificate.
“Trust me …” Policy and Practices in PKI David L. Wasley Fall 2006 PKI Workshop.
National Institute of Advanced Industrial Science and Technology Some topics from the OGF20 and the EUGrid PMA F2F Meeting Yoshio Tanaka Grid Technology.
IOTA AP Towards Differentiated Identity Assurance David Groep, Nikhef supported by the Netherlands e-Infrastructure and SURFsara.
Bridge Certification Architecture A Brief Overview by Tim Sigmon May, 2000.
X.509 Proxy Certificates for Dynamic Delegation Ian Foster, Jarek Gawor, Carl Kesselman, Sam Meder, Olle Mulmo, Laura Perlman, Frank Siebenlist, Steven.
On Robots J Jensen STFC Rutherford Appleton Lab Banff, July 2007.
Security Vulnerability Identification and Reduction Linda Cornwal, JRA1, Brno 20 th June 2005
NECTEC-GOC CA The 3 rd APGrid PMA face-to-face meeting. June, Suriya U-ruekolan National Electronics and Computer Technology Center, Thailand.
Security Policy Update WLCG GDB CERN, 14 May 2008 David Kelsey STFC/RAL
8-Mar-01D.P.Kelsey, Certificates, WP6, Amsterdam1 WP6: Certificates for DataGrid Testbeds David Kelsey CLRC/RAL, UK
12-Jun-03D.P.Kelsey, CA meeting1 CA meeting Minimum Requirements CERN, 12 June 2003 David Kelsey CCLRC/RAL, UK
MICS Authentication Profile Maintenance & Update Presented for review and discussion to the TAGPMA On 1May09 by Marg Murray.
7-May-03D.P.Kelsey, LCG-GDB-Security1 LCG/GDB Security Issues and Planning or Report from the Security Group CERN, 8 May 2003 David Kelsey CCLRC/RAL, UK.
Jens’ Soapbox J Jensen Rutherford Appleton Laboratory Berlin, Sep 2009.
TR-GRID CA Self-Auditing Results and Status Update EUGridPMA Meeting September 12-14, 2011 Marrakesh Feyza Eryol, Onur Temizsoylu TUBITAK-ULAKBIM
Content Introduction History What is Digital Signature Why Digital Signature Basic Requirements How the Technology Works Approaches.
Jens’ N th soapbox Can’t be a PMA without a Soapbox Jens Jensen, RAL EU GridPMA, Switch, Zürich, May 2009.
Security and Delegation The Certificate Perspective Jens Jensen Rutherford Appleton Laboratory Workshop at NIKHEF, 27 April 2010.
18 th EUGridPMA, Dublin / SRCE CA Self Audit SRCE CA Self Audit Emir Imamagić SRCE Croatia.
A Survey of Certificate Management Processes and Procedures in OSG Gabriel Ghinita and Mine Altunay
Jens' obligatory soap box Can't be a PMA without a SoapBox A random collection of Soapy things Nicosia, Jan 2009.
EGI-InSPIRE RI EGI (IGTF Liaison Function) EGI-InSPIRE RI IGTF & EUGridPMA status update SHA-2 – and more (David Groep,
UGRID CA Self-audit report Sergii Stirenko 21 st EUGRIDPMA Meeting Utrecht 24 January 2011.
HellasGrid CA self Audit. In general We do operations well Our policy documents need work (mostly to make the text clearer in a few sections) 2.
Soapbox (S Series) Who, what, where, why, how Rome Soapbox, Jan 2013 Jens Jensen, Chief Soapbox Officer.
News from EUGridPMA EGI OMB, 22 Jan 2013 David Kelsey (STFC) Using notes from David Groep 22/01/20131EUGridPMA News.
29 th EUGridPMA meeting, September 2013, Bucharest AEGIS Certification Authority Dušan Radovanović University of Belgrade Computer Centre.
Soapbox (S-Series) Certificate Validation Jens Jensen, STFC.
EGI-InSPIRE RI EGI-InSPIRE EGI-InSPIRE RI D4.4 and the EGI review Dr Linda Cornwall 19 th Sept 2011 D4.41.
EU GridPMA meeting Dublin, January 2010
TAG Presentation 18th May 2004 Paul Butler
J Jensen, STFC Chief Soapbox Officer 23 May 2017
AEGIS Certification Authority
Jens Jensen, STFC Sep EUGridPMA Manchester
TAG Presentation 18th May 2004 Paul Butler
Tweaking the Certificate Lifecycle for the UK eScience CA
Grid Security M. Jouvin / C. Loomis (LAL-Orsay)
Appropriate Access InCommon Identity Assurance Profiles
Presentation transcript:

Zeepkist Jens Jensen STFC SurfNet, Utrecht, Jan 2011

Contents of the Talk Compliance Level of Assurance The Warm and Fuzzy –W&F appears in every talk! Private key protection (as example)

Quote of the Day "Errors really aren't all that serious and you should be allowed to, like, chill man and just groove with the heavy consequences, dude." --Damian Conway in Exegesis 4 (p. 3) [very much taken out of context!]

Quote of the Yesterday “Must comply with the requirements” “… or we devalue the whole thing”

Compliance with What? IGTF, PKIX, X.509 PKIX > X.509 –E.g. single-set RDNs IGTF > PKIX –E.g. printableString names APs, GFD.125, minreq

Changing a CA Compliance Non-Compliance Level of Assurance Warm and Fuzzy High Low Warm Cold

Changes Compliance is better than non- compliance Higher LoA is better than lower ? –Up to a point? Warmer and fuzzier is better –Right?

Changes Self-reviewed, in a sense –If you build it, you review it (sort of) The role of reviewers –Post-change assessment –Pre-change assessment? What if changes are hidden?

Change Approval Survival of the noisiest –Silent acquiescence Just vote yes Just do it

Change Management (IT) Project Management –Planning, resources, etc –Depending on size of change People –DREC –And the curse of DREC

“Trust No-One” Can you trust X to run a CA? Assessor –Relationship and independence (cf RFC ) –Qualifications (8.2) Can you trust yourself…? Audited *anything* is more trusted –Particularly by a trusted auditor

How much do we need to trust you to trust no-one? Small stuff: can decide for yourself –Eg repository publications Bigger stuff: need advice if unsure –Eg cert extensions Even bigger: probably need advice –CP/CPS update, CA software Biggest: advice from group of experts –Initial accreditation

Non-Compliance A: actually it is probably OK B: really ought to fix eventually C: fix at next given opportunity D: fix sooner than that “In case of non-compliance, the CA manager must announce plan for addressing the issue.” (or similar)

The Scale of Cs How serious is non-compliance? –E.g. 393 days vs 395 days (Reimer) –RFC3647 vs RFC2527 Assessor and reviewer often disagree –Not always A>R, sometimes A<R –Implications for normal operations?

The Role of Understanding Understanding stuff takes time Insights take even more time Toxicity of RFC2119 SHOULD –IGTF-SHOULD is healthier –Consequences are bounced off the PMA

A Deo Rex, A Rege Lex Where do changes come from? Who can request a change? Can they request change for any reason?

Change happens, too Cold and distinct

Change happens, too Technology and related –Eg hardware tokens RP reqs –Compare global requirements with national –Biomed with physics

Change happens, too Boo boos –Fixing mistakes –Embarrassing, but necessary The “??”

Change Change is good –The world is not static –We need to move with it Change is bad –Difficult to implement globally 6 months unrealistic –Babies and bathwater

Change What are babies and bathwater? –Losing something we had But may not have known we had? –“Oops legislation” Not understanding consequences Not grokking the issues

From Istanbul (Soapbox) 1.Protection of private key 2.Validated parts of the DN 3.Security of identity vetting 4.Types of auditing (frequency, thoroughness) 5.Purpose of certificate 6.Protection of (CA) infrastructure

The LoA

Understanding the risks and impact Compliance with law etc Federations Dependence on technology Independence of technology The role of technology The role of usability

Identity Vetting 1.Maintain uniqueness of DN –Resolve name clashes –Affirm links to previous names 2.Auditable records of issuance 3.Maintained within scope of CA (eg DPA) 4.Maintain fully traceable links to user –Provide potentially legally binding docs

Goodenoughism Authenticating people at CERN –Initial –And re-authenticating Setting up RA at JAC… –Even if members of STFC

Identity Vetting “but I know the user personally” –Loss of auditable records “I know someone who can verify the user” –No formal links to CA

Maintenance of Links Continuous or regular (eg at rekey) Auditable verifications

The Private Key What is is? –Something you have –Something you know What it is for? –Proving that you have it –Without revealing information about it (ZK)

What problem? Users: certificates difficult to manage Slightly clunky key changeover? (rekey) –Renewal also clunky, for different reasons (But not with the cert wizard!) –MyProxy integration should ensure freq.

What is the solution? (Further than Jim B’s proposal) Remove key handling from users? Do not use X.509? –Other ZK? Probably don’t need ZK if key prot’n strong –Other two-factor? Still need two factor –Or we lower the LoA

Goodenoughism example 1 year proxies in MyProxy –Escape the eeevil clutches of the CA –Now cannot revoke the credential –Trouble at rekey, original p’key needed

What is Key Handling? 1.Generation of key 2.Delivery (-ies) 3.Storage (in protected form) 4.Activation 5.Deactivation 6.Destruction Auditable Audited

What is the problem with managing keys? 1.Key generation => provable 2.Key delivery => N/A 3.Key activation => single factor 4.Who can run a repository? 5.Purpose of certificate –Authentication vs digsig and nonrep

Do constrained envs help? Grids require: –Authentication –Digital signatures Grids do not require: –Anything else Normally

The Private Key Protection Problem Support existing purposes Maintain the LoA –Or increase the LoA –Need two factor authentication (tokens) Can the problem be solved? –Maybe –Does need careful thinking and review

The Private Key Protection Non-Problem Accept a formally different (lower) LoA RPs will take it anyway, they take anything :-P

The Repository Question Repository for proxies Or private keys Distinction: –Lifetime of credential –Revocability of credential

Who can run a repository? The CA? The infrastructure provider? The security chappie for a project? The student, under the desk? Probably similar to req’s for running AA

Who can run a repository? Locally (ie user generated) –Users own key, only Home organisation “Third party” –Not the CA, surely CAs MUST not generate keys for users(?)

Final slide (no really) A conclusion of sorts –Anthropology: CAs are people too –Quixotic quest against goodenoughism? Canwedobetterism –At the end, not so worried about lack of understanding –Worried about the silent majority?