<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC5849 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5849.xml">
<!ENTITY RFC4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY I-D.ietf-oauth-v2 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-v2.xml">
<!ENTITY RFC4279 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4279.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC4120 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml">
<!ENTITY RFC5056 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5056.xml">
<!ENTITY I-D.hardjono-oauth-kerberos SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hardjono-oauth-kerberos.xml">
<!ENTITY I-D.rescorla-stateless-tokens SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rescorla-stateless-tokens.xml">
<!ENTITY RFC4962 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4962.xml">

]>
<rfc category="info" docName="draft-tschofenig-oauth-signature-thoughts-00.txt" ipr="trust200902">
  <front>
    <title abbrev="Signatures for OAuth">Thoughts about Digital Signatures for the Open Web Authentication
    (OAuth) Protocol</title>   
    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization>Nokia Siemens Networks</organization>
      <address>
        <postal>
          <street>Linnoitustie 6</street>
          <city>Espoo</city>
          <code>02600</code>
          <country>Finland</country>
        </postal>
        <phone>+358 (50) 4871445</phone>
        <email>Hannes.Tschofenig@gmx.net</email>
        <uri>http://www.tschofenig.priv.at</uri>
      </address>
    </author>
    
    <author initials="B." surname="Cook" fullname="Blaine Cook">
      <organization>BT</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <code></code>
          <country>Ireland</country>
        </postal>
        <email>romeda@gmail.com</email>
      </address>
    </author>
    <date year="2010"/>
    <area>Applications Area</area>
    <workgroup>OAUTH</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>OAuth</keyword>
    <keyword>Open Web Authentication</keyword>
    <keyword>Signatures</keyword>
    <keyword>Security</keyword>
    <keyword>Message Authentication</keyword>
    <abstract>
      <t>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. </t>
      
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section anchor="introduction" title="Introduction">

    <t>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:
      
          <figure anchor="oauth-simplified" title="OAuth Simplified">
            <artwork>
              <![CDATA[
                      ,-.
                     (* *)
                      `+'  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
                  
                  ]]></artwork>
          </figure>
        </t>
<t>We use symbolic names in <xref target="oauth-simplified"/>. 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.</t>

<t>From a cryptographic point of view the following aspects of the OAuth 1.0 specification are worth mentioning:

<list style="symbols">
<t>The format and content of the Access Token is not specified.</t>
<t>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).</t>
<t>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. </t>
</list>
</t>

<t>OAuth 2.0 <xref target="I-D.ietf-oauth-v2"/> currently does not provide text for authenticated requests in the specification nor does it mandate the use of TLS.</t>

    </section>

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section anchor="terminology" title="Terminology">

      <t>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 <xref target="RFC2119"/>.</t>

<t>This document uses the terminology defined in RFC 4949 <xref target="RFC4949"/>. The terms 'keyed hash' and 'keyed message digest' are used interchangable.
</t>

<t>All discussions in this document refer to the abstract names, namely Alice, Bob, and Carol, shown in <xref target="oauth-simplified"/>.</t>
    </section>


    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section anchor="threats" title="Security Threats">
   
   <t>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 <xref target="NIST800-63"/>. We exclude a discussion of threats related to any form of registration and authentication.</t>
   <t><list style="hanging">
   <t hangText="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.</t>
   <t hangText="Token disclosure:">Tokens may contain authentication and attribute statements that include sensitive information.</t>
<!--    <t hangText="Token repudiation:">A token may be repudiated if the proper mechanisms are not in place.</t> -->
   <t hangText="Token redirect:">An attacker uses the token generated for consumption by Bob to obtain access to a second Relying Party.</t>   <t hangText="Token reuse:"> An attacker attempts to use a token that has already been used once with Bob.</t>
</list> 
</t>
   <t>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.</t>
</section> 

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

<section anchor="mitigation" title="Threat Mitigation"> 

<t>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.</t>

<t>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.</t>

<t>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. 
</t>

<t>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. </t>

<section anchor="confidentiality" title="Confidentiality Protection">

<t>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 <xref target="intended"/> and <xref target="confirmation"/> 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.
</t>

</section> 

<section anchor="intended" title="Sender Constraint">

<t>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 <xref target="RFC5246"/>, or pre-shared secrets within TLS <xref target="RFC4279"/>. The choice of the preferred authentication mechanism and credential type may depend on a number of factors, including <list style="symbols"> 
<t>security properties</t>
<t>available infrastructure</t>
<t>library support</t>
<t>credential cost (financial)</t>
<t>performance</t>
<t>integration into the existing IT infrastructure</t>
<t>operational overhead for configuration and distribution of credentials</t>
</list> 
</t>
<t>This long list hints to the challenge of selecting at least one mandatory-to-implement mechanism.</t>

</section> 

<section anchor="confirmation" title="Key Confirmation">

<t>A variation of the mechanism of sender authentication described in <xref target="intended"/> 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 <xref target="RFC5849"/> or by Kerberos <xref target="RFC4120"/> when utilizing the AP_REQ/AP_REP exchange (see <xref target="I-D.hardjono-oauth-kerberos"/> for a comparision between Kerberos and OAuth).</t>

<t>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 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.  
</t>
<t>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.</t>

<t>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.</t>
</section> 
 
    </section>



    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section anchor="summary" title="Summary">
   
   <t>In the design of the OAuth security mechanisms the following design decisions have to be made: 
   <list style="hanging">
   
   <t hangText="Threats:"> <xref target="threats"/> lists a few security threats. Are these the threats you care about? Are threats missing?</t>

<t hangText="Threat Mitigation:"> <xref target="mitigation"/> illustrates how to address the threats listed in <xref target="threats"/>. 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 <xref target="confidentiality"/>, <xref target="intended"/>, and <xref target="confirmation"/>) are roughly equivalent from a security point of view (even though they are not equivalent from an operational perspective)?   
</t>

<t hangText="Token Protection and Token Content:"> Do you agree that many security properties are dependent on the token content and the token protection?</t>
</list>
</t>

    </section>
    <!-- ////////////////////////////////////////////////////////////////////////////////// -->


    <section anchor="ops-cons" title="Operational Considerations">

   <t>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.</t>
   
   <t>The three approaches are: <list style="hanging">
   
   <t hangText="Confidentiality Protection:">The weak point with this approach, see <xref target="confidentiality"/>, 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.</t>
   <t hangText="Sender Constraint:">The weak point with this approach, see <xref target="intended"/>, 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. 
</t>
   <t hangText="Key Confirmation:">The weak point with this approach, see <xref target="confirmation"/>, is the increased complexity: a key distribution protocol has to be defined.  
  </t>
   </list> 
   </t>

    </section> 

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section anchor="sec-cons" title="Security Considerations">
   
   <t>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' <xref target="I-D.rescorla-stateless-tokens"/> before designing a custom token format.</t>
   
   <t>RFC 4962 <xref target="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 
   <list style="numbers">
   <t>Cryptographic algorithm independent</t>
   <t>Strong, fresh session keys</t>
   <t>Limit key scope</t>
   <t>Replay detection mechanism</t>
   <t>Authenticate all parties</t>
   <t>Keying material confidentiality and integrity</t>
   <t>Confirm ciphersuite selection</t>
   <t>Uniquely named keys</t>
   <t>Prevent the Domino effect</t>
   <t>Bind key to its context</t>
   <t>Confidentiality of identity</t>
   <t>Authorization restriction</t>
   </list>
   </t>
   <t>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.</t>
    </section>


    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section anchor="conclusion" title="Conclusion">

    <t>The authors argue that the best approach for providing security for OAuth is to 
    <list style="numbers">
    <t>describe security threats similar to the writeup in <xref target="threats"/>.</t>
    <t>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. <xref target="I-D.rescorla-stateless-tokens"/> and the Kerberos Token format <xref target="RFC4120"/> will provide valuable source of inspiration. 
    </t>
    <t>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 <xref target="RFC4962"/>.</t>
    <t>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 <xref target="RFC5056"/> should be investigated since they allow binding an anonymous Diffie-Hellman exchange during the TLS handshake with the high-layer security exchange.</t>
    </list>
    </t>
    </section>



    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section anchor="iana" title="IANA Considerations">

    <t>This document does not require actions by IANA.</t>
    
    </section>

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section title="Acknowledgments">
      <t>The authors would like to thank the OAuth working group for their discussion input.</t>
    </section>

  </middle>

  <!-- ////////////////////////////////////////////////////////////////////////////////// -->

  <back>
    <references title="Normative References">
      <reference anchor="RFC2119">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="Scott Bradner" initials="S." surname="Bradner">
            <organization>Harvard University</organization>
          </author>
          <date month="March" year="1997"/>
        </front>
        <format octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt" type="TXT"/>
      </reference>
      
 &RFC5948; &I-D.ietf-oauth-v2; &RFC4949;
 
 </references>

    <references title="Informative References">
    
&RFC4279;
&RFC5246;
&RFC4120;
&I-D.hardjono-oauth-kerberos;
&I-D.rescorla-stateless-tokens;
&RFC4962;
&RFC5849;
&RFC5056;

    <reference anchor="NIST800-63">
        <front>
          <title>NIST Special Publication 800-63-1, INFORMATION SECURITY</title>
          <author fullname="William E. Burr" initials="W." surname="Burr">
            <organization>NIST</organization>
          </author>
          <author fullname="Donna F. Dodson" initials="D." surname="Dodson">
            <organization>NIST</organization>
          </author>
          <author fullname="Ray A. Perlner" initials="R." surname="Perlner">
            <organization>NIST</organization>
          </author>
          <author fullname="W. Timothy Polk" initials="T." surname="Polk">
            <organization>NIST</organization>
          </author>
          <author fullname="Sarbari Gupta" initials="S." surname="Gupta">
            <organization>NIST</organization>
          </author>
          <author fullname="Emad A. Nabbus" initials="E." surname="Nabbus">
            <organization>NIST</organization>
          </author>
          <date month="December" year="2008"/>
        </front>
        <format target="http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-63-Rev.%201" type="HTML"/>
     </reference>
          
     </references> 
  </back>
</rfc>
