Public Key Infrastructure
Public keys can be used to verify digital signatures, but what does that tell us about the individual or entity performing the signature? Only that he, she, or it holds the corresponding private key. What is needed is a way to bind an identity to a public key in such a way that we will know with certainty that the holder of the corresponding private key is a particular identity. Certificates can be used to accomplish this task.
Certificates are documents that bind an identity to a public key. This binding is enforced by a digital signature of a Certification Authority (CA). A CA is a trusted entity, trusted to provide certificates bearing its signature only to individuals or entities that can prove their identity in a satisfactory manner to the CA. In effect, CAs are digital notary publics; they are trusted third parties. Being digital documents, certificates must be constructed in a well-defined format to enable their contents to be properly read. The ITU X.509 format is the most popular.
When all members of a group place trust in a common CA and are all issued certificates by that CA, they form a Public Key Infrastructure (PKI). Each member of the group will be able to present its certificate to every other member of the group and, provided it can demonstrate proof of possession of the corresponding private key, identify itself as the individual or entity described in the certificate. This allows for scalable authentication because each member need only enter into a single trust relationship with the CA. Without a PKI, every member of the group would have to enter into a pairwise trust relationship with every other member. That scales poorly as the group enters any reasonable size.
To join a PKI, an entity must enter into a trust relationship with the CA. The entity must obtain the CA's certificate (which, being the "authority" can be a self-signed certificate), prove its identity to the CA's satisfaction, and then present a public key for which it holds the corresponding private key. The CA then constructs a certificate that bears the identity the entity was able to prove, the public key the entity presented, and identification information of the CA itself, all signed by the CA's private key. A certificate can also contain additional information, such as alternate identities and usage restrictions.
For two members of a PKI to authenticate each other they must perform three steps: They must obtain each other's certificate; verify the authenticity of that certificate; and, then, use the public key from the certificate to verify the digital signature of the other member. This last step is crucial and is quite often forgotten when people say, "we're authenticating using a certificate." Merely obtaining a certificate from someone doesn't authenticate him or her. You must also make the peer prove possession of the corresponding private key.
Certificates can be obtained any number of ways. They can be passed in line as part of any authentication protocol such as IKE. They can be obtained from a common directory via a protocol such as LDAP (the Lightweight Directory Access Protocol). They could even be published in a newspaper. The very nature of certificates that they are necessary to authenticate the identity contained in the certificate, and that they are secured by the CA's signature and therefore require no additional security regimen means that the method that can put certificates in the most hands with the least problems will be the best. There is practically no reason to limit the distribution of a certificate. The more people that have the certificate, or have a way of obtaining it, the more useful it is.
Authentication of a certificate is a complex task that may require a recursive authentication of other certificates. At its heart, though, it involves checking the CA's signature on the certificate itself and making sure that the certificate is still current and has not been revoked. Since the CA is already trusted to not issue bogus certificates, any certificate that bears its authentic signature can be verified and the public key embedded in the certificate can be authoritatively bound to the identity in the certificate. A certificate can be treated as any other document that is signed (recall the description of digital signatures from Chapter 1). The entire certificate is hashed to form a digest and this digest is signed by the certification authority. The signature becomes part of the certificate itself. Part of the format of the certificate is the hash algorithm used to form the digest and the signature algorithm of the certification authority.
Once a certificate has been obtained and verified, the public key contained in the certificate can be removed and used to verify any other digital signature. IKE authentication using digital signatures or any of the encrypted nonce authentication methods requires the public key of the peer to either verify the signed hash or encrypt the nonce. Using certificates allows IKE to trust the public key and equate an identity to the peer upon completion of the authentication phase of the exchange. Once we authenticate a peer using a certificate that has been signed by a trusted CA, we know to whom we're speaking the identity in the certificate and can use that information to restrict or allow access to resources and to constrain any further negotiation.
The type of PKI described above is a simple, single-level type of PKI. Only members of the PKI can authenticate other members of a PKI. If Alice is a member of one PKI and Bob is a member of a different PKI, they cannot authenticate each other. For Alice and Bob to authenticate each other, their separate PKIs must enter into a mutual trust arrangement; they must form a trust model. This arrangement can be a joint exchange of certification authority. The CA of Alice's PKI can sign the certificate of the CA of Bob's PKI and vice versa. Such an arrangement is referred to as cross certification (Figure 12.8). Alice trusts her CA to not use its signature improperly and it signed a certificate bearing the public key and identity of another CA it certified another CA. The other CA further certified the identity of Bob and issued him a certificate. Alice now has a clear path to verify Bob's certificate and each step on the path represents a trust relationship.
Figure 12.8. Cross Certification.
Another trust model that can be used in building a PKI is a hierarchical one. In this model there exists a "root" CA that all entities implicitly trust. But instead of having a flat PKI where this CA issues all certificates, it instead signs the certificates of other certification authorities. These other CAs can, in turn, sign the certificates of still more CAs. In this way a hierarchical tree of trust is built (Figure 12.9).
Figure 12.9. Hierarchical Trust Model.
Hierarchical relationships exist naturally, so this model is well suited to adapting a PKI to an organization and not the other way around. For instance, have different departments and those departments can have groups. In this way an engineer working in the security group of the network protocols division of a corporation can have a certificate that is signed by the CA of the security group. The certificate of that CA is signed by the network protocols division CA which can, in turn, be signed by the engineering department CA that is then signed by the corporate CA. Validation of a certificate entails "walking" a chain of certificates until a common trust point a node on the tree is reached. To validate the employee's certificate, a member of the human resources department may have to walk the chain all the way back to the corporate CA, while a member of the integrated circuit design team (who is also in the engineering department) may only need to walk as far as the engineering CA.
Certificates cannot last forever. If an employee left a company her certificate should not allow her to authenticate herself as an employee anymore. Therefore, each CA maintains a list of revoked certificates a Certificate Revocation List, or CRL. This CRL is, ideally, published in an easily available repository or directory. As part of certificate validation (signature checking, chain walking, etc.) the CRL must be checked to determine whether this certificate is current or has been revoked. Obviously, any certificate on the CRL should not be accepted.
An important issue in building a PKI is the problem of the name space. The identity information contained in a certificate could be a name, address, city, and country of residence. Or it could be a name, division, and employee number. Or, if the entity is not even a human being, an IP address. Each CA describes the identity of an entity using information it deems important. What one CA thinks important another may think trivial, perhaps so trivial as to not even mention it. There could even be conflicts in name spaces between CAs.
For any security scheme involving authentication to scale to a reasonable size, some form of PKI must be built. Using preshared keys with IKE works, but the burden of preshared key distribution rapidly becomes onerous as the group grows. Similarly the bureaucracy for securely distributing public keys for use with IKE's other authentication methods would also collapse under its own weight. Clearly, IKE and IPSec need a PKI, but the issues of certificate format, certificate acquisition, trust models, certificate expiry, and revocation, etc., are not part of the IKE and IPSec specifications. That problem was (and still is being) solved by another working group in the IETF, the public key infrastructure (PKIX) working group. The PKIX group has defined an architectural model of a PKI and has developed a series of standards-track RFCs to describe it. The PKIX working group uses the work from other standards bodies (ITU, ANSI) but defines its use for the Internet. For instance, the definition of certain extensions to the X.509 standard are very broad and the PKIX working group has developed a profile for their use in the Internet. This is an on- going task, and as more and more PKIs are deployed, knowledge learned from the experience is translated back into the process as new documents or refinements of existing documents.
A PKI is not a technology solution in and of itself. It is an enabling technology. It is also an investment, and the benefits of it do not immediately outweigh the cost of deployment. Because of this, PKI deployment is a slow task and the number of fully functioning PKIs in existence today is quite small. While the early bird may catch the worm, it's usually not the first person through a mine field that survives, and that sentiment is seen in PKI development. PKIs are complex, and many thorny issues arise when they are built. It's not as easy as just saying, "We're going to use certificates for authentication" (although the amount of times that phrase is used as a complete answer is staggeringly large). As lessons are learned, though, PKIs will become more and more prevalent, thereby enabling the deployment of IKE and IPSec and satisfying the promise of ubiquitous network security on a global scale.
Top IPSec (2nd Edition) ISBN: 013046189X
EAN: 2147483647 Year: 2004
Pages: 76 Authors: Naganand Doraswamy, Dan Harkins
flylib.com © 2008-2017. If you may any questions please contact us: flylib@qtcs.net |