retreat talk

[Ivan R. Judson]

What happened to the outline I provided? Did you have questions about it or
not feel it was appropriate? That was what the Wednesday time I set aside
for everyone to come and chat was for...since you didn't come I had been
assuming you were happy with what I had give you to start with.

This is quite a surprise in terms of a major change in content. 

Aside from that this content is way too large, the talks are 30 minutes (20
minutes + q/a). This is more like a 60 minute talk (so far) doing it any
justice. Additionally, the breadth of the subject you are covering is
probably too great for any single session, it would need to be broken up
into smaller separate presentations to get digested effectively.

I'm pretty alarmed at what seems like a left turn in albequrque, how can we
resolve this?

--Ivan

> -----Original Message-----
> From: owner-ag-dev at mcs.anl.gov 
> [mailto:owner-ag-dev at mcs.anl.gov] On Behalf Of Robert Olson
> Sent: Thursday, May 20, 2004 5:33 PM
> To: ag-dev at mcs.anl.gov
> Subject: retreat talk
> 
> 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.
> 
>