Delegated Authentication for User Managed Access

Use Case Metadata

Title

Delegated Authentication for User Managed Access

Status

Use Case Lifecycle Status

Contributed	Working Draft	Committee Review	Compilation	Approval	Publication
This use case has been approved in version 1.2. This page may have been updated since the 1.2 document was approved.

Use Case AHG Review Status

This use case is planned for review by the User Case AHG on 2013-08-28.

Use Case Category

Authentication

Contributor

Bob Pinheiro (nstic@bobpinheiro.com)

Use Case Content

Use Case Description

There are many instances in which the owner of an online protected resource, such as a bank account, health record, or other information repository, needs to allow someone else to access the resource. Since many, if not most, online resources today are protected with only a password or other shared secret(s), the simplist way in which a resource owner can allow someone else to access the protected resource is to share knowledge of the same userID and password that the resource owner uses. But in addition to being insecure, this method provides the other party with unconstrained access to the protected resource.

There is increasing recognition that resource owners need to have a way to delegate access to protected resources that is constrained in some way, as determined by policies defined by the resource owner. This need is at the heart of the Kantara Initiative’s User Managed Access (UMA) project. UMA is based on claims-based access control, which means that entities entitled to access protected resources will be given permission to do so contingent upon presentation to an Authorization Manager of an appropriate “claim.” A claim consists of a relevant set of attribute values pertaining to the requesting party, which is the entity that is requesting access to the resource. The idea is that an arbitrary requesting party may gain access to the protected resource, according to a predefined set of "permissions", provided that the claims satisfy some criteria designated by the resource owner. Hence it is not necessary for the resource owner to be able to designate specific individuals or entities authorized to access the resource. UMA does not specify a particular method for these claims to be generated. However, for access to high value resources, presumably the resource owner will require some sort of trusted third party to verify a claim, rather than allow a requesting party to issue self-asserted claims. This requires that requesting parties seeking access to high value resources have a relationship with such a third party, and that the requesting party is able authenticate to the third party prior to the claims being generated. Authentication in this case should require an authentication token “stronger” than a static password. The use of public key cryptography for providing strong authentication, as described in the use case Cryptographic Authentication for Access to Online Resources, is a viable alternative.

However, it is often the case that the resource owner can identify a specific set of individuals or entities that should have access to the resource. Because the UMA protocol is based on claims-based access control, such individuals seeking access to high value resources *may* need to have a prior relationship with a third party identity / attribute provider that can issue verified and trusted claims. Another possibility is that such individuals can simply be emailed a link that provides them with access to the protected resource. However, the first example excludes individuals from being able to access the resource if they don't have relationships with identity / attribute providers. The second example may provide less assurance to the resource owner that an authorized party is accessing the resource than is desired. This use case overcomes these restrictions by allowing the resource owner to directly provision a strong authentication token directly onto the device of authorized parties. Specifically, this use case proposes an authentication scheme that uses a private cryptographic key residing on the requesting party’s computing device as a second “something you have” authentication factor. In order to provision a public / private key pair on an authorized requesting party's device, this use case requires that the requesting party be able to enter the URL of the Authorization Server on the device, and that a one-time code be sent to the requesting party’s mobile phone, which will then be entered on the device where the key pair will be provisioned.

Even if the specific set of individuals authorized for access to the protected resource do have relationships with third parties that could issue trusted claims, there is potential value in enabling the requesting party to directly authenticate to the Authorization Server using a strong authentication token, without a third party needing to be involved in the transaction. By eliminating the participation of a third party in every authentication transaction, a potential privacy issue is eliminated. A potential reliability issue is also eliminated, since the unavailability of the third party to issue a claim to the Authorization Server would imply that the requesting party would not be able to access the protected resource.

One of the NSTIC Guiding Principles is that identity solutions should be secure and resilient. Authentication methods that rely on shared secrets, such as passwords, are well known to be less secure than methods based on public key cryptography, for example. NSTIC-compliant identity solutions for high assurance applications, such as a user allowing someone else to have restricted access to the user’s high value online resources, should strive to eliminate reliance on weak authentication methods based on shared secrets whenever possible. The NSTIC derived requirements compiled by the National Program Office also specify that identity credentials should be resistant to theft, tampering, counterfeiting, and exploitation. Although no single authentication technology has a monopoly on these properties, public key cryptography arguably provides better security than most, if not all, current alternatives. In addition, recent advances have the potential to make public key crypto usable for consumer applications. Although a use case does not need to focus on any specific technologies, a goal of this use case is to help ensure that an NSTIC-compliant identity ecosystem will incorporate strong authentication methods that have previously not been usable by consumers.

Actors

