The Profiles of the International Grid Trust Federation 2nd NetherNordic SLCS meeting, 16 December 2

1
The Profiles of the International Grid Trust
Federation2nd NetherNordic SLCS meeting, 16
December 2008
2
Outline

• A few words on the EUGridPMA and IGTF
• A Brief History and Background
• IGTF Structure
• Relying Party Requirements
• Authentication Profiles
• Common Elements
• Classic the traditional way of doing PKI
• Short Lived Credential Services (SLCS)
• Member Integrated credential services
  (MICS)long-lived certs derived from a
  membership database
• Accreditation Process and PMA expectations

3
Stakeholders in Grid Security

• Current grids are largely end-user centric
• Roles of a person in a (research) collaboration
  or community bears no relation to her role in the
  home org
• Grids today target researchers, not organisations
• But all users are in an organisation ... ...
  that can - and should - be leveraged!

4
Where to Ground Trust?

• There is no a priori trust relationship between
  grid members or member organisations
• Community (VO) life time can vary from days to
  decades
• people and resources are members of many Vos
• VOs can accept some responsibility, but are a
  bad source for identity as VO loyalty may be
  the wrong way(as far as resource providers are
  concerned)
• but relationship userVOresource is required
• for authorising access, traceability and
  liability, incident handling, and accounting
• so the grid needs trusted third parties

5
Authentication academia, industry, and

• Possible sources of authentication and identity
• National PKI
• in general uptake of 1999/93/EC and
  e-Identification is slow
• where available, a national PKI could be
  leveraged
• Several commercial providers
• main commercial drive today secure e-commerce
  based on SSL
• thus primary market is server authentication, not
  end-user identities
• are implicitly trusted by many
• because web browsers pre-install the roots of
  trust
• WebTrust seal of approval scope limited to a
  single Authority
• Academic Grid PKI today
• Provide end-user identities for secure mail and
  grid use
• generally provided by the NREN or national
  e-science project

6
A Federation Model for Grid Authentication
CA 2
CA 1
relying party n
CA n
CA 3
relying party 1

• A policy bridge federation of independent CAs
• Policy coordination based on common minimum
  requirements(not policy harmonisation)
• Acceptable for major relying parties in Grid
  Infrastructures
• No strict hierarchy with a single top nor a
  bridge CA as such
• spread liability and enable failure containment
  (better resilience)
• maximum leverage of national efforts and
  subsidiarity

7
From the Beginning the EU DataGrid CACG

• The EU DataGrid project in 2000 needed a PKI for
  AuthN
• Explicitly and deliberatly split complex AuthZ
  from AuthN
• Estalbih both end-user and server/service PKI
• CACG (David Kelsey) had the task of creating this
  PKI
• for grid Authentication only
• no support for long-term encryption or digital
  signatures
• Single CA was not considered acceptable
• Not a sustainable funding model, and single point
  of failure
• One CA per country, large region or international
  organization
• CA must maintain strong relationship with RAs and
  users
• Allows incorporation of pre-existing CAs
• A single hierarchy would have excluded existing
  CAs and was not possible to support with
  existing software
• Coordinated group of peer CAs was most suitable
  choice

History
8
Building the federation CA by CA

• Meet or exceed common set of minimum requirements
• Authorities compliant with minimum requirements
• Guidelines set jointly by relying parties (sites,
  projects) and authorities
• De-facto a single LoA as strongly requested by
  the RPs
• Different technologies lead to slightly different
  choices
• Peer-review process within the federation to
  evaluate members on entry
• Both peer-reviewed self-audits and on-site audits
• It must work! Its not a playground for
  theoretical concepts, but constraint by software
  that is actually deployed
• ultimate decision on trust always remains with
  RPs

9
Reasonable procedure acceptable methods

• Requirements and Best Practices for an
  acceptable and trustworthy Grid CA Minimum
  Requirements

History
10
Relying Party issues to be addressed

• Key characteristics of the request by our Major
  Relying Parties
• 1. standard accreditation profiles sufficient to
  assure approximate parity in CAs
• 2. monitor signing namespaces for name
  overlaps and issue unique names3. a forum
  to participate and raise issues4. operation
  of a secure collection point for information
  about CAs which you accredit5. common
  practices where possible
