Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

Whitepapers

Federated Identity, Distributed PKI and Smart Cards

Purpose

This paper considers authentication systems based on smart cards, where the smart cards will be issued by many organizations, and authentication must work at any location. An important example of this type of deployment is the US Government planned deployment in support of HSPD (Homeland Security Presidential Directive) 12.

Federated Identity schemes have been proposed to support HSPD-12. This paper first looks at systems where federated identity approaches are appropriate. It then considers smart card based deployments, and looks at requirements and solutions to support them. It describes why use of a distributed PKI is generally superior to a federated identity approach.

An Overall Model for Large Scale Authentication

In order to build a viable authentication system for a large number of users, the management has to be distributed, with many organizations within the total system handling identity and credential management for local users. The process for operation within a local organization is reasonably straightforward and is not considered in detail here. The harder problem, which this paper is focused on, is where a user needs to be authenticated by an organization other than the one that directly manages the user's identity.

The model considered here is where there many organizations. Establishing direct trust between a large number of organizations does not scale well:

For a large number of organizations, it is sensible to have a central 'bridge' entity, with which each organization establishes trust, as illustrated below. This simplifies trust connectivity.

In order to make the following examples clear, we use a hypothetical scenario where a user associated with the Department of Justice (DoJ) is visiting the State of Texas, and wishes to be authenticated at the State of Texas in order to access local services.

Password Authentication and Federated Identity

Before looking at smart cards, we look at password based authentication. This gives a comparison architecture, and also shows the sort of situation where a federated identity approach is useful.

Federated Identity systems use standard terms to describe entities taking part in an identity system. These terms are noted here, and are used in this paper to aid those who are familiar with these terms.

• TTP (Trusted Third Party). This is the entity that provides the federation services to bridge between the other players.
• IdP (Identity Provider). This an the entity that manages identity.
• SP (Service Provider). This is the entity that is providing service to the user and requires to authenticate and authorize a user prior to provision of service.

The above diagram shows how password authentication works. The DoJ user runs a Web browser at State of Texas (SP) and this connects securely to the DoJ (IdP). The user provides username and password over the secure Web connection to a server at DoJ. Only the User and the DoJ server have the password information (shared secret). Authentication occurs at the DoJ (IdP).

In order for the State of Texas (SP) to trust the user, there must be a trust relationship between State of Texas (SP) and a TTP (Trusted Third Party), and a similar one between the TTP and DoJ (IdP). These trust relationships are used to communicate back to State of Texas (SP) that the user has been correctly authenticated at DoJ (IdP). It enables a Web Server at the State of Texas to trust the user, based on the authentication that occurred at DoJ.

The user's identity and authentication belong to the DoJ (IdP). This identity (local to DoJ) is being shared with other organizations. This approach is known as Federated Identity. It enables identity verification at one organization to be used by another.

SAML (Security Assertion Markup Language) is the most widely known and usedstandard for federated identity. It will only deal with pair-wise trust (e.g., in the above example the TTP needs to be associated with either DoJ or State of Texas). In general proprietary protocols are needed if an additional level of trust indirection is needed.

Smart Card Authentication

This paper is considering smart cards of the type being used for Personal Identity Verification (PIV) as a part of HSPD-12. These smart cards are based on X.509 PKI and digital signatures, and also contain biometric information as well as printed information and a photo. Such smart cards will be designed to be tamper-proof and meeting a range of appropriate security specifications. The most important digital signature related information on the card are:

1. An X.509 certificate which is issued by the card issuing organization and contains the user's public key. This certificate can be read from the card.
2. The user's private key. This is used to digitally sign information, and may also be used to decrypt information intended for the user. The private key cannot be extracted from the card – it is private to the user.

The smart card provides a mechanism to securely authenticate the user who holds it.

Biometrics

The basic digital signature mechanism on the PIV is supplemented by biometric techniques. For example, data on the user's finger prints (or other biometric data) is held on the card. As part of the verification process, this biometric data is checked. This can be thought of as a high-tech and much more reliable equivalent of comparing a photo to a person. Because the biometric information is held in a tamper-proof manner, it can give a very high assurance that the card belongs to the person who is presenting it and being authenticated. The biometric information will generally be used in the same way as a PIN number for the card, and the card will only be enabled once a biometric match has been made. It is important to understand that Biometrics helps ensure that the card is valid, but does not otherwise affect the distributed authenticated process.

