retreat talk
Rick Stevens
stevens at mcs.anl.gov
Fri May 21 07:00:51 CDT 2004
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.
> >
> >
>
>
More information about the ag-dev
mailing list