retreat talk

[Rick Stevens]

I think this is a great story that needs to be written up as a security
white paper and perhaps handed out in the session with the viewgraphs
focused in on subset.

For a 30 minute slot, one should plan on talking for 20-25 minutes with 
5-10 mins for Q+A.  That means something like 10-12 slides ideally..

--Rick

On 
Thu, 20 May 2004, Ivan R. Judson wrote:

> 
> 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.
> > 
> > 
> 
>