• A Resource Owner is the owner of a protected online resource who wishes to allow another individual to have access to that resource.
• A Requesting Party is an individual person who seeks access to a protected resource owned by the Resource Owner.
• An Authorization Server is an online system that allows the Resource Owner to specify a set of access permissions to be granted to the Requesting Party. The Resource Owner interacts with the Authorization Server to specify the policies or constraints that define the permissions that will be granted to a particular Requesting Party. The Resource Owner may choose to provide full access to the protected resource, so that the Requesting Party is treated the same as the Resource Owner when accessing the resource. Alternately, the Resource Owner may choose to specify a limited, constrained set of permissions.
• A Resource Server is an online system that a Requesting Party interacts with in order to obtain access to the protected resource. The Requesting Party must authenticate to the Resource Server to gain access to the protected resource.

Assumptions

Resource Owners are able to specify a given set of individuals who are authorized to access a protected resource according to permissions set by the Resource Owner.

An NSTIC-compliant identity ecosystem is presumed to incorporate functionality necessary to make public key cryptography usable and practical as a strong authentication method for consumer applications such as UMA.

An appropriate application (the “crypto manager”) will exist on the Requesting Party’s device to generate and manage public/private key pairs for authentication to multiple websites. This application must provide a user interface that makes it easy for users to cryptographically authenticate to multiple websites. This crypto manager is assumed to be an important component of NSTIC-compliant identity ecosystems and will be deployed on user devices in a manner yet to be described.

For increased security, Requesting Parties will only be able to access protected resources from “registered” devices, where a device becomes registered if it is provisioned with a private crypto key providing strong authentication. The registration process itself requires that the Requesting Party control a particular email account as well as a particular mobile phone number.

Process Flow

Resource Owner

The Resource Owner logins in to the Authorization Server to either define a new policy that specifies the access permissions for some specific Requesting Party, or to reuse a previously-defined policy to assign access permissions for the Requesting Party. [The method of authentication used by the Resource Owner for this purpose is not specified here.]

After the access permissions are defined, the Authorization Server requests that the Resource Owner provide a mobile phone number and email address for the Requesting Party. [Note: if the Requesting Party cannot receive SMS text messages on a mobile phone, the Resource Owner must indicate this and provide the phone number of a phone that can receive ordinary voice calls instead.]

After this information is provided, the Authorization Server sends an email message to the Requesting Party containing the URL of the Resource Server, together with a unique permission code. The message instructs the Requesting Party to register the device(s) that the Requesting Party wishes to use to access the protected resource by: (a) browsing to the URL of the Resource Server using the desired device, (b) providing the permission code to the Resource Server registration page, (c) receiving a one-time code from the Requesting Party’s mobile phone, and (d) entering it on the Resource Server registration page. [If the Requesting Party does not use a mobile phone that can accept SMS text messages, the alternative is that the Resource Server makes an automatic call to the Requesting Party’s phone, and generates a spoken one-time code.]

To change the access permissions granted to the Requesting Party, including revocation of the permissions, the Resource Owner logins in to the Authorization Server, using the permission code to identify the set of permissions to be changed. Once changed, the new set of permissions is associated with the permission code.

Requesting Party

The Requesting Party receives an email from the Authorization Server, and proceeds to register a desired device for access to the protected resource, as described above.

As part of the registration process, a private cryptographic key is provisioned on the Requesting Party’s device (using the crypto manager), with the corresponding public key sent to the Resource Server. The private key, in combination with the permission code, will allow the Requesting Party to access the protected resource with the appropriate permissions. An additional option may require the Requesting Party to provide a PIN or password to unlock the private key on the device. However, this PIN/password is not a shared secret, since it never leaves the device.

Once registered, the crypto manager on the device will presents a simple user interface when the Requesting Party accesses the appropriate Resource Server access page. The Requesting Party clicks a button to initiate the cryptographic authentication process, which may require the Requesting Party to provide a PIN or password to unlock the private key. Once this is done, the Requesting Party is granted permissioned access to the protected resource.

Any changes to the access permissions made by the Resource Owner will be noticed when the Requesting Party authenticates to the Resource Server and seeks to access the protected resource, since the modified permissions are associated with the same permission code used during the authentication process.

Success Scenario

A Resource Owner is able to successfully create a policy specifying the constraints under which a Requesting Party is given permission to access a protected resource.

The Requesting Party is able to obtain access to the protected resource after a successful challenge-response interaction between the Resource Server and the Requesting Party’s device that depends on the presence of the private key provisioned during the registration process.

Error Conditions

The registration process is compromised in some way, so that an attacker is able to register his device for access to the protected resource.

A hacker is able to compromise the private key on the Requesting Party’s device.

References and Citations

Cryptographic Authentication for Access to Online Resources Use Case

Eve Maler: Two Step Verification Will End Consensual Impersonation

NSTIC Guiding Principles Considerations

Privacy Considerations

Implementation details such as who should operate the authorization server should be considered. In addition, due diligence should be performed when considering the use case participants ability to track user activity.