wdiff draft-ietf-oauth-pop-architecture-03.txt draft-ietf-oauth-pop-architecture-04.txt

OAuth P. Hunt, Ed.
Internet-Draft Oracle Corporation
Intended status: Informational J. Richer
Expires: March 28, April 21, 2016
W. Mills

P. Mishra
Oracle Corporation
H. Tschofenig
ARM Limited
September 25,
October 19, 2015

OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
draft-ietf-oauth-pop-architecture-03.txt
draft-ietf-oauth-pop-architecture-04.txt

Abstract

The OAuth 2.0 bearer token specification, as defined in RFC 6750,
allows any party in possession of a bearer token (a "bearer") to get
access to the associated resources (without demonstrating possession
of a cryptographic key). To prevent misuse, bearer tokens must to be
protected from disclosure in transit and at rest.

Some scenarios demand additional security protection whereby a client
needs to demonstrate possession of cryptographic keying material when
accessing a protected resource. This document motivates the
development of the OAuth 2.0 proof-of-possession security mechanism.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on March 28, April 21, 2016.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Preventing Access Token Re-Use by the Resource Server . . 4 3
3.2. TLS Channel Binding Support . . . . . . . . . . . . . . . 4
3.3. Access to a Non-TLS Protected Resource . . . . . . . . . 4
3.4. Offering Application Layer End-to-End Security . . . . . 5
4. Security and Privacy Threats . . . . . . . . . . . . . . . . 5
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Threat Mitigation . . . . . . . . . . . . . . . . . . . . . . 10
6.1. 6
5.1. Confidentiality Protection . . . . . . . . . . . . . . . 11
6.2. 7
5.2. Sender Constraint . . . . . . . . . . . . . . . . . . . . 11
6.3. 7
5.3. Key Confirmation . . . . . . . . . . . . . . . . . . . . 12
6.4. 8
5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. 9
6. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Client and Authorization Server Interaction . . . . . . . 14
7.1.1. Symmetric Keys . . . . . . . . . . . . . . . . . . . 14
7.1.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . 16
7.2. Client and Resource Server Interaction . . . . . . 10
7. Requirements . . . 17
7.3. Resource and Authorization Server Interaction (Token
Introspection) . . . . . . . . . . . . . . . . . . . . . 18 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 20 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21

1. Introduction

The

At the time of writing the OAuth 2.0 protocol family ([RFC6749],
[RFC6750], and [RFC6819]) offer a single token type known as the "bearer" token standardized security
mechanism to access protected resources. resources, namely the bearer token.
RFC 6750 [RFC6750] specifies the bearer token mechanism and defines
it as follows:

"A security token with the property that any party in possession
of the token (a "bearer") can use the token in any way that any
other party in possession of it can. Using a bearer token does
not require a bearer to prove possession of cryptographic key
material."

The bearer token meets the security needs of a number of use cases
the OAuth 2.0 protocol had originally been designed for. There are,
however, other scenarios that require stronger security properties
and ask for active participation of the OAuth client in form of
cryptographic computations when presenting an access token to a
resource server.

This document outlines additional use cases requiring stronger
security protection in Section 3, identifies threats in Section 4,
proposes different ways to mitigate those threats in Section 6, 5,
outlines an architecture for a solution that builds on top of the
existing OAuth 2.0 framework in Section 7, 6, and concludes with a
requirements list in Section 5. 7.

2. Terminology

The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
specification are to be interpreted as described in [RFC2119], with
the important qualification that, unless otherwise stated, these
terms apply to the design of the protocol, not its implementation or
application.

3. Use Cases

The main use case that motivates improvement upon "bearer" better-than-bearer token security is
the desire of resource servers to obtain additional assurance that
the client is indeed authorized to present an access token. The
expectation is that the use of additional credentials (symmetric or
asymmetric keying material) will encourage developers to take
additional precautions when transferring and storing access token in
combination with these credentials.

Additional use cases listed below provide further requirements for
the solution development. Note that a single solution does not
necessarily need to offer support for all use cases.

3.1. Preventing Access Token Re-Use by the Resource Server

Imagine a scenario where a resource server that receives a valid
access token,
the resource server then token re-uses it with other resource server. The reason for
re-use may be malicious or may well be legitimate. In a legitimate case, the intent is to support
use case consider chaining of computations whereby a resource server
needs to consult other third party resource servers to complete a the
requested operation. In both cases it may be assumed that the scope
of the access token is sufficiently large that it allows such a re-use. re-
use. For example, imagine a case where a company operates email
services as well as picture sharing services and that company had
decided to issue access tokens with a scope that allows access to
both services.

With this use case the desire is to prevent such access token re-use.
This also implies that the legitimate use cases require additional
enhancements for request chaining.

3.2. TLS Channel Binding Support

In this use case we consider the scenario where an OAuth 2.0 request
to a protected resource is secured using TLS but the client and the
resource server demand that the underlying TLS exchange is bound to
additional application layer security to prevent cases where the TLS
connection is terminated at a TLS intermediary, which splits the TLS
connection into two separate connections.

In this use case additional information should be is conveyed to the resource
server to ensure that no entity entity has tampered with the TLS
connection.

3.3. Access to a Non-TLS Protected Resource

This use case is for a web client that needs to access a resource
that makes data available (such as videos) without offering integrity
and confidentiality protection using TLS. Still, the initial
resource request using OAuth, which includes the access token, must
be protected against various threats (e.g., token replay, token
modification).

