Transcript Short Lived Credential Services Profile

Short Lived
Credential Services
Profile
Tony J. Genovese
The Americas Grid PMA
DOEGrids
ATF/ESnet/LBNL
March 27, 2006
TAGPMA - Rio de Janeiro
1
SLCS Profile


The Authentication Profile is managed by
the TAGPMA
Derived from EUGridPMA Guidelines


Minimum Requirements version 4.0
Reviewed and approved by TAGPMA:

15 November 2005
March 27, 2006
TAGPMA - Rio de Janeiro
2
What is SLCS


Short-Term certificate has a life cycle less then 1 million
seconds (~11 days)
A translation of a local site’s native Identity to a Grid
Identity.


A KCA can translate a local Kerberos Identity
to a Grid Identity.
MyProxy can be integrated to some sites
Active credential repositories – different AuthN
profile.
Identity is validated by site security office
Leverages Site help desk and customer support
Possible local site service candidates:




Kerberos, Windows Domain, LDAP, One Time
Password and Long
term Certs.
March 27, 2006
TAGPMA - Rio de Janeiro

3
Document Identification
Document title: Profile for Short Lived Credential Services X.509 Public Key
Certification Authorities with secured infrastructure
Document vers: 1.1
Document date: November 15, 2005.
OID:
1.2.840.113612.5 = IGTF
OID:
IGTF.Policies.Authentication Profiles.SLCS.version
Document OID: 1.2.840.113612.5.2.3.1.1
Location:
March 27, 2006
http://www.tagpma.org/files/IGTF-AP-SLCS-20051115-1-1.pdf
TAGPMA - Rio de Janeiro
4
SLIC General Architecture
Sources of Identity
Grid Identity Mint
LDAP
AuthN
Short lived Grid
Identity/Proxy/Attribute
Certificates
slic
Kerberos
AuthN
slic
slic
slic
RADIUS
AuthN
slic
slic
Certificate Authority
SecureID
AuthN
(RADIUS)
Local Site AuthN infrastructure
March 27, 2006
TAGPMA - Rio de Janeiro
5
Identity


Every DN in a SLCS cert must be linked to
one and only one End Entity.
The DN owner is the human individual or
organizational group that has valid rights
to exclusive use of a subject name in a
certificate.
March 27, 2006
TAGPMA - Rio de Janeiro
6
Identity Translation rules



All identities used to create a Short Lived Certificate will
be based on the local Site/Organization identity system.
A SLCS must identify the Site/Organization identity
management service that will be used to provide the
authenticated identity to the SLCS.
A SLCS must describe in their CP/CPS:



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 it provides accountability, show that they have verified
enough identity information to get back to the physical person
any time now and in the future
March 27, 2006
TAGPMA - Rio de Janeiro
7
Operational Requirements



SLCS CA must be a dedicated machine
The CA must be located in a secure access
controlled environment.
CA’s private key must be protected:



FIPS 140-2 Level 3 HSM
Non-FIPS: Must describe the security
precautions.
CA Key >= 2048, lifetime <= 20 years
March 27, 2006
TAGPMA - Rio de Janeiro
8
Certificates and CRL profile





The accredited SLCS authority must publish a X.509 certificate as a root of trust.
SLCS CAs are not expected to issue CRLs.
The short lived certificates must be in X.509v3 format and compliant with
RFC3280 unless explicitly stated otherwise. In the certificate extensions:
 a Policy Identifier must be included and must contain an OID and an OID
only
 keyUsage must be included and marked as critical
 basicConstraints may be included, and when included it must be set to
‘CA: false’ and marked as critical so it conforms to general CA and ASN.1
practice.
 if an OCSP responder, operated as a production service by the issuing CA, is
available, AuthorityInfoAccess must be included and contain at least one
URI
If a commonName component is used as part of the subject DN, it should
contain an appropriate presentation of the actual name of the end-entity.
The message digests of the certificates must be generated by a trustworthy
mechanism, like SHA1 (in particular, MD5 must not be used).
March 27, 2006
TAGPMA - Rio de Janeiro
9
Revocation


It is assumed that the Short Lived Certificates will not
need to be revoked because their life time is shorter
than the update cycle of most CRLs.
If revocation is supported, then revocation requests can
be made by:


certificate holders, Site identity managers and the SLCS CA.
Others…
Individual holders of a SLCS certificate must request
revocation if the private key pertaining to the certificate
is lost or has been compromised, or if the data in the
certificate are no longer valid.
March 27, 2006
TAGPMA - Rio de Janeiro
10
Publication and Repository
responsibilities

Each SLCS authority must publish:







a SLCS CA root certificate or set of CA root certificates up to a
self-signed root;
a http or https URL of the PEM-formatted CA certificate;
a http or https URL of the web page of the CA for general
information;
the CP and CPS documents;
an official contact email address for inquiries and fault reporting
a physical postal contact address
The SLCS CA shall provide their trust anchor to a trust
anchor repository, specified by the accrediting PMA, via
the method specified in the policy of the trust anchor
repository.
March 27, 2006
TAGPMA - Rio de Janeiro
11
Audits





The SLCS CA must record and archive all requests for certificates,
along with all the issued certificates, all the requests for revocation
and the login/logout/reboot of the issuing machine.
The SLCS CA must keep these records for at least three years.
These records must be made available to external auditors in the
course of their work as auditor.
Each SLCS CA must accept being audited by other accredited CAs to
verify its compliance with the rules and procedures specified in its
CP/CPS document.
The SLCS CA should perform operational audits of the CA/RA staff at
least once per year. A list of CA and site identity management
personnel should be maintained and verified at least once per year.
The identity management system on which the SLCS CA relies
should undergo a periodic review or audit. This review should be
conducted by persons other than the system operators.
March 27, 2006
TAGPMA - Rio de Janeiro
12
SLCS Etcetera

Privacy and confidentiality


Compromise and Disaster recovery


Accredited SLCS CAs must define a privacy and data release
policy compliant with the relevant national legislation.
The SLCS CA must have an adequate compromise and disaster
recovery procedure, and be willing to discuss this procedure in
the TAGPMA. The procedure need not be disclosed in the policy
and practice statements.
Due diligence of subscribers

The SLCS CA should make a reasonable effort to make sure that
people realize the importance of properly protecting their private
data.
March 27, 2006
TAGPMA - Rio de Janeiro
13