• (list courtesy of the Open Science Grid, backed
  (and to be extended) by EGEELCG)

11
EUGridPMA Membership

• EUGridPMA membership for (classic) Authorities
• a single Authority per
• country, large region or international treaty
  organization
• serve the largest possible community
  with a small
  number of stable CAs
• operated as a long-term commitment
• Relying Parties major e-Infrastructures or
  partner organisations
• DEISA, EGEE, SEE-GRID, TERENA,
• Many CAs are operated by the (national)
  NREN(CESNET, ESnet, Belnet, NIIF, EEnet, SWITCH,
  DFN, )
• or by the e-Science programme/Science
  Foundation(UK eScience, VL-e, CNRS, )

12
Growth of the European Grid trust fabric
History
13
International Grid Trust Federation
Green regular national CA accredited Yellow
accreditation in progress
14
Geographical coverage of the EUGridPMA

• 23 of 25 EU member states (all except LU, MT)
• AM, CH, HR, IL, IR, IS, MA, ME, MK, NO, PK, RO,
  RS, RU, TR, UA, SEE-GRID CA, CERN (int),
  DoEGrids(US)

• Pending or in progress
• BY, MD, SY, LV, ZA, SN

15
IGTF Status Today

• Already 77 accredited authorities
• EUGridPMA 41 countries 1 treaty organisation
• TAGPMA 6 countries (but several authorities in
  US and BR)
• APGridPMA 7 countries or economic regions
  (several authorities in CN, TW, JP)
• About 10 Major Relying Party members
• 6 in Europe DEISA, EGEE, LCG, OSG, SEE-GRID,
  TERENA
• PRAGMA, TeraGrid, OSG , LCG in other PMAs as well

16
Different technologies, different profiles

• The IGTF established a single trust fabric,
  incorporating authorities using different
  techniques

• Profiles
• Classic
• Real-time vetting(F2F or TTP)
• 13 months life time
• SLCS
• Existing IdM databases
• 100k 1Ms life time
• MICS
• IdM Federation
• 13 months max

• Common Elements
• Unique Subject Naming
• Identifier Association
• Publication IPR
• Contact andincident response
• Auditability

17
IGTF Federation Common Policy
IGTF Federation Document
trustrelations
SubjectNamespaceAssignment
DistributionNaming Conventions
Common Authentication Profiles
Classic(EUGridPMA)
SLCS(TAGPMA)
worldwide relying parties see a uniform IGTF
mesh
18
Guidelines common elements in the IGTF

• Coordinated namespace
• Subject names refer to a unique entity (person,
  host)Any single subject distinguished name (DN)
  in a certi ficate must be linked with one and
  only one entity for the whole lifetime of the
  service.
• Used as a basis (directly or indirectly) for
  authorization
• Common Naming
• Single distribution for all PMAs
• Concerns and incident handling
• Guaranteed point of contact, to raise issues and
  concerns
• Requirement for documentation of processes
• PMA-disclosed, detailed policy and practice
  statement
• Open to auditing by federation peers

19
Guidelines secured X.509 CAs

• Aimed at long-lived identity assertions
• Identity vetting procedures
• Based on (national) photo IDs
• Face-to-face verification of applicants via a
  network of Registration Authorities or Trusted
  Registrars
• Periodic renewal (once every year)
• Secured operation
• off-line signing key or HSM-backed on-line
  secured systems (140.2-3)
• Response to incidents
• Timely revocation of compromised certificates
• CRL issuance required (downloaded up to 400
  times/minute!)
• Last version 4.2, synchronised with Federation
  Document
• The Annotated Minimum Requirements are on the
  Wiki
• Continues to evolve

20
Guidelines short-lived credential service

• Issue short-lived credentialsbased on another
  authentication system
• e.g. Kerberos CA based, or existing (federated)
  administration
• on-line issuing (with 140.2 level 2 HSM or
  equivalent)
• Based on crypto-data held by the applicant
• Same EE cert format, but no new user-held secrets
• Can act like a proxy (RFC3820), and has similar
  risks
• The applicant can (and will) use it like a proxy
• Risk of EE key exposure is mitigated by its
  shorter life time