While it is possible to utilize bearer tokens in this scenario with
TLS protection when the request to the protected resource is made, as
described in [RFC6750], there may be the desire to avoid using TLS
between the client and the resource server at all. In such a case
the bearer token approach is not possible since it relies on TLS for
ensuring integrity and confidentiality protection of the access token
exchange since otherwise replay attacks are possible: First, an
eavesdropper may steal an access token and present represent it at a
different resource server. Second, an eavesdropper may steal an
access token and replay it against the same resource server at a
later point in time. In both cases, if the attack is successful, the
adversary gets access to the resource owners data or may perform an
operation selected by the adversary (e.g., sending a message). Note
that the adversary may obtain the access token (if the
recommendations in [RFC6749] and [RFC6750] are not followed) using a
number of ways, including eavesdropping the communication on the
wireless link.

Consequently, the important assumption in this use case is that a
resource server does not have TLS support and the security solution
should work in such a scenario. Furthermore, it may not be necessary
to provide authentication of the resource server towards the client.

3.4. Offering Application Layer End-to-End Security

In Web deployments resource servers are often placed behind load
balancers, which are deployed by the same organization that operates
the resource servers. These load balancers may terminate the TLS
connection setup and HTTP traffic is transmitted without TLS
protection in the clear from
the load balancer to the resource server. With application layer
security in addition to the underlying TLS security it is possible to
allow application servers to perform cryptographic verification on an
end-to-end basis.

The key aspect in this use case is therefore to offer end-to-end
security in the presence of load balancers via application layer
security. Enterprise networks also deploy proxies that inspect
traffic and thereby break TLS.

4. Security and Privacy Threats

The following list presents several common threats against protocols
utilizing some form of token. tokens. This list of threats is based on NIST
Special Publication 800-63 [NIST800-63]. We exclude a discussion of
threats related to any form of identity proofing and authentication
of the resource owner to the authorization server since these
procedures are not part of the OAuth 2.0 protocol specification
itself.

Token manufacture/modification:

An attacker may generate a bogus tokens or modify the token
content (such as authentication or attribute statements) of an
existing token, causing resource server to grant inappropriate
access to the client. For example, an attacker may modify the
token to extend the validity period. A client may modify the
token to have access to information that they should not be able
to view.

Token disclosure:

Tokens may contain personal data, such as real name, age or
birthday, payment information, etc.

Token redirect:

An attacker uses the token generated for consumption by the
resource server to obtain access to another resource server.

Token reuse:

An attacker attempts to use a token that has already been used
once with a resource server. The attacker may be an eavesdropper
who observes the communication exchange or, worse, one of the
communication end points. A client may, for example, leak access
tokens because it cannot keep secrets confidential. A client may
also reuse re-use access tokens for some other resource servers.
Finally, a resource server may use a token it had obtained from a
client and use it with another resource server that the client
interacts with. A resource server, offering relatively
unimportant application services, may attempt to use an access
token obtained from a client to access a high-value service, such
as a payment service, on behalf of the client using the same
access token.

Token repudiation:

Token repudiation refers to a property whereby a resource server
is given an assurance that the authorization server cannot deny to
have created a token for the client.

5. Requirements

RFC 4962 [RFC4962] gives useful guidelines for designers Threat Mitigation

A large range of
authentication and key management protocols. While RFC 4962 was
written with threats can be mitigated by protecting the AAA framework used for network access authentication
in mind content
of the offered suggestions are useful token, for example using a digital signature or a keyed
message digest. Alternatively, the design content of other
key management systems as well. The following requirements list
applies OAuth 2.0 terminology to the requirements outlined in RFC
4962.

These requirements include

Cryptographic Algorithm Independent:

The key management protocol MUST be cryptographic algorithm
independent.

Strong, fresh session keys:

Session keys MUST token could be strong and fresh. Each session deserves an
independent session key, i.e., one that is generated specifically
for
passed by reference rather than by value (requiring a separate
message exchange to resolve the intended use. In context of OAuth this means reference to the token content). To
simplify the subsequent description we assume that keying
material the token itself
is created in such a way that can only be used digitally signed by the
combination of a client instance, protected resource, authorization server and therefore cannot
be modified.

To deal with token redirect it is important for the authorization scope.

Limit Key Scope:

Following
server to include the principle identifier of least privilege, parties MUST NOT have
access to keying material that is the intended recipient - the
resource server. A resource server must not needed be allowed to perform their
role. Any protocol accept
access tokens that is used to establish session keys MUST
specify the scope are not meant for session keys, clearly identifying the
parties its consumption.

To provide protection against token disclosure two approaches are
possible, namely (a) not to whom include sensitive information inside the session key is available.

Replay Detection Mechanism:

The key management protocol exchanges MUST be replay protected.
Replay protection allows a protocol message recipient
token or (b) to discard
any message that was recorded during a previous legitimate
dialogue ensure confidentiality protection. The latter
approach requires at least the communication interaction between the
client and presented the authorization server as well as though it belonged to the current
dialogue.

Authenticate All Parties:

Each party in the key management protocol MUST be authenticated to
the other parties with whom they communicate. Authentication
mechanisms MUST maintain interaction
between the confidentiality of any secret values
used in client and the authentication process. Secrets MUST NOT be sent resource server to
another party without experience
confidentiality protection.

Authorization:

Client and resource server authorization MUST As an example, TLS with a ciphersuite
that offers confidentiality protection has to be performed. These
entities MUST demonstrate possession of applied (which is
currently true for all ciphersuites, except for one). Encrypting the appropriate keying
material, without disclosing it. Authorization
token content itself is REQUIRED
whenever another alternative. In our scenario the
authorization server would, for example, encrypt the token content
with a client interacts symmetric key shared with an authorization the resource server.
Authorization checking prevents an elevation of privilege attack.

Keying Material

To deal with token reuse more choices are available.

5.1. Confidentiality and Integrity:

While preserving algorithm independence, Protection

In this approach confidentiality and
integrity of all keying material MUST be maintained.

Confirm Cryptographic Algorithm Selection:

