Riccardo Gargana, INFN Roma Tre

1
Authentication and Authorization in gLite

• Riccardo Gargana, INFN Roma Tre

2
Grid security and trust

• Providers of resources (computers, databases,..)
  need risks to be controlled they are asked to
  trust users they do not know
• They trust a VO
• The VO trusts its members
• User needs
• single sign-on to be able to logon to a machine
  that can pass the users identity to other
  resources
• To trust owners of the resources they are using
• Build middleware on layer providing
• Authentication know who wants to use resource
• Authorization know what the user is allowed to
  do
• Security reduce vulnerability, e.g. from outside
  the firewall
• Non-repudiation knowing who did what
• The Grid Security Infrastructure middleware is
  the basis of (most) production grids

3
The Problems

• How does a user securely access the Resource
  without having an account on the machines in
  between or even on the Resource?
• How does the Resource know who a user is?
• Which resource can you access, and what are you
  allowed to do?
• Authentication how is identity of user/site
  communicated?
• Authorisation what can a user do?

4
RISK vulnerability

• Launch attacks to other sites
• Large distributed farms of machines, perfect for
  launching a Distributed Denial of Service attack.
• Illegal or inappropriate data distribution and
  access sensitive information
• Massive distributed storage capacity ideal for
  example, for exchange movies.
• Growing number of users have data that must be
  private biomedical imaging for example
• Damage caused by viruses, worms etc.
• Highly connected infrastructure means worms could
  spread faster than on the internet in general.

5
Basis of security (Public Key Algorithms)

• Every user has two keys one private and one
  public
• it is very difficult to derive the private key
  from the public one
• a message encrypted by one key can be decrypted
  only by the other one.
• Public keys are exchanged
• The sender cyphers using the public key of the
  receiver
• The receiver decrypts using his private key
• The number of keys is O(n)

The Public key Algorithms assure that only the
receiver can be able to understand the messages
and allows to create a secure channel between the
user.
6
Basis of security (Digital Signature)

• Paul calculates the hash of the message
• Paul encrypts the hash using his private key the
  encrypted hash is the digital signature.
• Paul sends the signed message to John.
• John calculates the hash of the message
• Decrypts signature, to get A, using Pauls
  public key.
• If hashes equal 1. message wasnt
• modified 2. hash A is from
  Pauls private key

Paul
message
Hash A
Digital Signature
Digital Signature allows to check the integrity
of the messages and the correspondence beetwen
the public key and the private key.
John
Pauls keys
Hash B
Hash A
public
private
7
Basis of security (Certification Authority)

• How can John be sure that Pauls public key is
  really Pauls public key and not someone elses?
• A third party certifies correspondence between
  the public key and Pauls identity.
• Both John and Paul trust this third party
• The third party is called a Certification
  Authority (CA).

Finally, the CA assure the correspondence
between the digital certificate and the
physical identity.
8
X.509 Certificates

• An X.509 Certificate contains
• owners public key
• identity of the owner
• info on the CA
• time of validity
• Serial number
• Optional extensions
• digital signature of the CA

9
The Grid Security Infrastructure (GSI)

• every Grid transaction is mutually authenticated
• Paul sends his certificate
• John verifies signature in Pauls certificate
  using CA public certificate
• John sends to Paul a challenge string
• Paul encrypts the challenge string with his
  private key
• Paul sends encrypted challenge to John
• John uses Pauls public key to decrypt the
  challenge.
• John compares the decrypted string with the
  original challenge
• If they match, John verified Pauls identity and
  Paul can not repudiate it.
• Repeat for Paul to verify Johns identity

JOHN
PAUL
Based on X.509 PKI
10
The Grid Security Infrastructure (GSI) - continued
Paul
After Paul and John uthenticated each other, for
Paul to send a message to John
John

• Default message integrity checking
• Not private a test for tampering
• For private communication
• Encrypt all the message (not just hash) - Slower

Message Encrypted hash
11
Certification Authorities

• Users identity has to be certified by one of the
  national Certification Authorities (CAs)
• Resources are also certified by CAs
• CAs are mutually recognized http//www.gridpma.org
  /
• Each CAs establish a number of people as
  registration authorities (RAs)
• The RA is a link in the chain of trust RA check
  the identity of the users on CA behalf

12
Certificate Request
User generatespublic/privatekey pair in browser.
After RA blessing, CA signature links identity
and public key in certificate. CA informs user.
CertRequest Public Key
User sends public key to CA and shows RA proof of
identity.
Certification Authority
Private Key encrypted on local disk
13
Your personal certificate

• Finally, everybody can have got a personal
  certificate signed by a CA. That certificate have
  one year of validity and identified yourself in
  to the grid and also in many different service
  provider on WWW. It s same to your passport,
  your ID card or your credit card in real life.

• Where do you put your personal certificate and
  your private key?

14
User Responsibilities

• Keep your private key secure on USB drive only
• Do not loan your certificate to anyone.
• Report to your local/regional contact if your
  certificate has been compromised.
