[Search] [txt|html|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]