The selection protection of the "best" cryptographic algorithms SHOULD be
securely confirmed. The mechanism SHOULD detect attempted roll-
back attacks.

Uniquely Named Keys:

Key management proposals require a robust key naming scheme,
particularly where key caching exchange is supported. The key name
provides a way to refer
provided on the communication interfaces between the client and the
resource server, and between the client and the authorization server.
No eavesdropper on the wire is able to observe the token exchange.
Consequently, a key in replay by a protocol so that it third party is clear
to all parties which key is being referenced. Objects not possible. An
authorization server wants to ensure that cannot
be named cannot be managed. All keys MUST be uniquely named, it only hands out tokens to
clients it has authenticated first and
the key name MUST NOT directly or indirectly disclose the keying
material.

Prevent the Domino Effect:

Compromise who are authorized. For this
purpose, authentication of a single client MUST NOT compromise keying material
held by any other the client within to the system, including session keys
and long-term keys. Likewise, compromise of a single resource authorization server MUST NOT compromise keying material held by any other
Resource Server within the system. In the context of
will be a key
hierarchy, this means that the compromise requirement to ensure adequate protection against a range
of one node attacks. This is, however, true for the description in
Section 5.2 and Section 5.3 as well. Furthermore, the key
hierarchy must client has to
make sure it does not disclose distribute (or leak) the information necessary access token to
compromise
entities other branches in the key hierarchy. Obviously, than the
compromise of intended the root of resource server. For that
purpose the key hierarchy client will compromise all of have to authenticate the keys; however, a compromise in one branch MUST NOT result in resource server
before transmitting the compromise of other branches. There are many implications access token.

5.2. Sender Constraint

Instead of
this requirement; however, two implications deserve highlighting.
First, providing confidentiality protection the scope authorization
server could also put the identifier of the keying material must be defined and
understood by all parties that communicate client into the protected
token with the following semantic: 'This token is only valid when
presented by a party that holds
that keying material. Second, a party that holds keying material
in a key hierarchy must not share that keying material with
parties that are associated client with other branches in the key
hierarchy.

Bind Key to its Context:

Keying material MUST be bound to the appropriate context. The
context includes the following.

* The manner in which following identifier.' When the keying material
access token is expected then presented to be used.

* The other parties the resource server how does it
know that are expected it was provided by the client? It has to have access authenticate the
client! There are many choices for authenticating the client to the
keying material.

*
resource server, for example by using client certificates in TLS
[RFC5246], or pre-shared secrets within TLS [RFC4279]. The expected lifetime choice of
the keying material. Lifetime of preferred authentication mechanism and credential type may depend
on a
child key SHOULD NOT be greater than the lifetime number of its parent
in the key hierarchy.

Any party with legitimate access to keying material can determine
its context. In addition, the protocol MUST ensure that all
parties with legitimate access to keying material have factors, including

o security properties

o available infrastructure
o library support

o credential cost (financial)

o performance

o integration into the same
context existing IT infrastructure

o operational overhead for the keying material. This requires that the parties
are properly identified configuration and authenticated, so that all distribution of the
parties that have access
credentials

This long list hints to the keying material can be determined.
The context will include the client and the resource server
identities in more than challenge of selecting at least one form.

Authorization Restriction:

If
mandatory-to-implement client authorization is restricted, then authentication mechanism.

5.3. Key Confirmation

A variation of the client SHOULD be
made aware mechanism of sender authentication, described in
Section 5.2, is to replace authentication with the restriction.

Client Identity Confidentiality:

A client has identity confidentiality when any party other than proof-of-
possession of a specific (session) key, i.e., key confirmation. In
this model the resource server and would not authenticate the authorization server cannot
sufficiently identify client
itself but would rather verify whether the client within knows the anonymity set. In
comparison to anonymity and pseudonymity, identity confidentiality
is concerned with eavesdroppers and intermediaries. A session
key
management protocol SHOULD provide associated with a specific access token. Examples of this property.

Resource Owner Identity Confidentiality:

Resource servers SHOULD
approach can be prevented found with the OAuth 1.0 MAC token [RFC5849], and
Kerberos [RFC4120] when utilizing the AP_REQ/AP_REP exchange (see
also [I-D.hardjono-oauth-kerberos] for a comparison between Kerberos
and OAuth).

To illustrate key confirmation the first examples borrow from knowing
Kerberos and use symmetric key cryptography. Assume that the real or
pseudonymous identity of
authorization server shares a long-term secret with the resource owner, since
server, called K(Authorization Server-Resource Server). This secret
would be established between them out-of-band. When the client
requests an access token the authorization server is creates a fresh and
unique session key Ks and places it into the only entity involved in verifying token encrypted with the
resource owner's identity.

Collusion:

Resource servers that collude can be prevented from using
information related to
long term key K(Authorization Server-Resource Server). Additionally,
the resource owner authorization server attaches Ks to track the individual.
That is, two different resource servers can be prevented from
determining that the same resource owner has authenticated response message to both
of them. Authorization servers MUST bind different keying
material the
client (in addition to access tokens used for resource servers from different
origins (or similar concepts in the app world).

AS-to-RS Relationship Anonymity:

For solutions using asymmetric key cryptography access token itself) over a
confidentiality protected channel. When the client MAY
conceal information about sends a request
to the resource server it wants has to interact
with. The authorization server MAY reject such an attempt since
it may not be able use Ks to enforce access control decisions.

Channel Binding:

A solution MUST enable support compute a keyed message
digest for channel bindings. the request (in whatever form or whatever layer). The concept
of channel binding, as defined in [RFC5056], allows applications
resource server, when receiving the message, retrieves the access
token, verifies it and extracts K(Authorization Server-Resource
Server) to establish that obtain Ks. This key Ks is then used to verify the two end-points keyed
message digest of a secure channel at one
network layer are the same as at a higher layer by binding
authentication at request message.