• Do not launch a delegation service for longer
  than your current task needs.

If your certificate or delegated service is used
by someone other than you, it cannot be proven
that it was not you.
15
Proxy Certificate
To authenticate himself the user does not use its
own long living certificate ? Security problems
may arise.
GSI extension to X.509 Identity Certificates
X.509 Proxy Certificate
16
X.509 Proxy Certificate

• Proxy GSI extension to X.509 Identity
  Certificates
• signed by the normal end entity cert (or by
  another proxy).
• It enables single sign-on.
• It supports some important features
• Delegation
• Mutual authentication
• It has a limited lifetime (minimized risk of
  compromised credentials)
• It is created by the grid-proxy-init command
• grid-proxy-init
• Enter PEM pass phrase
• Options for grid-proxy-init
• -hours ltlifetime of credentialgt
• -bits ltlength of keygt
• -help

17
grid-proxy-init

• User enters pass phrase, which is used to decrypt
  private key.
• Private key is used to sign a proxy certificate
  with its own, new public/private key pair.
• Users private key not exposed after proxy has
  been signed

• Proxy placed in /tmp
• the private key of the Proxy is not encrypted
• stored in local file must be readable only by
  the owner
• proxy lifetime is short (typically 12 h) to
  minimize security risks.
• NOTE No network traffic!

18
Proxy again

• grid-proxy-init login to the Grid
• To logout you have to destroy your proxy
• grid-proxy-destroy
• This does NOT destroy any proxies that were
  delegated from this proxy.
• You cannot revoke a remote proxy
• To gather information about your proxy
• grid-proxy-info
• Options for grid-proxy-info-subject -issuer-t
  ype -timeleft-strength -help

19
Delegation

• Delegation remote creation of a (second level)
  proxy credential
• New key pair generated remotely on server
• Client signs proxy cert and returns it
• Allows remote process to authenticate on behalf
  of the user
• Remote process impersonates the user

20

• Proxy has limited lifetime (default is 12 h)
• Bad idea to have longer proxy
• However, a grid task might need to use a proxy
  for much longer time
• Grid jobs in HEP on LCG last up to 2 days
• myproxy server
• Allows to create and store a long term proxy
  certificate
• myproxy-init -s lthost_namegt
• -s lthost_namegt specifies the hostname of the
  myproxy server
• myproxy-info
• Get information about stored long living proxy
• myproxy-get-delegation
• Get a new proxy from the MyProxy server
• myproxy-destroy
• Check out the myproxy-xxx --help option for more
  information
• A dedicated service on the RB can renew
  automatically the proxy
• File transfer services in gLite validates user
  request and eventually renew proxies
• contacting myproxy server

Long term proxy --gt Myproxy
21
Grid authentication with MyProxy
WS
UI PnP
I
n
s
t
a
l
l
Job Run
Job Done
22
Coffee break
23
VOs and authorization

• Grid users MUST belong to virtual organizations
• It was called groups previously.
• It defines sets of users belonging to a
  collaboration
• User must sign the usage guidelines for the VO
• You will be registered in the VO-LDAP server
  (wait for notification)
• List of supported VOs
• https//lcg-registrar.cern.ch/virtual_organization
  .html
• VOs maintain a list of their members on a LDAP
  Server
• The list is downloaded by grid machines to map
  user certificate subjects to local pool
  accounts
• Sites decide which VOs to support
• /etc/grid-security/grid-mapfile

Absolete
"/CCH/OCERN/OUGRID/CNSimone Campana 7461"
.dteam "/CCH/OCERN/OUGRID/CNAndrea Sciaba
8968" .cms "/CCH/OCERN/OUGRID/CNPatricia
Mendez Lorenzo-ALICE" .alice
24
VOMS concepts

• Virtual Organization Membership Service (VOMS) is
  a service that keeps track of the members of a VO
  and grants them a set of attributes, that get
  included in the users proxy certificate at proxy
  creation time.

25
VOMS concepts-2

• Virtual Organization Membership Service
• Extends the proxy with info on VO membership,
  group, roles
• Fully compatible with the software of
  authetication (Globus Toolkit)
• Each VO has a database containing group
  membership, roles and capabilities information
  for each user
• User contacts voms server requesting his
  authorization info
• Server sends authorization info to the client,
  which includes them in a proxy certificate

glite-tutor /home/garganagt voms-proxy-init
--voms gilda Cannot find file or dir
/home/gargana/.glite/vomses Your identity
/CIT/OGILDA/OUPersonal Certificate/LINFN-ROMA3
/CNRiccardo Gargana/Emailgargana_at_roma3.infn.it E
nter GRID pass phrase Your proxy is valid until
Mon Jan 30 233551 2006 Creating temporary
proxy.................................Done Contact
ing voms.ct.infn.it15001 /CIT/OGILDA/OUHost/
LINFN Catania/CNvoms.ct.infn.it/Emailemidio.gio
rgio_at_ct.infn.it "gilda" Creating proxy
...................................... Done Your
proxy is valid until Mon Jan 30 233551 2006
26
FQAN and AC

