retreat talk

Robert Olson olson at mcs.anl.gov
Thu May 20 17:32:55 CDT 2004


Well, they're not slides yet ...

my notes on what I wanted to talk about kept growing, and have turned into 
the following document. I plan on turning them into slides tomorrow; 
consider this an expanded outline. If we want, it can be polished a bit and 
included in the proceedings instead of or in addition to the slides - would 
likely be more useful to folks. In any event, this is what I plan on 
talking about.'

--bob

---------------------------------------

Security and the Access Grid

A major goal of the AG2.x project is to provide a solid foundation of
secure communication on which interesting tools and applications can
be constructed.

An essential component in this foundation is the facility for reliable
authentication of the communicating parties, whether they may be
people, their agents, or independent services or devices.

Any authentication system will include the following five elements
[ref auth book]

Person, principal, entity

Distinguishing characteristic

Proprietor

Authentication mechanism

Access control mechanism

The AG currently uses a public-key infrastructure-based architecture
for authentication. In such a system, the distinguishing
characteristic for an entity is the public key of a PKI keypair (held
in an X509 identity certificate). The authentication mechansim is the
software implementing the certificate validation algorithms, making
use of public-key cryptography.

PKI History

The first common use of PKI in the internet world was with the advent
of websites secured for electronic commerce. Users need to be assured
that the website they are visiting is really that of the merchant they
think they are visiting, and their credit card information is not
stolen enroute to the merchant.

This level of security is obtained by the web server holding an
identity certificate, signed by a certificate authority. The web
browser engages in a protocol exchange (the SSL handshake) with the
server, which presents its certificate in a way that the client can
determine that the server holds the private key associated with the
certificate in the public key. The client also knows which certificate
authority signed the server's certificate; clients are distributed
with a number of certificate authorities' own identity certificates
built in, and can use these certificates to validate the server's
certificate.

When the SSL handshake is complete, the client and server have also
created a secure communications channel, over which further messages
are sent. This is the mechanism by which the private data (the credit
card number in the example above) are kept private.

Communications between clients and servers in the Access Grid proceed
in much the same way, except that the client also presents a
certificate to the server, which has the ability to decide if the
client is indeed whom it claims to be. This process is called mutual
authentication.

It is important to note that the private key, held by each party in a
mutual authentication exchange, is critical: if the private key is
exposed, anyone holding that key can masquerade as the party
identified by the certificate bound to the private key.

Hence it is important that mechanisms be provided that keep the
private key private. For keys identifying people, it is common to hold
the private key encrypted on its storage mechanism, and for the user
to present a password to decrypt the private key each time it is
used. For keys identifying services, it is common to leave the private
key unencrypted, but to use other means to keep the key private -
filesystem permissions, physical security on the system hosting the
service, etc.

It can be inconvenient for a user to provide the encryption password
for his private key each time it is to be used. In order to alleviate
this problem, we make use of proxy certificates. A proxy certificate
(or proxy) is a certificate that has been signed by an identity
certificate (a process that unfortunately violates the strict X509
rules on certificate management; however, work is underway to
standardize the format and use of proxy certificates). The proxy is
kept without a passphrase. The risk of a proxy certificate being
compromised is mitigated by the proxy having a limited lifetime
(typically in the hours or small number of days), and by it being
limited in what access it allows its holder.

Validation

Before I discuss the use of PKI in the AG in more detail, I wish to
discuss the process of certificate validation. It is possible for
anyone to create a CA certificate, create identity certificates signed
by that CA certificate, and attempt to use them. It is the certificate
validation process that provides real meaning to a PKI.

The validation process can be thought of as a series of questions. If
any of these are answered "no", the validation has failed. In the
actual implementation, the order and means by which the questions are
asked and answered may differ from the order presented below.

1. Was the certificate issued by a certificate authority that I trust?

The validating process will check the digital signature on the
presented certificate against the public key kept in its store of
trusted CA certificates. If it does not match, or if the certificate
was issued by a CA for which there is no local certificate, the
validation fails.

2. Is the certificate currently valid?

Each certificate contains a time before which the certificate is
invalid, and a time after which the certificate is invalid.  Unless the
current time falls between these two times, the validation fails.

3. Does the entity presenting the certificate hold the private key for
    the certificate?

The process presenting the certificate must present proof that it
holds the private key corresponding to the certificate. This is
typically accomplished by the presenting process encrypting a challenge
(a random string) using its private key. The validating process can
verify that the encrypted string matches the public key in the certificate.

