OAUTH H. Tschofenig
Internet-Draft Nokia Siemens Networks
Intended status: Informational B. Cook
Expires: April 21, 2011 BT
October 18, 2010
Thoughts about Digital Signatures for the Open Web Authentication
(OAuth) Protocol
draft-tschofenig-oauth-signature-thoughts-00.txt
Abstract
The initial version of the Open Web Authentication Protocol (OAuth
1.0), often referred to as the community addition, included an
mechanism for putting a digital signature (when using asymmetric
keys) or a keyed message digest (when using symmetric keys) to a
resource request when presenting the OAuth token. This cryptographic
mechanism has lead to lots of discussions, particularly about the
problems implementers had, the use cases it supports, and the
benefit-cost tradeoff.
This document tries to describe the use of the so-called 'OAuth
Signature' mechamism in an unbiased and less emotional way with the
main purpose to conclude the discussions.
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 April 21, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Tschofenig & Cook Expires April 21, 2011 [Page 1]
Internet-Draft Signatures for OAuth October 2010
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Security Threats . . . . . . . . . . . . . . . . . . . . . . . 6
4. Threat Mitigation . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Confidentiality Protection . . . . . . . . . . . . . . . . 7
4.2. Sender Constraint . . . . . . . . . . . . . . . . . . . . 8
4.3. Key Confirmation . . . . . . . . . . . . . . . . . . . . . 8
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Operational Considerations . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Tschofenig & Cook Expires April 21, 2011 [Page 2]
Internet-Draft Signatures for OAuth October 2010
1. Introduction
The initial version of the Open Web Authentication Protocol (OAuth
1.0) included an mechanism for putting a digital signature (when
using asymmetric keys) or a keyed message digest (when using
symmetric keys) to a resource request when presenting the OAuth
token. OAuth 2.0 generalized the structure a bit and the abstract
and simplified description of the protocol has the following
structure:
,-.
(* *)
`+' User
'
:------------ ---|--- ~~~~~~~~~~:
: Service / \ : Management
: Interaction / \ : of Resources
: : Consent :
: : :
: : :
: +---:-+ Carol :
: 1. |Carol| as :
: Obtain .'>| | Asserting :
: Access .' +-----+ Party :
: Token.' :
: .' :
: .' :
: v' :
+-:---+ +--:--+ Bob
|Alice|<------------------------->|Bob | as
| | 2. Authenticated | | Relying
+-----+ Request + +-----+ Party
Access Token
Figure 1: OAuth Simplified
We use symbolic names in Figure 1. A few remarks about the figure.
In addition to illustrating the message exchange between Alice, Bob,
and Carl it also highlights the importance of the user in the
exchange in providing consent, triggering the entire interaction as
part of invoking a service, and in managing a resource that is work
delegating access to.
From a cryptographic point of view the following aspects of the OAuth
1.0 specification are worth mentioning:
Tschofenig & Cook Expires April 21, 2011 [Page 3]
Internet-Draft Signatures for OAuth October 2010
o The format and content of the Access Token is not specified.
o The authenticated request shown in (2) is essentially a basic HTTP
authentication mechanism that supports symmetric as well as
asymmetric credentials. The purpose is to authenticate Alice to
Bob; no mutual authentication. The procedure for obtaining these
credentials is outside the scope. To ensure liveness of the
authentication a timestamp and a nonce is included in the request
(and is included in the digital signature and the keyed message
digest).
o The authenticated request signing is optional to implement and
optional to use. When the authenticated request signature is
omitted (called bearer token) then TLS. Details about what
ciphersuite to use with TLS and what required features are needed
are not available.
OAuth 2.0 [I-D.ietf-oauth-v2] currently does not provide text for
authenticated requests in the specification nor does it mandate the
use of TLS.
Tschofenig & Cook Expires April 21, 2011 [Page 4]
Internet-Draft Signatures for OAuth October 2010
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses the terminology defined in RFC 4949 [RFC4949].
The terms 'keyed hash' and 'keyed message digest' are used
interchangable.
All discussions in this document refer to the abstract names, namely
Alice, Bob, and Carol, shown in Figure 1.
Tschofenig & Cook Expires April 21, 2011 [Page 5]
Internet-Draft Signatures for OAuth October 2010
3. Security Threats
The following list presents several common threats against protocols
utilizing some form of 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 registration and authentication.
Token manufacture/modification: An attacker may generate a bogus
token or modify the token content (such as the authentication or
attribute statements) of an existing token, causing Bob to grant
inappropriate access to the Alice. For example, an attacker may
modify the token to extend the validity period; Alice may modify
the assertion to have access to information that they should not
be able to view.
Token disclosure: Tokens may contain authentication and attribute
statements that include sensitive information.
Token redirect: An attacker uses the token generated for consumption
by Bob to obtain access to a second Relying Party.
Token reuse: An attacker attempts to use a token that has already
been used once with Bob.
A Web authentication protocol must provide a consistent story on how
to deal with all these threats. We excluded one threat from the
list, namely 'token repudiation'. Token repudiation refers to a
property whereby Bob is given an assurance that Carol cannot deny to
have created a token for Alice. We believe that such a property is
interesting from theoretical point of view but most deployments
perfer to deal with the violation of this security property via
business actions rather than using cryptography.
Tschofenig & Cook Expires April 21, 2011 [Page 6]
Internet-Draft Signatures for OAuth October 2010
4. Threat Mitigation
A large range of threats can be mitigated by protecting the content
of the token, using a digitial 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 the token itself is digitally
signed by Carol and therefore cannot be modified. This also provides
the basis for non-repudiation.
To deal with token redirect it is important for Carol to include the
identity of the intended recipient, namely Bob. Carol would have to
be told that Bob is the intended recipient.
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
feature requires at least the communication interaction between the
Alice and Carol as well as the interaction between Alice and Bob to
experience confidentiality protection. As an example, Transport
Layer Security with a ciphersuite that offers confidentiality
protection has to be applied. Encrypting the token content is
another alternative.
To deal with the last threat, namely token reuse, more choices are
available. First, it is highly advisable for Carol to restrict the
lifetime of the token by putting a validity time field inside the
protected part of the token. This is, however, largely independent
of the potential approaches described in the sub-sections below.
4.1. Confidentiality Protection
In this approach confidentiality protection of the exchange is
provided on the communication interfaces between Alice and Bob, and
Alice and Carol. No eavesdropper on the wire is able to observe the
token exchange. Consequently, a replay is not possible. Carol wants
to ensure that it only hands out tokens to entities it has
authenticated first and who are authorized. For this purpose,
authentication of Alice to Carol will be a requirement. This is,
however, true for the description in Section 4.2 and Section 4.3 as
well. Furthermore, Alice has to make sure it does not distribute the
token to entities other than Bob. For that purpose Alice will have to
authenticate Bob before transmitting the token.
Tschofenig & Cook Expires April 21, 2011 [Page 7]
Internet-Draft Signatures for OAuth October 2010
4.2. Sender Constraint
Instead of providing confidentiality protection Carl could also put
the identity of Alice into the protected token with the following
semantic: 'This token is only valid when presented by Alice.' When
the token is then presented to Bob how does he know that it was
provided by Alice? He has to authenticate Alice! There are many
choices for authenticating Alice to Bob, such as, client-side
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 security properties
o available infrastructure
o library support
o credential cost (financial)
o performance
o integration into the existing IT infrastructure
o operational overhead for configuration and distribution of
credentials
This long list hints to the challenge of selecting at least one
mandatory-to-implement mechanism.
4.3. Key Confirmation
A variation of the mechanism of sender authentication described in
Section 4.2 is to replace authentication with the proof-of-possession
of a specific key, i.e. key confirmation. In this model Bob would
not authenticate Alice but would rather verify whether Alice knows a
secret. This mechanism corresponds to the message signature approach
defined by the OAuth 1.0 signature mechanisms [RFC5849] or by
Kerberos [RFC4120] when utilizing the AP_REQ/AP_REP exchange (see
[I-D.hardjono-oauth-kerberos] for a comparision between Kerberos and
OAuth).
To illustrate key confirmation the first examples borrows from
Kerberos and symmetric key cryptography. Assume that Carol shares a
long-term secret with Bob, called K(Carol-Bob). This secret would be
established between them in an initial registration phase outside the
scope of the actual protocol run. When Alice requests a token Carol
creates a fresh and unique key Ks and places it into the token
Tschofenig & Cook Expires April 21, 2011 [Page 8]
Internet-Draft Signatures for OAuth October 2010
encrypted with K(Carol-Bob). Additionally, Carol attaches Ks when it
sends the token to Alice over a confidentialy protected channel.
When Alice sends a request to Bob it has to use Ks to sign the
request (in whatever form or whatever layer). Bob, when receiving
the message, retrieves the token, verifies it and uses K(Carol-Bob)
to decrypt Ks and to verify the signature.
Note that in this example one could imagine that the mechanism to
protect the token itself is based on a symmetric key based mechanism
to avoid any form of public key infrastructure but this aspect is not
further eleborated in the scenario.
A similar mechanism can also be designed using asymmetric
cryptography. When Alice requests a token Carol creates an ephemeral
public / privacy key pair PK/SK and places the public key PK into the
protected token. When Carol returns the token to Alice it also
provides the PK/SK key pair over a confidentialy protected channel.
When Alice sends a request to Bob it has to use the privacy key SK to
sign the request. Again, the details are secondary. Bob, when
receiving the message, retrieves the token, verifies it and extracts
the public key PK. It uses this ephemeral public key to verify the
attached signature.
Tschofenig & Cook Expires April 21, 2011 [Page 9]
Internet-Draft Signatures for OAuth October 2010
5. Summary
In the design of the OAuth security mechanisms the following design
decisions have to be made:
Threats: Section 3 lists a few security threats. Are these the
threats you care about? Are threats missing?
Threat Mitigation: Section 4 illustrates how to address the threats
listed in Section 3. Do you agree that these are the approaches
to address the threats? Do you agree that the three approaches to
address token re-use (see Section 4.1, Section 4.2, and
Section 4.3) are roughly equivalent from a security point of view
(even though they are not equivalent from an operational
perspective)?
Token Protection and Token Content: Do you agree that many security
properties are dependent on the token content and the token
protection?
Tschofenig & Cook Expires April 21, 2011 [Page 10]
Internet-Draft Signatures for OAuth October 2010
6. Operational Considerations
It is worth pointing out that the operational aspects in the
deployment of OAuth have an impact on the design. While the authors
believe that the three approaches to address token re-use are
equivalent there are operational challenges with each of them. The
purpose of the discussion in this section is therefore to determine,
which approach encourages good practices that lead to better security
of the overall system based on the most likely behavior of its
actors.
The three approaches are:
Confidentiality Protection: The weak point with this approach, see
Section 4.1, is that Alice has to be careful to whom she discloses
the token. Everyone who is in possession of the token is granted
access to the data. Furthermore, Alice has to trust Bob to secure
the token at rest; unauthorized disclosure could be harmful
particularly when the token has a rather long lifetime.
Intiuitively, one would argue that tokens are easy to mint and
used for a small time duration only.
Sender Constraint: The weak point with this approach, see
Section 4.2, is to setup the authentication infrastructure such
that Alice can be authenticated towards Bob. Additionally, Carol
to correctly encode Alice's identity in the token for verification
by Bob. Depending on the chosen layer for providing client-side
authentication there may be additional challenges due Web server
load balancing, lack of API access to identity information, etc.
Key Confirmation: The weak point with this approach, see
Section 4.3, is the increased complexity: a key distribution
protocol has to be defined.
Tschofenig & Cook Expires April 21, 2011 [Page 11]
Internet-Draft Signatures for OAuth October 2010
7. Security Considerations
The main focus of this document is on security. Nevertheless, the
authors would like to point out that the design of the stoken
encoding and token content is currently not standardized. While this
motivated by the current OAuth deployment environment and the desire
to offer flexibility there are concerns about the ability of those
deploying OAuth making reasonable design choices. We recommend to
consult 'How to Implement Secure (Mostly) Stateless Tokens'
[I-D.rescorla-stateless-tokens] before designing a custom token
format.
RFC 4962 [RFC4962] gives useful guidelines for designers of key
management protocols. While the document was written with the AAA
framework and network access authentication in mind the offered
suggestions are useful for the design of OAuth and particularly
interesting for solutions belonging to the 'key confirmation' class.
These requirements include
1. Cryptographic algorithm independent
2. Strong, fresh session keys
3. Limit key scope
4. Replay detection mechanism
5. Authenticate all parties
6. Keying material confidentiality and integrity
7. Confirm ciphersuite selection
8. Uniquely named keys
9. Prevent the Domino effect
10. Bind key to its context
11. Confidentiality of identity
12. Authorization restriction
The authors believe it is useful to consider these requirements in
the protocol design since the 'token' terminology seems to implicitly
suggest to hand out cryptographic keying material and meta-data for
usage in multiple, potentially unbounded contexts, with a (very) long
lifetime.
Tschofenig & Cook Expires April 21, 2011 [Page 12]
Internet-Draft Signatures for OAuth October 2010
8. Conclusion
The authors argue that the best approach for providing security for
OAuth is to
1. describe security threats similar to the writeup in Section 3.
2. offer recommendations for the protection and the content of the
token. A document with a detailed description of the token
encoding and the token content (including security protection) is
likely to provide users with help in designing their own custom
extensions. This document does not need to be part of the OAuth
2.0 base specification. [I-D.rescorla-stateless-tokens] and the
Kerberos Token format [RFC4120] will provide valuable source of
inspiration.
3. define a mandatory-to-implement solution based on 'key
confirmation' (using symmetric keys) since it provides the fewest
number of operational drawbacks. A symmetric key based approach
was chosen because of performance reasons even though it requires
Carol and Bob to share a long-term secret. It is highly
recommended to compare the design against the requirements
outlined in [RFC4962].
4. strongly recommend the usage of TLS between Alice and Bob mainly
for the additional security services TLS provides, such as
confidentiality protection. TLS will be useful for access to
protected resources for the exchange of sensitive information.
In case that server-side authentication is a concern the usage of
channel bindings [RFC5056] should be investigated since they
allow binding an anonymous Diffie-Hellman exchange during the TLS
handshake with the high-layer security exchange.
Tschofenig & Cook Expires April 21, 2011 [Page 13]
Internet-Draft Signatures for OAuth October 2010
9. IANA Considerations
This document does not require actions by IANA.
Tschofenig & Cook Expires April 21, 2011 [Page 14]
Internet-Draft Signatures for OAuth October 2010
10. Acknowledgments
The authors would like to thank the OAuth working group for their
discussion input.
Tschofenig & Cook Expires April 21, 2011 [Page 15]
Internet-Draft Signatures for OAuth October 2010
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[I-D.ietf-oauth-v2]
Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth
2.0 Protocol", draft-ietf-oauth-v2-10 (work in progress),
July 2010.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007.
11.2. Informative References
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279,
December 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[I-D.hardjono-oauth-kerberos]
Hardjono, T., "OAuth 2.0 support for the Kerberos V5
Authentication Protocol", draft-hardjono-oauth-kerberos-00
(work in progress), June 2010.
[I-D.rescorla-stateless-tokens]
Rescorla, E., "How to Implement Secure (Mostly) Stateless
Tokens", draft-rescorla-stateless-tokens-01 (work in
progress), March 2007.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007.
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
April 2010.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
Tschofenig & Cook Expires April 21, 2011 [Page 16]
Internet-Draft Signatures for OAuth October 2010
[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.
Tschofenig & Cook Expires April 21, 2011 [Page 17]
Internet-Draft Signatures for OAuth October 2010
Authors' Addresses
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Blaine Cook
BT
Ireland
Email: romeda@gmail.com
Tschofenig & Cook Expires April 21, 2011 [Page 18]