Using Smart Cards with Federated Identity

Smart card based authentication can be used with federated identity in a manner analogous to password based authentication. The DoJ user runs a Web browser at State of Texas (SP) and connects to a DoJ server (IdP). The smart card is used to create a digital signature that is verified by the DoJ server. As with the password based authentication, federated authentication using the TTP will pass information to State of Texas to enable access to local Web services.

Using Smart Cards with Distributed PKI

Because there is no password (secret key), a smart card can be verified locally at State of Texas (SP) by any smart card enabled application, as shown above. In our State of Texas example, authentication of the DoJ user occurs at the State of Texas where the smart card is read. This contrasts with the remote authentication in the password based example. The basic process is that the private key on the card is used to digitally sign something as part of the authentication process. This signed object is then verified using the user's certificate.

In order to complete the authentication, the system at State of Texas needs information that it does not possess and is not on the smart card. This information is provided by a Distributed PKI, as described in the following sections. 'Distributed PKI' is used to contrast this from the 'Federated Identity' of the previous section.

The Certificate Verification Requirement

At this point, validation has checked the digital signature of the card owner, and has matched the person carrying the card with biometric information on the card. This may seem complete, but a key piece missing in that the authentication is against the certificate that was provided on the card. In order to complete the authentication, there is a need to determine:

1. Was the certificate really issued by the DoJ (IdP).
2. Does the State of Texas trust certificates issued by the DoJ.
3. Is the certificate currently valid.

X.509 PKI is designed to enable secure answering of these questions, which will be explained in the following sections.

SVCP vs Direct Verification

There are two basic mechanisms for verifying the certificate provided. The first is done directly by the process that is validating the smart card.

The second mechanism is to use a protocol called SVCP (Server-based Certificate Verification Protocol). SVCP is a secure protocol that passes a certificate to a trusted server that validates the certificate. In our scenario, this would be an SVCP server operated by or on behalf of the State of Texas.

Note that in both scenarios, certificate validation happens at the State of Texas – it remains a process that is associated with the authenticating organization. Typically SVCP will be used in situations where verification happens only occasionally, and direct verification will be used in higher volume situations or where only a small number of specific users are validated. The underlying verification process is the same for both mechanisms. SVCP simply moves the certificate verification to the SVCP server. OCSP (Online Certificate Status Protocol) is a protocol that provides a subset of the SCVP functionality, which is insufficient to meet requirements.

Trust Anchors

In order to verify a certificate, the process doing the verification needs to start by trusting something. This trust point is referred to as a 'trust anchor'. A common trust anchor is a self-signed certificate issued by a Certification Authority (CA). 'Self Signed' means that the CA uses its private key (the one it uses to digitally sign all certificates) to sign a certificate for itself. In our example we will assume that the trust anchor for certificate validation at the State of Texas is a self signed certificate issued by the State of Texas CA. This self signed certificate will be carefully installed and protected, as the trust anchor is central to the verification process.

The trust anchor makes local verification easy, as it enables cryptographically secure verification of any certificate issued by the State of Texas CA. A local user will present a locally issued certificate, and this can be verified directly.

How a 'Remote' Certificate is Verified

In our scenario, the DoJ User's Certificate needs to be verified at State of Texas. This is done using an X.509 trust chain. This trust chain is built using cross certificates, where one CA issues a certificate for another CA. In our scenario, the Federal Bridge CA is used as an intermediate step, and this provides the central role described in Section 2. The trust chain is built with:

1. A cross certificate issued by State of Texas CA, which verifies the Federal Bridge CA,
2. A cross certificate issued by the Federal Bridge CA, which verifies the DoJ CA. The DoJ CA issues the Certificate being verified, and so the trust chain is complete.

This is illustrated in the diagram above, with the arrows representing the trust provided by the associated certificates. It can be seen that these two cross certificates enable certificate verification, and deal with the first two checks noted in previously. There is also a need to ensure that the certificate is currently valid (the third requirement). Validity dates are included in the certificate. If a certificate is revoked, it will be included in certificate revocation list (CRL). As part of the certificate verification in our scenario a currently valid CRL issues by the DoJ CA must be checked, along with some other CRLs and ARLs (Authority Revocation Lists).