Certificate Chains

It is possible for there to be a series of CA certificates for a
particular identity certificate; each CA certificate in the chain
issued and signed by the CA certificate above it in the chain. At the
top of the chain is the root CA certificate, which is self-signed.

In this case, the CA certificate validation process (item 1 above) is
performed once for each link of the chain. The validating process may
require that it hold a trusted CA certificate for each link in the
chain, or only for the root of the chain.

Authentication and the AG

This brings us back to the Access Grid and the way it uses PKI.

Each AG client and service holds an X509 identity certificate. Any
communications exchange between a client and a service (or a client
and another client) is authenticated, with the validation rules
discussed above being upheld.

This mechanism has two important implications which drive a number of
points in the design of the AG authentication implementation.

First, each participant must have an identity certificate, and it must
have a readable private key (by means of the key being unencrypted, by
the user having provided a password to decrypt the key, or by the key
actually being a proxy certificate with its unencrypted key).

Next, each participant in a communication must hold a copy of the CA
certificate for the CA that issued the identity certificate for the
party with which it is communicating.

Before delving into more detail, we will discuss the issue of access
control.

Authorization

Communication exchanges between parties in an AG session are typically
for the purpose of requesting some action to be performed or for the
exchange of information. The process of authorization is the means by
which a party can determine whether the requesting party is to be
allowed to perform the action or have access to the information. This
decision is made on the basis of the identity of the requesting party,
as valided by the authentication process.

In the AG, there exists a rich role-based access control
implementation which gives the application or service programmer a
great deal of flexibility in expressing the access control
requirements for a resource.

Further details of the authorization toolkit are outside the scope of
this document.

Operational issues

We will now address the two important implications of the use of PKI
in the Access Grid.

Identity Certificates

As discussed above, each communicating entity in the Access Grid must
hold an identity certificate. This implies that each person using the
AG must some how be issued a certifcate, as must each server or
service.

Certificates are issued in collaboration with a certificate
authority. The entity requesting a certificate creates a pair of
documents: a private key and a certificate request. The private key is
held locally, and is often encrypted (as discussed earlier). The
certificate request holds the the public key corresponding to the new
private key, and is in fact signed by that private key. It also holds
identifying inforamation about the requesting party.

The certificate request is presented to the certificate authority. The
CA inspects the certificate request, and validates the digital signature on
the request. The CA must then make a decision: Do I believe that the
party which presented this certificate request is the party who is
named in teh request? Remember that a certificate asserts a binding
between a name and a promise to hold a private key private.  The
details on what level of trust is required for a CA to sign the
certificate varies greatly from CA to CA.

If the CA does decide that the requestor of the certificate is to be
trusted, it creates a new document, the certificate. The public key
contained in the request is copied to the certificate, the certificate
is given a name (according to the policies of the CA), the issuing
CA's name, and starting and ending times of validity. Then the CA
signs the certificate with its private key. The resulting certificate
is returnd to the requesting entity, which can now use it for
identifying itself.

Trusted CA certificates

Any communication based on mutual authentication requires that
each party hold the CA certificate that was used to issue its peer's
identity certifiate. This implies that, ahead of time, the AG software
must be configured with these certificates.

In the AG toolkit, we address this issue by shipping with the software
the CA certificates for the certificate authorities run by the AG
developers, and a small set of other certificates. It is currently the
responsibility of an organization that is using a different CA for
their identity certificates to make the required CA certifiates
available for their users. We are investigating mechanisms to
streamline this process. One proposed solution allows a client to
query a server for the CA certificates it requires, and install them
into the client's set of trusted CA certificates.

Offline and Online CAs

The certificate issuing process can proceed in two
ways. In an offline CA, the requests are not processed in realtime; in
a higly-secure production CA, in fact, the issuance of a certificate
may require the user to present real-life credentials (a drivers
license or laboratory identification badge).

In an online CA, the decision to sign certificates is made
automatically, and the certificate is issued immediately in response
to the request.

The Access Grid group at Argonne National Laboratory maintain one of
each of these certificate authority types.

The AGDev CA is an offline CA. It is accessed through the certificate
request mechanism that is built into the Access Grid client. We
support the request of individual identity certificates and the
request of service certificates. We have a fairly flexible issuing
policy: individual identity certificates are issued in the name of
individuals, and the contain a domain which matches the domain of the
user's email address. Service certificates must also have a domain
that matches the requesting user's email address. Requests and issued
certificates are transferred using a simple web service protocol to a
central server.