Note that in this example one could imagine that the higher layer mechanism to
protect the channel at the lower
layer.

There are performance concerns with the use of asymmetric
cryptography. Although token itself is based on a symmetric key cryptography offers better
performance asymmetric cryptography offers additional security
properties. A solution MUST therefore offer the capability to
support both symmetric as well as asymmetric keys.

There are threats that relate based mechanism
to the experience of the software
developer as well as operational practices. Verifying the servers
identity in TLS is discussed at length in [RFC6125].

A number of the threats listed in Section 4 demand protection of the
access token content and a standardized solution, in avoid any form of a JSON-
based format, public key infrastructure but this aspect is available with not
further elaborated in the JWT [RFC7519].

6. Threat Mitigation scenario.

A large range of threats similar mechanism can also be mitigated by protecting the content
of the token, for example designed using a digital signature or a keyed
message digest. Alternatively, the content of the token could be
passed by reference rather than by value (requiring a separate
message exchange to resolve the reference to the token content). To
simplify the subsequent description we assume that asymmetric
cryptography. When the client requests an access token itself
is digitally signed by the
authorization server creates an ephemeral public / privacy key pair
(PK/SK) and therefore cannot
be modified.

To deal with token redirect it is important for the authorization
server to include places the identifier of public key PK into the intended recipient - protected token. When
the
resource server. A resource authorization server must not be allowed to accept returns the access tokens that are not meant for its consumption.

To provide protection against token disclosure two approaches are
possible, namely (a) not to include sensitive information inside the
token or (b) to ensure confidentiality protection. The latter
approach requires at least client it
also provides the communication interaction between PK/SK key pair over a confidentiality protected
channel. When the client and sends a request to the authorization resource server as well as it
has to use the interaction
between privacy key SK to sign the client request. The resource
server, when receiving the message, retrieves the access token,
verifies it and extracts the resource server public key PK. It uses this ephemeral
public key to experience
confidentiality protection. verify the attached signature.

5.4. Summary

As an example, TLS with a ciphersuite
that offers confidentiality protection has to high level message, there are various ways how the threats can
be applied (which mitigated and while the details of each solution is
currently true for somewhat
different they all ciphersuites, except for one). Encrypting ultimately accomplish the
token content itself goal.

The three approaches are:

Confidentiality Protection:

The weak point with this approach, which is another alternative. In our scenario briefly described in
Section 5.1, is that the
authorization server would, for example, encrypt client has to be careful to whom it
discloses the token content
with a symmetric key shared access token. What can be done with the resource server.

To deal with token reuse more choices are available.

6.1. Confidentiality Protection

In this approach confidentiality protection of the exchange is
provided
entirely depends on what rights the communication interfaces between token entitles the client presenter
and what constraints it contains. A token could encode the
resource server, and between
identifier of the client and the authorization server.
No eavesdropper on but there are scenarios where the wire client
is able not authenticated to observe the token exchange.
Consequently, a replay by a third party is not possible. An
authorization resource server wants to ensure that it only hands out tokens to
clients it has authenticated first and who are authorized. For this
purpose, authentication or where the
identifier of the client to the authorization server
will be rather represents an application class
rather than a requirement to ensure adequate protection against single application instance. As such, it is
possible that certain deployments choose a range
of attacks. This is, however, true for the description in
Section 6.2 and Section 6.3 as well. Furthermore, the client has rather liberal approach
to
make sure it does not distribute (or leak) security and that everyone who is in possession of the access
token is granted access to
entities other than the intended the resource server. For that
purpose the client will have data.

Sender Constraint:

The weak point with this approach, which is briefly described in
Section 5.2, is to authenticate setup the authentication infrastructure such
that clients can be authenticated towards resource server
before transmitting the access token.

6.2. Sender Constraint

Instead of providing confidentiality protection servers.
Additionally, the authorization server could also put must encode the identifier
of the client into the protected
token with in the following semantic: 'This token is only valid when
presented for later verification by a client with the following identifier.' When resource
server. Depending on the chosen layer for providing client-side
authentication there may be additional challenges due Web server
load balancing, lack of API access token is then presented to identity information, etc.

Key Confirmation:

The weak point with this approach, see Section 5.3, is the resource server how does it
know that
increased complexity: a complete key distribution protocol has to
be defined.

In all cases above it was provided by the client? It has to authenticate the
client! There are many choices for authenticating be ensured that the client is able to
keep the
resource server, for example by using client certificates in TLS
[RFC5246], or pre-shared secrets within TLS [RFC4279]. The choice of
the preferred authentication mechanism and credential type may depend
on a number of factors, including

o credentials secret.

6. Architecture

The proof-of-possession security properties

o available infrastructure

o library support
o credential cost (financial)

o performance

o integration into concept assumes that the existing IT infrastructure

o operational overhead for configuration and distribution of
credentials

This long list hints
authorization server acts as a trusted third party that binds keys to
access tokens. These keys are then used by the challenge of selecting at least one
mandatory-to-implement client authentication mechanism.

6.3. Key Confirmation

A variation of the mechanism of sender authentication, described in
Section 6.2, is to replace authentication with demonstrate
the proof-of- possession of a specific (session) key, i.e., key confirmation. In
this model the secret to the resource server would not authenticate when accessing
the client
itself but would rather resource. The resource server, when receiving an access token,
needs to verify whether that the key used by the client knows matches the one
included in the session
key associated with a specific access token. Examples of this
approach can be found with the OAuth 1.0 MAC token [RFC5849], and
Kerberos [RFC4120] when utilizing the AP_REQ/AP_REP exchange (see
also [I-D.hardjono-oauth-kerberos] for a comparison

There are slight differences between Kerberos
and OAuth).