• Same common guidelines apply!
• reliable identity vetting to ensure uniqueness
  over CA life time

21
Specifics of a SLCS

• Sufficient information must be recorded and
  archived such that the association of the entity
  and the subject DN can be confirmed at a later
  date.
• Qualifying IdMs must suspend or revoke
  authorization to use the service if the
  traceability to the person is lost.
• The CP/CPS must describe
• How the identity (DN) assigned in the certificate
  is unique within the namespace of the issuer.
• How it attests to the validity of the identity.
• How the identity (DN) assigned in the certificate
  will never be re-issued to another end-entity
  during the entire lifetime of the CA.
• How it provides DN accountability, showing how
  they can verify enough identity information to
  trace back to the physical person for at least
  one year from the date of certification, and in
  keeping with audit retention requirements.
• In the event that documented traceability is
  lost, the DN must never be reissued.

22
MICS vs SLCS

• MICS is essentially a Classic CA, but with the
  identity vetting time-shifted off-loaded to
  federation or IdM which makes it look an awful
  lot like SLCS!
• But then
• The life time of the cert can be 13 months
• To off-set this risk
• The requirements on IdM access and -use are
  stronger
• Extra verification data is requested at issuance
  time to protect against weak or re-used IdM
  passwords
• Active revocation support required (in SLCS
  only re-active CRLs required)

23
New CAs the Accreditation Process

• Accreditation Guidelines for EUGridPMA
• Basic elements
• Codification of procedures in a CP(S) for each CA
• de facto lots of copy/paste, except for vetting
  and practice sections
• Peer-review process for evaluation
• comments welcomed from all PMA members
• two assigned referees
• In-person appearance during a review meeting
• Accreditation after remaining issues are
  addressed (by e-mail)
• Discussions are the most important, as many
  details are eithernot codified, and the PMA will
  assess a new CA on merit, not merely a piece of
  canonical text
• Periodic re-appearance and peer assessment of
  self-audits

24
Common Naming the Distribution

• Periodic, (monthly, max. biweekly) distribution
  of all trust anchors
• Common for the entire IGTF
• Includes all trust anchors for all
  profilesclassic, SLCS, experimental, but no
  overarching bundle
• Does not distinguished between accrediting PMAs
• Wide variety of formats
• RedHat Package Management (RPM) systemincluding
  a meta package with dependencies per profile
• tar archives per CA, ordered per profile
• Installation bundle suitable for ./configure
  make install
• Distributed update through chairs and registrars

25
Access to the Distribution Repository

• Web site https//dist.eugridpma.info/distribution/
  
• Mirrored by PMAs
• Web site with SCS cert
• PGP singed data
• Validation of contentvia TACAR
• RPs (and the IGTF) willmonitor your CA/CRL!

26
The Effect of being the IGTF Distribution

• Default installation by all users and relying
  parties in
• EGEE, DEISA, SEE-GRID, TeraGrid, Open Science
  Grid, EELA, PRAGMA, APGrid, NAREGI, wLCG,
• All users of the VDT distribution
• Virtually all European national e-Science
  programmes/NGIs
• And likely more, but in a PKI you dont see all
  relying parties (and I still get surprised at
  times )
• A lot of CRL downloads (indicating RPs)
• From over 14000 distinct IP addresses (from which
  at least 300 web caches proxying for even more
  nodes)
• 88452 downloads per day per CRL

27
Maintaining relationship with a PMA

• Periodic plenary meetings (EUGridPMA 3 per year)
• Attendance expected, and required at least once
  per year
• Expect contribution to the PMA operations, by
  helping out with peer reviews and assessments
• Meetings rotate through Europe (giving
  possibility for on-site audits of the hosting
  CA!)
• Evolution of the profiles (they are not cast in
  stone!)
• New policy and technical development
  discussions(e.g. 1SCPs, Robots, CSIRT-ops, AA
  Operations, Cred. Repos, CRL caching or OCSP, )
• IGTF Plenary Meetings during OGF workshops (3/yr)

28
APGridPMA http//www.apgridpma.org/EUGridPMA htt
p//www.eugridpma.org/TAGPMA http//www.tagpma.o
rg/IGTF http//www.igtf.net/