We also run an anonymous CA. This is an online CA that will sign any
certificate request sent to it, but the name placed on the generated
certificate is always of the form "Anonymous User XXXXXXX", where
XXXXXXX represents a unique random string. Such certificates enable
users to have access to AG resources (that trust the anonymous CA
certificate), but do not provide a great deal of solid identification
information. They are quite sufficient for a large class of uses of
the AG software.

With the installation of the appropriate trusted CA certificates, one
can use identity certificates issued by any other PKI.

Additional services

Recall that one must have a certificate to use the AG software. This
implies that the file containing the certificate itself must be
present on any computer that one uses. If one only uses the Access
Grid software on a fixed set of computers, this model works well,
after the startup cost of copying the certificate to each computer is
paid. However, using that identity certificate on a new computer can
be difficult.

One solution to this problem is to carry the certificate with you. One
can simply copy the file to the now commonly-used memory stick, and
use that on each computer. A more secure apporach is to use a hardware
encryption token. We plan to research methods to make the use of such
removable hardware easy for users.

A second solution is to store the certificate online. This approach is
similar to that used with an online CA, except that the original
certificate may have been issued via an offline CA. The risk in such
an approach comes with the possibility that the server machine could
be compromised. The NCSA MyProxy software provides a way to mitigate
this risk. Instead of the actual certificate being stored online, a
proxy to the certificate is stored. This proxy has a limited lifetime
(typically days to weeks), and must be periodically renewed. When one
wishes to authenticate with his identity certifiate, a protocol
exchange occurs with the MyProxy server resulting in a proxy to the
proxy being created locally; this proxy can then be used to
authenticate with the AG environment.

Service Authentication

A multiple-machine Access Grid node presents a particular
authentication problem. If we are to use PKI-based secure
communications between the components of a node (which we must if they
are on an open network, since confidential information like media
stream encryption keys must be exchanged beteween them), they must
each have identity certificates.

We currently address this by issuing a service certificate to each
machine. These certificates do not have encrypted private keys, and
thus do not require the creation of a proxy certificate. Since they
are clearly not user certificates, the compromise of one of them will
likely not lead to the loss of confidential information (since the
configuration of a secure venue will likely include a list of specific
individual users's identities). However, the service certificates
still must be requested and installed, a manual process that can be
time consuming.

It is common that only the machines in a multiple machine node will
ever need to communicate with each other; hence, it is actually
overkill for them to be issued certificates by a well-known CA.

Consider the following alternative approach. One machine in a
multiple-machine cluster is chosen to host a cluster-local CA. This
CA's certificate is installed as the only trusted CA certificate in
each machine in the cluster, and a service certificate is issued from
the CA to each of the machines, for their use in communicating with
each other.

This solution achieves protected communication within the cluster, and
does not require any outside intervention. If, however, an outside
user does need to contact machines in the cluster (say, to use the
remote-control interface on the node), the cluster CA would be
required to issue an identity certificate to that user, and the user
would be required to add the cluster CA to his list of trusted
CAs.

Certificate Management Tools

Since certificates are so important to the operation of the AG, the AG
Toolkit includes a tools for helping users manage their certificates.

At the core of this is a certificate management module that the
toolkit uses for all access to certificates. It holds a repository of
identity certificates, trusted CA certificates, and proxy
certificates. A user may interact with this certificate store via a
commandline tool, or, preferably, via an interactive GUI-based
tool. The management tools allow a user to browse the installed
certificates, inspect them in detail, and check their
validity. Certificates can be exported to disk for safe keeping or for
installation on another machine. They can also be imported from disk
after being issued by a third-party CA or having been exported on
another computer.

The certificate management tools also include the interfaces for
requesting certificates from the AGDev and anonymous certificate
authorities and installing the approved certificates.

Future Plans

The AG Toolkit currently uses SOAP messaging over SSL-protected
sockets for all its control communication. As the technology matures,
the AG project will migrate toward using higher-level web services
protocols. These protocols are based on more sophisticated XML
messaging, and ultimately use an XML-based security mechanism, where
content encryption moves into the messaging infrastructure instead of
being performed at the wire level. As we move toward the use of these
protocols, which are based on the Web Services Resource Framework,
with the WS-Security framework providing the aforementioned security
support, we will likely have to modify the way in which security is
managed. However, it is likely that much of the current infrastructure
will be able to be reused; the requirement to manage X.509 identity
certificates will not be going away any time soon.




More information about the ag-dev mailing list