To illustrate key confirmation, the first example is borrowed from
Kerberos and use of symmetric key cryptography. Assume that keys and
asymmetric keys when they are bound to the
authorization server shares a long-term secret with access token and the resource
server, called K(Authorization Server-Resource Server). This secret
would be established
subsequent interaction between them out-of-band. When the client
requests an access token and the authorization
server creates a fresh and
unique session key Ks and places it into the token encrypted with when demonstrating possession of these keys. Figure 1 shows
the
long term symmetric key K(Authorization Server-Resource Server). Additionally,
the authorization server attaches Ks to the response message to the
client (in addition to procedure and Figure 2 illustrates how asymmetric
keys are used. While symmetric cryptography provides better
performance properties the access token itself) over a
confidentiality protected channel. When use of asymmetric cryptography allows the
client sends a request to keep the resource server private key locally and never expose it has to use Ks to compute any
other party.

With the JSON Web Token (JWT) [RFC7519] a keyed message
digest standardized format for the request (in whatever form or whatever layer). The
resource server, when receiving the message, retrieves the
access
token, verifies it and extracts K(Authorization Server-Resource
Server) to obtain Ks. This key Ks tokens is then used to verify the keyed
message digest of the request message.

Note that in this example one could imagine that the mechanism available. The necessary elements to
protect the token itself is based on a bind symmetric key based mechanism
or asymmetric keys to avoid any form of public key infrastructure but this aspect is not
further elaborated a JWT are described in the scenario.

A similar mechanism can also be designed using asymmetric
cryptography. When
[I-D.ietf-oauth-proof-of-possession].

Note: The negotiation of cryptographic algorithms between the client requests an access token the
authorization server creates an ephemeral public / privacy key pair
(PK/SK)
and places the public key PK into the protected token. When the authorization server returns is not shown in the access token examples below and
assumed to the client it
also provides the PK/SK key pair over be present in a confidentiality protected
channel. When protocol solution to meet the client sends a request requirements
for crypto-agility.

+---------------+
^| |
// | Authorization |
/ | Server |
// | |
/ | |
(I) // /+---------------+
Access / //
Token / /
Request // // (II) Access Token
+Params / / +Symmetric Key
// //
/ v
+-----------+ +------------+
| | | |
| | | Resource |
| Client | | Server |
| | | |
| | | |
+-----------+ +------------+

Figure 1: Interaction between the Client and the Authorization Server
(Symmetric Keys).

In order to request an access token the resource client interacts with the
authorization server as part of the a normal grant exchange, as shown
in Figure 1. However, it
has needs to include additional information
elements for use with the privacy key SK to sign PoP security mechanism, as depicted in
message (I). In message (II) the request. The resource
server, when receiving authorization server then returns
the message, retrieves requested access token. In addition to the access token,
verifies it and extracts token itself,
the public key PK. It uses this ephemeral
public symmetric key is communicated to verify the attached signature.

6.4. Summary

As client. This symmetric key
is a high level message, there are various ways unique and fresh session key with sufficient entropy for the threats can be
mitigated. While
given lifetime. Furthermore, information within the details of each solution are somewhat
different, they all accomplish access token
ties it to this specific symmetric key.

Note: For this security mechanism to work the goal of mitigating client as well as the threats.

The three approaches are:

Confidentiality Protection:

The weak point with this approach, which is briefly described in
Section 6.1, is that the client has to be careful
resource server need to whom it
discloses the have access token. What can be done with the token
entirely depends on what rights to the token entitles session key. While the presenter
and what constraints it contains. A token could encode
key transport mechanism from the
identifier of authorization server to the client but
has been explained in the previous paragraph there are scenarios where three ways for
communicating this session key from the client
is not authenticated authorization server to the
resource server or where the
identifier of server, namely

Embedding the client rather represents an application class
rather than a single application instance. As such, it is
possible that certain deployments choose a rather liberal approach
to security and that everyone who is in possession of symmetric key inside the access token is granted access to itself. This
requires that the data.

Sender Constraint:

The weak point with this approach, which is briefly described in
Section 6.2, symmetric key is to setup the authentication infrastructure such
that clients can be authenticated towards confidentiality protected.

The resource servers.
Additionally, server queries the authorization server must encode the identifier
of for the client in
symmetric key. This is an approach envisioned by the token for later verification by
introspection endpoint [I-D.ietf-oauth-introspection].

The authorization server and the resource
server. Depending on the chosen layer for providing client-side
authentication there may be additional challenges due to Web server load balancing, lack of API both have access
to identity information,
etc.

Key Confirmation:

The weak point with this approach, see Section 6.3, is the
increased complexity: a complete key distribution protocol has to
be defined.

In all cases above it has to be ensured that same back-end database. Smaller, tightly coupled systems
might prefer such a deployment strategy.

Figure 2: Interaction between the client is able to
keep Client and the credentials secret.

7. Architecture Authorization Server
(Asymmetric Keys).

The proof-of-possession security concept assumes that the
authorization server acts as a trusted third party that binds keys to
access tokens. These use of asymmetric keys are then used by is slightly different since the client to demonstrate
the possession of the secret to or
the resource server when accessing could be involved in the resource. The resource server, when receiving an access token,
needs to verify that generation of the ephemeral key used by
pair. This exchange is shown in Figure 1. If the client matches generates
the one
included in key pair it either includes a fingerprint of the access token.

