Authentication – Establishing Identity

Establishing identity with people you know is not very hard to do in person. People look at you, hear you, and know you well enough to quickly detect an impostor. It is possible, however, for an impostor to succeed in person if he is unknown to the person checking his identity.

This is why we need certificates such as passports, driver’s licenses, and employee badges. These certificates generally bind information about a person (such as their name, identity, or entitlements) with information that can be used to uniquely identify the person, such as a picture and a signature – things we assume to be relatively difficult to forge.

On the Internet, as a famous New Yorker magazine cartoon put it,

“nobody knows you’re a dog.” It is easy to pretend to be someone else over a distance with unfamiliar parties and with little real interaction.

Authentication means using techniques to establish identity, based on something you know, have, or are. A username and a password are something you know, and if you keep your password secret, it is very difficult for others to impersonate you. A token, such as a Subscriber Identity Module (SIM card) in a mobile phone, or a card that generates one-time passwords (e.g., an RSA SecurID card), is something you have.

If it is hard for others to replicate such a device, having one allows you to establish your identity to others, assuming you do not lose the device or share it with someone else. A biometric, such as a fingerprint or retinal eye scan, is something you are. It is difficult for others to copy, unless

they are able to copy the dataset produced in reading the biometric (or make a cast of your finger in exactly the right way). To minimize the risks associated with these authentication mechanisms, more than one mechanism can be used at once. For example, using a password with a SecurID card is a two-factor authentication mechanism, which can reduce the risks associated with the use of either mechanism alone.

In the simplest scenario, one party authenticates himself to another party. An investor identifies their identity to the brokerage firm before using his account, and ensures he is actually interacting with the broker.

Similarly, a retailer identifies himself to a manufacturer when ordering replacement stock, and ensures that he is in fact interacting with the manufacturer. Often one party can identify the other by something they know regarding the private agreement related to the transaction. This is information only shared by the two parties. However, in order to reduce the risks associated with attacks where one party impersonates another, it is necessary to use explicit bilateral authentication when performing electronic transactions or information exchange of any consequence.

It is important for communicating parties to be certain about whom they are communicating with. Usually this is taken for granted in face-to-face communication, but the situation is quite different in electronic communication. Communicating with an unknown party may involve great risks. For example, if one party is able to impose as someone else (a method known as spoofing), then message integrity and confidentiality are of no use.

It is the responsibility of the relying party (recipient of a message) to ensure that the authentication level is appropriate to the risks involved.

The relying party should perform appropriate signature verification and credentials validation. One example is the validation of an X.509 certificate chain (including revocation status).

A variety of techniques can be used to achieve direct authentication to a relying party. These techniques include:

• Peer authentication over a single hop using SSL/TLS in conjunction with X.509 certificates

• Peer authentication over a single hop using HTTP basic authentication (username and password) or digest authentication, presumably over a secure transport (e.g., SSL/TLS)

• End-to-End Web service client authentication with a Username SOAP Message Security token to convey a username and a password or a one-time password value. This token can be bound to the message with a signature together with a key derivation algorithm, and should be encrypted using SOAP Message Security encryption.

• End-to-End Web service client authentication through a SOAP Message Security digital signature binding a key associated with a SOAP Message Security token to the message. This key can be agreed on in advance, or it can be associated with an infrastructure such as PKI or Kerberos. The key can be associated with an identity using the appropriate token (such as an X.509, Kerberos, or SAML token).

• Passing an authentication assertion (e.g., a SAML token) in the message, binding it to the message.

• Authentication of a mobile device to a mobile network infrastructure using SIM authentication, which effectively uses digital signatures associated with the SIM token key. This is done at the network layer, but it allows a network operator to establish identity and share it with an identity provider (IDP), if the IDP is operating within a mobile operator’s infrastructure. Since anyone can pick up and use a mobile device that is not locked, the use of an additional authentication technique may be necessary to reduce risk to an appropriate level.

It can be difficult for every service provider to support the variety of authentication mechanisms listed, and doing so would require a large number of service providers to repeat the implementation. This does not scale. An alternative is for a system component to support authentication as a service, and then provide authentication information to other services. In the Liberty Identity Web Services Framework (ID-WSF) this service is provided by an IDP, which creates tokens summarizing information about authentication events. If other service providers can trust these assertions, they no longer have to support a variety of authentication mechanisms.

As a Web service client can use more than one technique to authenticate itself to a Web service provider (or in particular to an IDP), there needs to be a way to determine the used authentication technique. One option is to simply try an authentication method and see if it is accepted, but this might not be useful, especially when various policy constraints associated with a technique must be met. Thus, the option may not be acceptable. Other approaches include deciding the issue out of band, or using a general Web services policy mechanism to reach an agreement. The rejection of an unauthenticated request could include, for example, a policy statement regarding the required mechanism and constraints.

The Liberty ID-WSF Authentication Service Specification defines a general, open approach, in which a series of SOAP messages is used to negotiate an acceptable authentication method. These SOAP messages follow the IETF Simple Authentication and Security Layer (SASL) framework

and use definitions of authentication methods to allow a negotiation.

In this scenario, the desired form of authentication is negotiated using SOAP messages containing <SASLRequest> and <SASLResponse>

elements in the SOAP Body. Supported authentication methods are registered in the SASL framework and have associated identifiers. This information is used as part of the SASL negotiation to establish the authentication method.