• FQAN short for Fully Qualified Attribute Name, is
  what VOMS uses to express membership and other
  authorization info
• Groups membership, roles and capabilities may be
  expressed in a format that bounds them
  togetherltgroupgt/Roleltrolegt/Capabilityltcapabi
  litygt
• FQAN are included in an Attribute Certificate
• Attribute Certificates are used to bind a set of
  attributes (like membership, roles, authorization
  info etc) with an identity
• ACs are digitally signed
• VOMS uses AC to include the attributes of a user
  in a proxy certificate

• glite-tutor /home/gargana gt voms-proxy-info
  -fqan
• /gilda/RoleNULL/CapabilityNULL
• /gilda/tutors/RoleNULL/CapabilityNULL

27
VOMS and AC

• Server creates and signs an AC containing the
  FQAN requested by the user, if applicable
• AC is included by the client in a well-defined,
  non critical, extension assuring compatibility
  with GT-based mechanism

/home/gargana gt voms-proxy-info -all subject
/CIT/OGILDA/OUPersonal Certificate/LINFN-ROMA3
/CNRiccardo Gargana/Emailriccardo.gargana_at_roma3.
infn.it/CNproxy issuer /CIT/OGILDA/OUPers
onal Certificate/LINFN-ROMA3/CNRiccardo
Gargana/Emailgargana_at_roma3.infn.it identity
/CIT/OGILDA/OUPersonal Certificate/LINFN-ROMA3
/CNRiccardo Gargana/Emailgargana_at_roma3.infn.it t
ype proxy strength 512 bits path
/tmp/x509up_u513 timeleft 115952 VO
gilda extension information VO
gilda subject /CIT/OGILDA/OUPersonal
Certificate/LINFN-ROMA3/CNRiccardo
Gargana/Emailgargana_at_roma3.infn.it issuer
/CIT/OGILDA/OUHost/LINFN Catania/CNvoms.ct.in
fn.it/Emailemidio.giorgio_at_ct.infn.it attribute
/gilda/tutors/RoleNULL/CapabilityNULL attribute
/gilda/RoleNULL/CapabilityNULL timeleft
115945
Standard globus attributes
Voms extensions
28
Evolution of VO management

• Before VOMS
• User is authorised as a member of a single VO
• All VO members have same rights
• Gridmapfiles are updated by VO management
  software map the users DN to a local account
• grid-proxy-init

• VOMS
• User can be in multiple VOs
• Aggregate rights
• VO can have groups
• Different rights for each
• Different groups of experimentalists
• Nested groups
• VO has roles
• Assigned to specific purposes
• E,g. system admin
• When assume this role
• Proxy certificate carries the additional
  attributes
• voms-proxy-init

VOMS now in use on EGEE grid
29
Summary of AA - 1

• Authentication based on X.509 PKI infrastructure
• Trust between Certificate Authorities (CA) and
  sites, CAs and users is established (offline)
• CAs issue (long lived) certificates identifying
  sites and individuals (much like a passport)
• Commonly used in web browsers to authenticate to
  sites
• In order to reduce vulnerability, on the Grid
  user identification is done by using (short
  lived) proxies of their certificates
• Proxies can
• Be delegated to a service such that it can act on
  the users behalf
• Include additional attributes (like VO
  information via the VO Membership Service VOMS)
• Be stored in an external proxy store (MyProxy)
• Be renewed (in case they are about to expire)

30

• User certificate files
• Certificate X509_USER_CERT
• (default HOME/.globus/usercert.pem)
• Private key X509_USER_KEY
• (default HOME/.globus/userkey.pem)
• Proxy X509_USER_PROXY
• (default /tmp/x509up_ultidgt)
• Host certificate files
• Certificate X509_HOST_CERT
• (default /etc/grid-security/hostcert.pem)
• Private key X509_HOST_KEY
• (default /etc/grid-security/hostkey.pem)

GSI environment variables
31
GSI environment variables

• Trusted certification authority certificates
• X509_CERT_DIR
• (default /etc/grid-security/certificates)
• Voms server public keys
• X509_VOMS_DIR
• (default /etc/grid-security/vomsdir)

32
References

• Grid
• LCG Security http//proj-lcg-security.web.cern.ch
  /proj-lcg-security/
• LCG Registration http//lcg-registrar.cern.ch/
• Globus Security http//www.globus.org/security/
• VOMS http//infnforge.cnaf.infn.it/projects/voms
• IGTF for trusted CAs http//www.gridpma.org/
• Background
• GGF Security http//www.gridforum.org/security/
• IETF PKIX charter http//www.ietf.org/html.charte
  rs/pkix-charter.html
• PKCS http//www.rsasecurity.com/rsalabs/pkcs/inde
  x.html

33
Questions
?