There are slight differences between public key or
the use of symmetric keys and
asymmetric keys when they are bound public key in the request to the authorization server. The
authorization server would include this fingerprint or public key in
the confirmation claim inside the access token and thereby bind the
asymmetric key pair to the token. If the
subsequent interaction between the client and did not provide a
fingerprint or a public key in the request then the authorization
server when demonstrating possession of these keys. Figure 1 shows
the symmetric key procedure and Figure 2 illustrates how is asked to create an ephemeral asymmetric
keys are used. While symmetric cryptography provides better
performance properties key pair, binds the use
fingerprint of asymmetric cryptography allows the
client public key to keep the private access token, and returns the
asymmetric key locally pair (public and never expose it private key) to any
other party.

With the JSON Web Token (JWT) [RFC7519] a standardized format for
access tokens client. Note
that there is available. The necessary elements to bind symmetric
or asymmetric keys to a JWT are described in
[I-D.ietf-oauth-proof-of-possession].

Note: strong preference for generating the private/public
key pair locally at the client rather than at the server.

The negotiation of cryptographic algorithms specification describing the interaction between the client and
the authorization server is not server, as shown in the examples below Figure 1 and
assumed to in Figure 2, can
be present found in a protocol solution [I-D.ietf-oauth-pop-key-distribution].

Once the client has obtained the necessary access token and keying
material it can start to meet interact with the requirements
for crypto-agility.

7.1. Client resource server. To
demonstrate possession of the key bound to the access token it needs
to apply this key to the request by computing a keyed message digest
(i.e., a symmetric key-based cryptographic primitive) or a digital
signature (i.e., an asymmetric cryptographic computation). When the
resource server receives the request it verifies it and Authorization Server Interaction

+---------------+
| |
/
| Authorization |
(I) // /+---------------+
Access / //
Token / /
| Server |
| |
| |
+---------------+

Request // // (II) Access Token
+Params / / +Symmetric Key
// //
/ v
+-----------+ + Signature/MAC (a) +------------+
| |---------------------->| |
| |
| | [+Access Token] | Resource |
| Client | | Server |
| | Response (b) | |
| | | |<----------------------| |
+-----------+ [+ Signature/MAC] +------------+

^ ^
| |
| |
Symmetric Key Symmetric Key
or or
Asymmetric Key Pair Public Key (Client)
+ +
Parameters Parameters

Figure 1: Interaction between the 3: Client and demonstrates PoP.

The specification describing the Authorization Server
(Symmetric Keys).

In order ability to sign the HTTP request an access token
from the client interacts with to the
authorization resource server as part of the a normal grant exchange, as shown can be found in Figure 1. However, it needs
[I-D.ietf-oauth-signed-http-request].

So far the examples talked about access tokens that are passed by
value and allow the resource server to include additional information
elements for use with make authorization decisions
immediately after verifying the PoP security mechanism, as depicted in
message (I). request from the client. In message (II) some
deployments a real-time interaction between the authorization server then returns
and the requested resource server is envisioned that lowers the need to pass
self-contained access token. tokens around. In addition to that case the access token itself,
the symmetric key is communicated
merely serves as a handle or a reference to state stored at the client. This symmetric key
is
authorization server. As a unique and fresh session key with sufficient entropy for the
given lifetime. Furthermore, information within the access token
ties it to this specific symmetric key.

Note: For this security mechanism to work the client as well as consequence, the resource server need to have access to the session key. While the
key transport mechanism from the cannot
autonomously make an authorization server to the decision when receiving a request
from a client but has been explained in the previous paragraph there are three ways for
communicating this session key from the authorization server to the
resource server, namely

Embedding the symmetric key inside the access token itself. This
requires that the symmetric key is confidentiality protected.

The resource server queries consult the authorization server for the
symmetric key. server. This is an approach envisioned by can,
for example, be done using the token introspection endpoint [I-D.ietf-oauth-introspection].

The authorization server (see
[I-D.ietf-oauth-introspection]). Figure 4 shows the protocol
interaction graphically. Despite the additional token exchange
previous descriptions about associating symmetric and asymmetric keys
to the resource server both have access token are still applicable to the same back-end database. Smaller, tightly coupled systems
might prefer such a deployment strategy.

7.1.2. Asymmetric Keys this scenario.

