User:Minali Arora

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.

Employees can use their local corporate credentials to log on to external networks that have trust relationships with their companies. One solution for this is- Federated Identity. Federated identity is best described as: a. Two or more applications that share the same set of users. b. Two or more organizations that share the same set of users. c. Two or more organizations that share an identity provider. d. One organization trusting users from one or more other organizations to access its applications. Password based Authentication: Using a password to authenticate a client to a Server

In this case, the user has already trusted the server. The user has requested a resource controlled by the server. The server requires client authentication before permitting access to the requested resource. The client sends the username and the password in plain text across the network either in plain text or over an encrypted SSL connection. The server looks up the username and password in its local database and verifies the user’s authentication. If it is valid, it then allows the client to access it.

Certificate based Authentication: One of the advantages of Certificate based Authentication is that allows the user to send only a single password which is not sent across the network but allows the administrator to control authentication centrally.

The above fig assumes that the client has a valid certificate that can be used to identify the client to the server. Certificate based authentication is preferred to Password based authentication because it is based on the user both processing the private key and knowing the password. Note: Neither password-based authentication nor certificate-based authentication address security issues related to physical access to individual machines or passwords. 1. The client software maintains a database of the private keys that correspond to the public keys published in any certificates issued for that client. The client asks for the password to this database the first time the client needs to access it during a given session, such as the first time the user attempts to access an SSL-enabled server that requires certificate-based client authentication. 2. After entering this password once, the user does not need to enter it again for the rest of the session, even when accessing other SSL-enabled servers. 3. The client unlocks the private-key database, retrieves the private key for the user's certificate, and uses that private key to sign data randomly-generated from input from both the client and the server. This data and the digital signature are evidence of the private key's validity. The digital signature can be created only with that private key and can be validated with the corresponding public key against the signed data, which is unique to the SSL session. 4. The client sends both the user's certificate and the randomly-generated data across the network. 5. The server uses the certificate and the signed data to authenticate the user's identity. 6. The server may perform other authentication tasks, such as checking that the certificate presented by the client is stored in the user's entry in an LDAP directory. The server then evaluates whether the identified user is permitted to access the requested resource. This evaluation process can employ a variety of standard authorization mechanisms, potentially using additional information in an LDAP directory or company databases. If the result of the evaluation is positive, the server allows the client to access the requested resource.

Certificates replace the authentication portion of the interaction between the client and the server. Instead of requiring a user to send passwords across the network continually, single sign-on requires the user to enter the private-key database password once, without sending it across the network. For the rest of the session, the client presents the user's certificate to authenticate the user to each new server it encounters. Existing authorization mechanisms based on the authenticated user identity are not affected.

Smart Card Authentication:

The mentioned topic considers Smart Cards of the type being used for Personal Identity Verification. These smart cards are based on PKI and digital signatures, also contain biometric information as well as printed information and a photo. The most important digital signature related information on the card are: 1. A 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 since it is private to the user. Understanding how authentication takes place with Federated Identity: To understand how smart card authentication works, let us understand the three basic terminologies: • TTP (Trusted Third Party): This is the entity that provides the federation services to bridge between the other players. • IdP (Identity Provider): This is 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. Let us take a hypothetical situation, 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.

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

SCVP purposes 1. It allows a client to delegate certification path construction and certification path validation to a 2. server . 3. It is a common point of trust within the PKI. 4. Certification path construction or validation is performed according to a validation policy, which 5. contains one or more trust anchors (e.g. CA certs). 6. This enforces uniformly the rules and policies of a specific PKI (useful for centralized environments) 7. It allows simplification of client implementations and use of a set of pre-defined validation policies. 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.