In order for the DoJ user's certificate to be verified at State of Texas, the process doing the verification will need to have the two cross certificates, CRLs and ARLs noted above. The verification all happens at State of Texas, but requires information that will usually need to be obtained from elsewhere. There is no trusted intermediate organization participating in the verification. All that is needed is to gather the various PKI elements (certificates, CRLs, ARLs) together at the point of verification.

The Role of Directory

The directory has a quite simple role in this. In order for the verification to work, up to date information needs to be made available to processes performing verification. The directory is the location where this gets stored. In order for this to work, there needs to be coherent naming across the participating organizations, so that information can be referenced correctly. This leads to putting in place a directory that spans all of the organizations, and in effect using a single name space. . Note that this is quite different to the federated model described earlier. More information on the role of directory in this type of deployment is provided in two Isode white papers:

• Distributed Directory in support of large scale PKI
• Distributed Directory in support of Large Scale PKI: Supporting Government Departments

Authorization

The discussion so far has considered authentication – secure validation of an identity. In most situations, authorization is needed by the entity (Service Provider) performing the authentication in order to determine the rights of the authenticated user. There are three authentication scenarios that are common to authentication by both Federated Identity and Distributed PKI:

1. Implicit authorization. Here, the fact that the user has correctly authenticated is taken as authorization. This is appropriate for many applications taking the model "use is allowed, providing I know who you are", This enables application audit, and controlling access to the broad community of users (e.g., all government users).
2. Local authorization. Here, information local to the SP is used to control authorization based on "global" identity. This would be appropriate for an application that permitted a relatively restricted number of users access with a certain role. Here, local information could be managed of the list of users (local and remote) who are authorized.
3. Authorization from information in the Certificate. X.509 digital certificates allow additional information to be included in the certificate, and this can be used for authorization. A closed community could agree arbitrary attributes to be included in the certificate for authorization purposes. The most important general purpose attribute is "Security Label", which is widely used for authorization in military and high security situations. The core of a security label is a policy (e,g,, US Government) and a classification (e.g., Secret). By including appropriate security labels in the certificate, SPs can make authorization decisions based on the security label. This approach is good for handling authorization for a wide range of users.

There is a fourth secenarion, which is somewhat different for the two authentication mechanisms. This is where authorization information comes from the Identity Provider. In a federated identity approach, the IdP can provide additional attributes as a part of the federated process, and these can be used by the SP for authorization. In the Distributed PKI approach, authentication provides only the name and associated certificate. Where attributes are not available from the certificate, the directory name that identifies the user can b used to look up information in the directory. Although these mechanisms appear somewhat different, in practice they are likely to be implemented in the same way – attributes used for authentication are stored in a directory that is used by the IdP.

Federated Identity vs Distributed PKI to support Smart Cards

Federated Identity and Distributed PKI can both be used to support smart card authentication. Both require an infrastructure to operate. This section considers the merits of the two approaches.

Benefits of Federated Identity:

• A common infrastructure can be used for both password and smart card based authentication.

Benefits of Distributed PKI:

• It can be used for applications other than Web services to which federated identity is in practice restricted. Applications include:
  • Applications that make direct use of PKI based authentication, such as secure logon.
  • Physical entry systems, that need to check the smart card directly.
• Because the authentication is done locally it is straightforward for the local organization to apply its own security policies to the authentication.
• The distributed PKI is needed for other services, in particular to support verification of digitally signed documents and messages. Federated Identity is not appropriate for supporting secure messaging. Because a distributed PKI can support applications beyond Web services, it will be preferable for many types of deployment.
• Replication of data (including caching) can increase resilience and improve performance. This is particularly important as traffic volume grows.
  

Conclusions

This paper has shown how federated identity works for password based authentication, and how federated identity can also be used to support smart cards. This is contrasted this with the X.509 CA and Directory based model for supporting smart card based authentication. Federated identity is a useful approach for supporting password based authentication between organizations. Where smart cards are used, distributed PKI is an alternative to federated identity, and it offers substantial benefits over federated identity. In order to implement smart card authentication based on distributed PKI, PKI information (certificates, CRLs and ARLs) is needed at the point of verification. Directory plays a key role in making this information available.