+---------------+
Access ^| |
Access
Token Req. // | Authorization |
+Parameters |^
(I) / | Server |
+[Fingerprint] \ (IV) Token
// | | \ Introspection Req.
/ | |
(I) \ +Access
// /+---------------+ \ Token
/ // (II) \ \\
/ / (II) Access \ \
// // Access Token \ (V) \
/ / +[ephemeral \Resp.\
// // asymmetric key pair] \ \
/ v V \
+-----------+ +------------+
| | Request +Signature/MAC+------------+
| | (III) +Access Token | |
| |---------------------->| Resource |
| Client | (VI) Success or | Server |
| | Failure | |
| | | |<----------------------| |
+-----------+ +------------+

Figure 2: Interaction between the Client 4: Token Introspection and the Authorization Server
(Asymmetric Keys).

The use Access Token Handles.

7. Requirements

RFC 4962 [RFC4962] gives useful guidelines for designers of asymmetric keys is slightly different since the client or
the server could be involved in the generation of the ephemeral
authentication and key
pair. This exchange is shown management protocols. While RFC 4962 was
written with the AAA framework used for network access authentication
in Figure 1. If mind the client generates offered suggestions are useful for the key pair it either includes a fingerprint design of the public key or
the public other
key in the request management systems as well. The following requirements list
applies OAuth 2.0 terminology to the authorization server. The
authorization server would requirements outlined in RFC
4962.

These requirements include this fingerprint or public

Cryptographic Algorithm Independent:

The key in management protocol MUST be cryptographic algorithm
independent.

Strong, fresh session keys:

Session keys MUST be strong and fresh. Each session deserves an
independent session key, i.e., one that is generated specifically
for the confirmation claim inside intended use. In context of OAuth this means that keying
material is created in such a way that can only be used by the access token
combination of a client instance, protected resource, and thereby bind
authorization scope.

Limit Key Scope:

Following the
asymmetric key pair principle of least privilege, parties MUST NOT have
access to the token. If the client did keying material that is not provide a
fingerprint or a public key in the request then the authorization
server needed to perform their
role. Any protocol that is asked used to create an ephemeral asymmetric key pair, binds establish session keys MUST
specify the
fingerprint of scope for session keys, clearly identifying the public key
parties to whom the access token, and returns the
asymmetric session key pair (public and private key) to the client. Note
that there is available.

Replay Detection Mechanism:

The key management protocol exchanges MUST be replay protected.
Replay protection allows a strong preference for generating protocol message recipient to discard
any message that was recorded during a previous legitimate
dialogue and presented as though it belonged to the private/public
key pair locally at current
dialogue.

Authenticate All Parties:

Each party in the client rather than at key management protocol MUST be authenticated to
the server.

7.2. Client and Resource Server Interaction

The specification describing other parties with whom they communicate. Authentication
mechanisms MUST maintain the interaction between confidentiality of any secret values
used in the client authentication process. Secrets MUST NOT be sent to
another party without confidentiality protection.

Authorization:

Client and
the resource server authorization server, as shown in Figure 1 and in Figure 2, can MUST be found in [I-D.ietf-oauth-pop-key-distribution].

Once performed. These
entities MUST demonstrate possession of the appropriate keying
material, without disclosing it. Authorization is REQUIRED
whenever a client has obtained the necessary access token interacts with an authorization server. The
authorization checking prevents an elevation of privilege attack,
and it ensures that an unauthorized authorized is detected.

Keying Material Confidentiality and Integrity:

While preserving algorithm independence, confidentiality and
integrity of all keying material it can start to interact with the resource server. To
demonstrate possession MUST be maintained.

Confirm Cryptographic Algorithm Selection:

The selection of the "best" cryptographic algorithms SHOULD be
securely confirmed. The mechanism SHOULD detect attempted roll-
back attacks.

Uniquely Named Keys:

Key management proposals require a robust key bound naming scheme,
particularly where key caching is supported. The key name
provides a way to the access token it needs refer to apply this a key to the request by computing a keyed message digest
(i.e., a symmetric key-based cryptographic primitive) or in a digital
signature (i.e., an asymmetric cryptographic computation). When the
resource server receives the request it verifies protocol so that it and decides
whether access is clear
to the protected resource can be granted. This
exchange all parties which key is shown in Figure 3.

+---------------+
| |
| Authorization |
| Server |
| |
| |
+---------------+

Request
+-----------+ + Signature/MAC (a) +------------+
| |---------------------->| |
| | [+Access Token] | Resource |
| Client | | Server |
| | Response (b) | |
| |<----------------------| |
+-----------+ [+ Signature/MAC] +------------+

^ ^
| |
| |
Symmetric Key Symmetric Key
or or
Asymmetric Key Pair Public Key (Client)
+ +
Parameters Parameters

Figure 3: Client Demonstrates PoP.

The specification describing being referenced. Objects that cannot
be named cannot be managed. All keys MUST be uniquely named, and
the ability to sign key name MUST NOT directly or indirectly disclose the HTTP request
from keying
material.

Prevent the Domino Effect:

Compromise of a single client to MUST NOT compromise keying material
held by any other client within the system, including session keys
and long-term keys. Likewise, compromise of a single resource
server can be found in
[I-D.ietf-oauth-signed-http-request].

7.3. MUST NOT compromise keying material held by any other
Resource and Authorization Server Interaction (Token
Introspection)

So far within the examples talked about access tokens that are passed by
value and allow system. In the resource server to make authorization decisions
immediately after verifying context of a key
hierarchy, this means that the request from compromise of one node in the client. In some
deployments a real-time interaction between key
hierarchy must not disclose the authorization server
and information necessary to
compromise other branches in the resource server is envisioned that lowers key hierarchy. Obviously, the need to pass
self-contained access tokens around. In that case
compromise of the access token
merely serves as a handle or a reference to state stored at root of the
authorization server. As key hierarchy will compromise all of
the keys; however, a consequence, compromise in one branch MUST NOT result in
the resource server cannot
autonomously make an authorization decision when receiving compromise of other branches. There are many implications of
this requirement; however, two implications deserve highlighting.
First, the scope of the keying material must be defined and
understood by all parties that communicate with a request
from party that holds
that keying material. Second, a client but has to consult party that holds keying material
in a key hierarchy must not share that keying material with
parties that are associated with other branches in the authorization server. This can,
for example, key
hierarchy.

Bind Key to its Context:

Keying material MUST be done using bound to the token introspection endpoint (see
[I-D.ietf-oauth-introspection]). Figure 4 shows appropriate context. The
context includes the protocol
interaction graphically. Despite following.

* The manner in which the additional token exchange
previous descriptions about associating symmetric and asymmetric keys keying material is expected to the access token be used.

* The other parties that are still applicable expected to this scenario.

* The expected lifetime of the keying material. Lifetime of a
child key SHOULD NOT be greater than the lifetime of its parent
in the key hierarchy.

Any party with legitimate access to keying material can determine
its context. In addition, the protocol MUST ensure that all
parties with legitimate access to keying material have the same
context for the keying material. This requires that the parties
are properly identified and authenticated, so that all of the
parties that have access to the keying material can be determined.
The context will include the client and the resource server
identities in more than one form.

Authorization Restriction:

If client authorization is restricted, then the client SHOULD be
made aware of the restriction.

Client | (VI) Success Identity Confidentiality:

A client has identity confidentiality when any party other than
the resource server and the authorization server cannot
sufficiently identify the client within the anonymity set. In
comparison to anonymity and pseudonymity, identity confidentiality
is concerned with eavesdroppers and intermediaries. A key
management protocol SHOULD provide this property.

Resource Owner Identity Confidentiality:

Resource servers SHOULD be prevented from knowing the real or | Server |
| | Failure | |
| |<----------------------| |
+-----------+ +------------+

Figure 4: Token Introspection
pseudonymous identity of the resource owner, since the
authorization server is the only entity involved in verifying the
resource owner's identity.

Collusion:

Resource servers that collude can be prevented from using
information related to the resource owner to track the individual.
That is, two different resource servers can be prevented from
determining that the same resource owner has authenticated to both
of them. Authorization servers MUST bind different keying
material to access tokens used for resource servers from different
origins (or similar concepts in the app world).

AS-to-RS Relationship Anonymity:

For solutions using asymmetric key cryptography the client MAY
conceal information about the resource server it wants to interact
with. The authorization server MAY reject such an attempt since
it may not be able to enforce access control decisions.

Channel Binding:

A solution MUST enable support for channel bindings. The concept
of channel binding, as defined in [RFC5056], allows applications
to establish that the two end-points of a secure channel at one
network layer are the same as at a higher layer by binding
authentication at the higher layer to the channel at the lower
layer.

There are performance concerns with the use of asymmetric
cryptography. Although symmetric key cryptography offers better
performance asymmetric cryptography offers additional security
properties. A solution MUST therefore offer the capability to
support both symmetric as well as asymmetric keys.

There are threats that relate to the experience of the software
developer as well as operational practices. Verifying the servers
identity in TLS is discussed at length in [RFC6125].

A number of the threats listed in Section 4 demand protection of the
access token content and Access Token Handles. a standardized solution, in form of a JSON-
based format, is available with the JWT [RFC7519].

8. Security Considerations

The purpose of this document is to provide use cases, requirements,
and motivation for developing an OAuth security solution extending
Bearer Tokens. As such, this document is only about security.

9. IANA Considerations

This document does not require actions by IANA.

10. Acknowledgments

This document is the result of conference calls late 2012/early 2013
and in design team conference calls February 2013 of the IETF OAuth
working group. The following persons (in addition to the OAuth WG
chairs, Hannes Tschofenig, and Derek Atkins) provided their input
during these calls: Bill Mills, Justin Richer, Phil Hunt, Prateek
Mishra, Mike Jones, George Fletcher, Leif Johansson, Lucy Lynch, John
Bradley, Tony Nadalin, Klaas Wierenga, Thomas Hardjono, Brian
Campbell

In the appendix of this document we reuse re-use content from [RFC4962] and
the authors would like thank Russ Housely and Bernard Aboba for their
work on RFC 4962.

We would like to thank Reddy Tirumaleswar for his review.

11. References

11.1. Normative References

[I-D.ietf-oauth-introspection]
Richer, J., "OAuth 2.0 Token Introspection", draft-ietf-
oauth-introspection-11 (work in progress), July 2015.

[I-D.ietf-oauth-pop-key-distribution]
Bradley, J., Hunt, P., Jones, M., and H. Tschofenig,
"OAuth 2.0 Proof-of-Possession: Authorization Server to
Client Key Distribution", draft-ietf-oauth-pop-key-
distribution-01 (work in progress), March 2015.

[I-D.ietf-oauth-proof-of-possession]
Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)",
draft-ietf-oauth-proof-of-possession-04 (work in
progress), August 2015.

[I-D.ietf-oauth-signed-http-request]
Richer, J., Bradley, J., and H. Tschofenig, "A Method for
Signing an HTTP Requests for OAuth", draft-ietf-oauth-
signed-http-request-01 (work in progress), March 2015.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, 10.17487/
RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.

[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<http://www.rfc-editor.org/info/rfc6749>.

[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://www.rfc-editor.org/info/rfc7519>.

11.2. Informative References

[I-D.hardjono-oauth-kerberos]
Hardjono, T., "OAuth 2.0 support for the Kerberos V5
Authentication Protocol", draft-hardjono-oauth-kerberos-01
(work in progress), December 2010.

[I-D.ietf-oauth-introspection]
Richer, J., "OAuth 2.0 Token Introspection", draft-ietf-
oauth-introspection-11 (work in progress), July 2015.

[NIST800-63]
Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S.,
and E. Nabbus, "NIST Special Publication 800-63-1,
INFORMATION SECURITY", December 2008.

[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
DOI 10.17487/RFC4120, July 2005,
<http://www.rfc-editor.org/info/rfc4120>.

[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)", RFC
4279, DOI 10.17487/RFC4279, December 2005,
<http://www.rfc-editor.org/info/rfc4279>.

[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management", BCP
132, RFC 4962, DOI 10.17487/RFC4962, July 2007,
<http://www.rfc-editor.org/info/rfc4962>.

[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
<http://www.rfc-editor.org/info/rfc5056>.

[RFC5849] Hammer-Lahav, E., Ed., "The OAuth 1.0 Protocol", RFC 5849,
DOI 10.17487/RFC5849, April 2010,
<http://www.rfc-editor.org/info/rfc5849>.

[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <http://www.rfc-editor.org/info/rfc6125>.

[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, 10.17487/
RFC6750, October 2012,
<http://www.rfc-editor.org/info/rfc6750>.

[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819, DOI
10.17487/RFC6819, January 2013,
<http://www.rfc-editor.org/info/rfc6819>.

Authors' Addresses

Phil Hunt (editor)
Oracle Corporation

Email: phil.hunt@yahoo.com

Justin Richer

Email: ietf@justin.richer.org

William Mills

Email: wmills@yahoo-inc.com

Prateek Mishra
Oracle Corporation

Email: prateek.mishra@oracle.com
Hannes Tschofenig
ARM Limited
Hall in Tirol 6060
Austria

Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at