Port Control Protocol (PCP) Extension for Port Set Allocation
draft-ietf-pcp-port-set-11

Web Authorization Protocol (oauth)                   T. Lodderstedt, Ed.
Internet-Draft                                       Deutsche Telekom AG
Intended status: Informational                                M. McGloin
Expires: August 22, 2012                                             IBM
                                                                 P. Hunt
                                                      Oracle Corporation
                                                       February 19, 2012

           OAuth 2.0 Threat Model and Security Considerations
                   draft-ietf-oauth-v2-threatmodel-02

Abstract

   This document gives security considerations based on a comprehensive
   threat model for the OAuth 2.0 Protocol.

Requirements Language

   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].

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 August 22, 2012.

Copyright Noticequot;OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

4.  The PORT_SET Option

   Option Name:  PORT_SET

   Number:  TBD

   Purpose:  To map sets of ports.

   Valid for Opcodes:  MAP

   Length:  5 bytes

   May appear in:  Both requests and responses

   Maximum occurrences:  1

   The PORT_SET Option indicates that the PCP client wishes to reserve a
   set of ports.  The requested number of ports in that set is indicated
   in the option.

   The maximum occurrences of the PORT_SET Option should be limited to
   1.  The reason is that the suggested external port set depends on the
   data contained in the MAP Opcode header.  Having two PORT_SET options
   with a single MAP Opcode header would imply having two overlapping
   suggested external port sets.

   Note that the option number is in the "optional to process" range
   (128-191), meaning that a MAP request with a PORT_SET option will be
   interpreted by a PCP server that does not support PORT_SET as a
   single-port MAP request, as if the PORT_SET option was absent.

   The PORT_SET Option is formatted as shown in Figure 1.

Sun, et al.              Expires April 16, 2016                 [Page 5]
Internet-Draft                PCP PORT_SET                  October 2015

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Option Code=TBD|   Reserved    |        Option Length=5        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Port Set Size          |      First Internal Port      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Reserved   |P|
   +-+-+-+-+-+-+-+-+

                         Figure 1: PORT_SET Option

   The fields are as follows:

   Port Set Size:  Number of ports requested.  MUST NOT be zero.

   First Internal Port:  In a request, this field MUST be set equal to
      the Internal Port field in the MAP opcode by the PCP client.  In a
      response, this field indicates the first internal port of the port
      set mapped by the PCP server, which may differ from the value sent
      in the request.  That is to be contrasted to the Internal Port
      field, which by necessity is always identical in matched requests
      and responses.

   Reserved:  MUST be set to zero when sending, MUST be ignored when
      receiving.

   P: 1 if parity preservation is requested, 0 otherwise.  See
      [RFC4787], Section 4.2.2.

   The Internal Port Set is defined as being the range of Port Set Size
   ports starting from the First Internal Port.  The External Port Set
   is respectively defined as being the range of Port Set Size ports
   starting from the Assigned External Port.  The two ranges always have
   the same size (i.e., the Port Set Size returned by the PCP server).

   The Suggested External Port corresponds to the first port in the
   Assigned External Port Set. Its purpose is for clients to be able to
   regenerate previous mappings after state loss.  When such an event
   happens, clients may attempt to regenerate identical mappings by
   suggesting the same External Port Set as before the state loss.  Note
   that there is no guarantee that the allocated External Port Set will
   be the one suggested by the client.  In particular, the
   PREFER_FAILURE option MUST NOT be present in a request that contains
   a PORT_SET option.

Sun, et al.              Expires April 16, 2016                 [Page 6]
Internet-Draft                PCP PORT_SET                  October 2015

4.1.  Client Behavior

   To retrieve a set of ports, the PCP client adds a PORT_SET option to
   its PCP MAP request.  If port preservation is required, the PCP
   Client MUST set the parity bit (to 1) to ask the PCP server to
   preserve the port parity.

   The PCP Client MUST NOT include more than one PORT_SET option in a
   MAP request.  If several port sets are needed, the PCP client MUST
   issue separate MAP requests, each potentially including a PORT_SET
   option.  These individual MAP requests MUST include distinct Internal
   Port.

   If the PCP Client does not know the exact number of ports it
   requires, it MAY then set the Port Set Size to 0xffff, indicating
   that it is willing to accept as many ports as the PCP server can
   offer.

   When the PCP-controlled device supports multiple port-sets delegation
   for a given PCP client, the PCP client MAY re-initiate a PCP request
   to get another port set when it has exhausted all the ports within
   the port-set.

4.2.  Server Behavior

   In addition to regular MAP request processing, the following checks
   are made upon receipt of a PORT_SET option with non-zero Requested
   Lifetime:

   o  If multiple PORT_SET options are present in a single MAP request,
      a MALFORMED_OPTION error is returned.

   o  If the Port Set Size is zero, a MALFORMED_OPTION error is
      returned.

   PREFER_FAILURE MUST NOT appear in a request with PORT_SET option.  As
   a reminder PREFER_FAILURE was specifically designed for the Universal
   Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol
   Interworking Function (IGD-PCP IWF) [RFC6970].  The reasons for not
   recommending the use of PREFER_FAILURE are discussed in Section 13.2
   of [RFC6887].  The PCP server MAY map fewer ports than the value of
   Port Set Size from the request.  It MUST NOT map more ports than the
   PCP client asked for.  Internal ports outside the range of Port Set
   Size ports starting from the Internal Port MUST NOT be mapped by the
   PCP server.

Sun, et al.              Expires April 16, 2016                 [Page 7]
Internet-Draft                PCP PORT_SET                  October 2015

   If the requested port set cannot be fully satisfied, the PCP server
   SHOULD map as many ports as possible, and SHOULD map at least one
   port (which is the same behavior as if Port Set Size is set to 1).

   If the PCP server ends up mapping only a single port, for any reason,
   the PORT_SET option MUST NOT be present in the response.

   If the port parity preservation is requested (P = 1), the PCP server
   MAY preserve port parity.  In that case, the External Port is set to
   a value having the same parity as the First Internal Port.

   If the mapping is successful, the MAP response's Assigned External
   Port is set to the first port in the External Port Set, and the
   PORT_SET option's Port Set Size is set to number of ports in the
   mapped port set.  The First Internal Port field is set to the first
   port in the Internal Port Set.

4.3.  Absence of Capability Discovery

   A PCP client that wishes to make use of a port set unconditionally
   includes the PORT_SET option.  If no PORT_SET option is present in
   the response, the PCP client cannot conclude that the PCP server does
   not support the PORT_SET option.  It may just be that the PCP server
   does support PORT_SET but decided to allocate only a single port, for
   reasons that are its own.  If the client wishes to obtain more ports,
   it MAY send additional MAP requests (see Section 6.4), which the PCP
   server may or may not grant according to local policy.

   If port set capability is added to or removed from a running PCP
   server, the server MAY reset its Epoch time and send an ANNOUNCE
   message as described in the PCP specification ([RFC6887],
   Section 14.1).  This causes PCP clients to re-try, and those using
   PORT_SET will now receive a different response.

4.4.  Port Set Renewal and Deletion

   Port set mappings are renewed and deleted as a single entity.  That
   is, the lifetime of all port mappings in the set is set to the
   Assigned Lifetime at once.

   A PCP client attempting to refresh or delete a port set mapping MUST
   include the PORT_SET option in its request.  A PCP client MUST NOT
   send a PORT_SET option for single-port refreshes.

Sun, et al.              Expires April 16, 2016                 [Page 8]
Internet-Draft                PCP PORT_SET                  October 2015

4.4.1.  Overlap Conditions

   Port set map requests can overlap with existing single port or port
   set mappings.  This can happen either by mistake or after a PCP
   client becomes out of sync with server state.

   If a PCP server receives a MAP request, with or without a PORT_SET
   option, that tries to map one or more internal ports or port sets
   belonging to already existing mappings, then the request is
   considered to be a refresh request applying those mappings.  Each of
   the matching port or port set mappings is processed independently, as
   if a separate refresh request had been received.  The processing is
   as described in Section 15 of [RFC6887].  The PCP server sends a
   Mapping Update message for each of the mappings.

5.  Examples

5.1.  Simple Request on NAT44

   An application requires a range of 100 IPv4 UDP ports to be mapped to
   itself.  The application running on the host has created sockets
   bound to IPv4 UDP ports 50,000 to 50,099 for this purpose.  It does
   not care about which external port numbers are allocated.  The PCP
   client sends a PCP request with the following parameters over IPv4:

   o  MAP opcode

      Mapping Nonce:  <a random nonce>

      Protocol:  17

      Internal Port:  50,000

      Suggested External Port:  0

      Suggested External IP Address:  ::ffff:0.0.0.0

   o  PORT_SET Option

      Port Set Size:  100

      First Internal Port:  50,000

      P: 0

   The PCP server is unable to fulfill the request fully: it is
   configured by local policy to only allocate 32 ports per user.  Since
   the PREFER_FAILURE option is absent from the request, it decides to

Sun, et al.              Expires April 16, 2016                 [Page 9]
Internet-Draft                PCP PORT_SET                  October 2015

   map UDP ports 37,056 to 37,087 on external address 192.0.2.3 to
   internal ports 50,000 to 50,031.  After setting up the mapping in the
   NAT44 device it controls, it replies with the following PCP response:

   o  MAP opcode

      Mapping Nonce:  <copied from the request>

      Protocol:  17

      Internal Port:  50,000

      Assigned External Port:  37,056

      Assigned External IP Address:  ::ffff:192.0.2.3

   o  PORT_SET Option

      Port Set Size:  32

      First Internal Port:  50,000

      P: 0

   Upon receiving this response, the host decides that 32 ports is good
   enough for its purposes.  It closes sockets bound to ports 50,032 to
   50,099, sets up a refresh timer, and starts using the port range it
   has just been assigned.

5.2.  Stateless Mapping Discovery

   A host wants to discover a stateless NAT44 mapping pointing to it.
   To do so, it sends the following request over IPv4:

   o  MAP opcode

      Mapping Nonce:  <a random nonce>

      Protocol:  0

      Internal Port:  1

      Suggested External Port:  0

      Suggested External IP Address:  ::ffff:0.0.0.0

   o  PORT_SET Option

Sun, et al.              Expires April 16, 2016                [Page 10]
Internet-Draft                PCP PORT_SET                  October 2015

      Port Set Size:  65,535

      First Internal Port:  1

      P: 0

   The PCP server sends the following response:

   o  MAP opcode

      Mapping Nonce:  <copied from the request>

      Protocol:  0

      Internal Port:  1

      Assigned External Port:  26,624

      Assigned External IP Address:  ::ffff:192.0.2.5

   o  PORT_SET Option

      Port Set Size:  2048

      First Internal Port:  26,624

      P: 0

   From this response, the host understands that a 2048-port stateless
   mapping is pointing to itself, starting from port 26,624 on external
   IP address 192.0.2.5.

5.3.  Resolving Overlap

   This example relates to Section 4.4.1.

   Suppose internal port 100 is mapped to external port 100 and port set
   101-199 is mapped to external port set 201-299.  The PCP server
   receives a MAP request with Internal Port = 100, External Port = 0,
   and a PORT_SET option with Port Set Size = 100.  The request's
   Mapping Nonce is equal to those of the existing single port and port
   set mappings.  This request is therefore treated as two refresh
   requests, the first one applying to the single port mapping and the
   second one applying to the port set mapping.  The PCP server updates
   both mapping's lifetimes as usual then sends two responses: the first
   one contains Internal Port = 100, External Port = 100, and no
   PORT_SET option, while the second one contains Internal Port = 101,
   External Port = 201, and a PORT_SET option with Port Set Size = 99.

Sun, et al.              Expires April 16, 2016                [Page 11]
Internet-Draft                PCP PORT_SET                  October 2015

6.  Operational Considerations

6.1.  Limits and Quotas

   It is up to the PCP server to determine the port-set quota, if any,
   for each PCP client.

   If the PCP server is configured to allocate multiple port-set
   allocations for one subscriber, the same Assigned External IP Address
   SHOULD be assigned to the subscriber in multiple port-set responses.

   To optimize the number of mapping entries maintained by the PCP
   server, it is RECOMMENDED to configure the PCP server to assign the
   maximum allowed port set size in a single response.  This policy
   SHOULD be configurable.

6.2.  High Availability

   The failover mechanism in MAP [section 14 in [RFC6887]] can also be
   applied to port sets.

6.3.  Idempotence

   A core, desirable property of the PCP protocol is idempotence.  In a
   nutshell, requests produce the same results whether they are executed
   once or multiple times.  This property is preserved with the PORT_SET
   attribute, with the following caveat: the order in which the PCP
   server receives requests with overlapping Internal Port Sets will
   affect the mappings being created and the responses received.

   For example suppose these two requests are sent by a PCP client:

   Request A:  Internal Port Set 1-10

   Request B:  Internal Port Set 5-14

   The PCP server's actions will depend on which request is received
   first.  Suppose that A is received before B:

   Upon reception of A:  Internal ports 1-10 are mapped.  A success
      response containing the following fields is sent:

      Internal Port:  1

      First Internal Port:  1

      Port Set Size:  10

Sun, et al.              Expires April 16, 2016                [Page 12]
Internet-Draft                PCP PORT_SET                  October 2015

   Upon reception of B:  The request matches mapping A.  The request is
      interpreted as a refresh request for mapping A, and a response
      containing the following fields is sent:

      Internal Port:  5

      First Internal Port:  1

      Port Set Size:  10

   If the order of reception is reversed (B before A), the created
   mapping will be different, and the First Internal Port in both
   responses would then be 5.

   To avoid surprises, PCP clients MUST ensure that port set mapping
   requests do not inadvertently overlap.  For example, a host's
   operating system could include a central PCP client process through
   which port set mapping requests would be arbitrated.  Alternatively,
   individual PCP clients running on the same host would be required to
   acquire the internal ports from the operating system (e.g., a call to
   the bind() function from the BSD API) before trying to map them with
   PCP.

6.4.  What should a PCP client do when it receives fewer ports than
      requested?

   Suppose a PCP client asks for 16 ports and receives 8.  What should
   it do?  Should it consider this a final answer?  Should it try a
   second request, asking for 8 more ports?  Should it fall back to 8
   individual MAP requests?  This document leaves the answers to be
   implementation-specific, but describes issues to be considered when
   answering them.

   First, the PCP server has decided to allocate 8 ports for some
   reason.  It may be that allocation sizes have been limited by the PCP
   server's administrator.  It may be that the PCP client has reached a
   quota.  It may be that these 8 ports were the last contiguous ones
   available.  Depending on the reason, asking for more ports may or may
   not be likely to actually yield more ports.  However, the PCP client
   has no way of knowing.

   Second, not all PCP clients asking for N ports actually need all N
   ports to function correctly.  For example, a DNS resolver could ask
   for N ports to be used for source port randomization.  If fewer than
   N ports are received, the DNS resolver will still work correctly, but
   source port randomization will be slightly less efficient, having
   fewer bits to play with.  In that case, it would not make much sense
   to ask for more ports.



   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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

Lodderstedt, et al.      Expires August 22, 2012                [Page 1]
Internet-Draft             OAuth 2.0 Security              February 2012

   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 . . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Attack Assumptions . . . . . . . . . . . . . . . . . . . .  7
     2.3.  Architectural assumptions  . . . . . . . . . . . . . . . .  7
       2.3.1.  Authorization Servers  . . . . . . . . . . . . . . . .  8
       2.3.2.  Resource Server  . . . . . . . . . . . . . . . . . . .  8
       2.3.3.  Client . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.  Security Features  . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Tokens . . . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . 10
       3.1.2.  Expires_In . . . . . . . . . . . . . . . . . . . . . . 10
     3.2.  Access Token . . . . . . . . . . . . . . . . . . . . . . . 11
     3.3.  Refresh Token  . . . . . . . . . . . . . . . . . . . . . . 11
     3.4.  Authorization Code . . . . . . . . . . . . . . . . . . . . 12
     3.5.  Redirection URI  . . . . . . . . . . . . . . . . . . . . . 12
     3.6.  State parameter  . . . . . . . . . . . . . . . . . . . . . 12
     3.7.  Client Identity  . . . . . . . . . . . . . . . . . . . . . 12
   4.  Security Threat Model  . . . . . . . . . . . . . . . . . . . . 14
     4.1.  Clients  . . . . . . . . . . . . . . . . . . . . . . . . . 15
       4.1.1.  Threat: Obtain Client Secrets  . . . . . . . . . . . . 15
       4.1.2.  Threat: Obtain Refresh Tokens  . . . . . . . . . . . . 16
       4.1.3.  Threat: Obtain Access Tokens . . . . . . . . . . . . . 18
       4.1.4.  Threat: End-user credentials phished using
               compromised or embedded browser  . . . . . . . . . . . 18
       4.1.5.  Threat: Open Redirectors on client . . . . . . . . . . 19
     4.2.  Authorization Endpoint . . . . . . . . . . . . . . . . . . 19
       4.2.1.  Threat: Password phishing by counterfeit
               authorization server . . . . . . . . . . . . . . . . . 20
       4.2.2.  Threat: User unintentionally grants too much
               access scope . . . . . . . . . . . . . . . . . . . . . 20
       4.2.3.  Threat: Malicious client obtains existing
               authorization by fraud . . . . . . . . . . . . . . . . 21
       4.2.4.  Threat: Open redirector  . . . . . . . . . . . . . . . 21
     4.3.  Token endpoint . . . . . . . . . . . . . . . . . . . . . . 21
       4.3.1.  Threat: Eavesdropping access tokens  . . . . . . . . . 22
       4.3.2.  Threat: Obtain access tokens from authorization
               server database  . . . . . . . . . . . . . . . . . . . 22

Lodderstedt, et al.      Expires August 22, 2012                [Page 2]
Internet-Draft             OAuth 2.0 Security              February 2012

       4.3.3.  Threat: Obtain client credentials over non secure
               transport  . . . . . . . . . . . . . . . . . . . . . . 22
       4.3.4.  Threat: Obtain client secret from authorization
               server database  . . . . . . . . . . . . . . . . . . . 23
       4.3.5.  Threat: Obtain client secret by online guessing  . . . 23
       4.3.6.  Threat: DoS on dynamic client secret creation  . . . . 23
     4.4.  Obtaining Authorization  . . . . . . . . . . . . . . . . . 23
       4.4.1.  Authorization Code . . . . . . . . . . . . . . . . . . 24
         4.4.1.1.  Threat: Eavesdropping or leaking authorization
                   codes  . . . . . . . . . . . . . . . . . . . . . . 24
         4.4.1.2.  Threat: Obtain authorization codes from
                   authorization server database  . . . . . . . . . . 25
         4.4.1.3.  Threat: Online guessing of authorization codes . . 25
         4.4.1.4.  Threat: Malicious client obtains authorization . . 26
         4.4.1.5.  Threat: Authorization code phishing  . . . . . . . 27
         4.4.1.6.  Threat: User session impersonation . . . . . . . . 28
         4.4.1.7.  Threat: Authorization code leakage through
                   counterfeit client . . . . . . . . . . . . . . . . 28
         4.4.1.8.  Threat: CSRF attack against redirect-uri . . . . . 30
         4.4.1.9.  Threat: Clickjacking attack against
                   authorization  . . . . . . . . . . . . . . . . . . 31
         4.4.1.10. Threat: Resource Owner Impersonation . . . . . . . 31
         4.4.1.11. Threat: DoS, Exhaustion of resources attacks . . . 33
         4.4.1.12. Threat: DoS using manufactured authorization
                   codes  . . . . . . . . . . . . . . . . . . . . . . 33
       4.4.2.  Implicit Grant . . . . . . . . . . . . . . . . . . . . 35
         4.4.2.1.  Threat: Access token leak in
                   transport/end-points . . . . . . . . . . . . . . . 35
         4.4.2.2.  Threat: Access token leak in browser history . . . 35
         4.4.2.3.  Threat: Malicious client obtains authorization . . 35
         4.4.2.4.  Threat: Manipulation of scripts  . . . . . . . . . 36
         4.4.2.5.  Threat: CSRF attack against redirect-uri . . . . . 36
       4.4.3.  Resource Owner Password Credentials  . . . . . . . . . 37
         4.4.3.1.  Threat: Accidental exposure of passwords at
                   client site  . . . . . . . . . . . . . . . . . . . 38
         4.4.3.2.  Threat: Client obtains scopes without end-user
                   authorization  . . . . . . . . . . . . . . . . . . 38
         4.4.3.3.  Threat: Client obtains refresh token through
                   automatic authorization  . . . . . . . . . . . . . 38
         4.4.3.4.  Threat: Obtain user passwords on transport . . . . 39
         4.4.3.5.  Threat: Obtain user passwords from
                   authorization server database  . . . . . . . . . . 39
         4.4.3.6.  Threat: Online guessing  . . . . . . . . . . . . . 40
       4.4.4.  Client Credentials . . . . . . . . . . . . . . . . . . 40
     4.5.  Refreshing an Access Token . . . . . . . . . . . . . . . . 40
       4.5.1.  Threat: Eavesdropping refresh tokens from
               authorization server . . . . . . . . . . . . . . . . . 40
       4.5.2.  Threat: Obtaining refresh token from authorization

Lodderstedt, et al.      Expires August 22, 2012                [Page 3]
Internet-Draft             OAuth 2.0 Security              February 2012

               server database  . . . . . . . . . . . . . . . . . . . 41
       4.5.3.  Threat: Obtain refresh token by online guessing  . . . 41
       4.5.4.  Threat: Obtain refresh token phishing by
               counterfeit authorization server . . . . . . . . . . . 41
     4.6.  Accessing Protected Resources  . . . . . . . . . . . . . . 42
       4.6.1.  Threat: Eavesdropping access tokens on transport . . . 42
       4.6.2.  Threat: Replay authorized resource server requests . . 42
       4.6.3.  Threat: Guessing access tokens . . . . . . . . . . . . 42
       4.6.4.  Threat: Access token phishing by counterfeit
               resource server  . . . . . . . . . . . . . . . . . . . 43
       4.6.5.  Threat: Abuse of token by legitimate resource
               server or client . . . . . . . . . . . . . . . . . . . 44
       4.6.6.  Threat: Leak of confidential data in HTTP-Proxies  . . 44
       4.6.7.  Threat: Token leakage via logfiles and HTTP
               referrers  . . . . . . . . . . . . . . . . . . . . . . 44
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 45
     5.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . . 45
       5.1.1.  Confidentiality of Requests  . . . . . . . . . . . . . 45
       5.1.2.  Server authentication  . . . . . . . . . . . . . . . . 46
       5.1.3.  Always keep the resource owner informed  . . . . . . . 46
       5.1.4.  Credentials  . . . . . . . . . . . . . . . . . . . . . 46
         5.1.4.1.  Credential Storage Protection  . . . . . . . . . . 47
         5.1.4.2.  Online attacks on secrets  . . . . . . . . . . . . 48
       5.1.5.  Tokens (access, refresh, code) . . . . . . . . . . . . 49
         5.1.5.1.  Limit token scope  . . . . . . . . . . . . . . . . 49
         5.1.5.2.  Expiration time  . . . . . . . . . . . . . . . . . 49
         5.1.5.3.  Short expiration time  . . . . . . . . . . . . . . 49
         5.1.5.4.  Limit number of usages/ One time usage . . . . . . 50
         5.1.5.5.  Bind tokens to a particular resource server
                   (Audience) . . . . . . . . . . . . . . . . . . . . 50
         5.1.5.6.  Use endpoint address as token audience . . . . . . 51
         5.1.5.7.  Audience and Token scopes  . . . . . . . . . . . . 51
         5.1.5.8.  Bind token to client id  . . . . . . . . . . . . . 51
         5.1.5.9.  Signed tokens  . . . . . . . . . . . . . . . . . . 51
         5.1.5.10. Encryption of token content  . . . . . . . . . . . 51
         5.1.5.11. Random token value with high entropy . . . . . . . 51
         5.1.5.12. Assertion formats  . . . . . . . . . . . . . . . . 52
       5.1.6.  Access tokens  . . . . . . . . . . . . . . . . . . . . 52
     5.2.  Authorization Server . . . . . . . . . . . . . . . . . . . 52
       5.2.1.  Authorization Codes  . . . . . . . . . . . . . . . . . 52
         5.2.1.1.  Automatic revocation of derived tokens if
                   abuse is detected  . . . . . . . . . . . . . . . . 52
       5.2.2.  Refresh tokens . . . . . . . . . . . . . . . . . . . . 52
         5.2.2.1.  Restricted issuance of refresh tokens  . . . . . . 52
         5.2.2.2.  Binding of refresh token to client_id  . . . . . . 53
         5.2.2.3.  Refresh Token Rotation . . . . . . . . . . . . . . 53
         5.2.2.4.  Refresh Token Revocation . . . . . . . . . . . . . 53
         5.2.2.5.  Device identification  . . . . . . . . . . . . . . 54

Lodderstedt, et al.      Expires August 22, 2012                [Page 4]
Internet-Draft             OAuth 2.0 Security              February 2012

         5.2.2.6.  X-FRAME-OPTION header  . . . . . . . . . . . . . . 54
       5.2.3.  Client authentication and authorization  . . . . . . . 54
         5.2.3.1.  Don't issue secrets to public clients or
                   clients with inappropriate security policy . . . . 55
         5.2.3.2.  Public clients without secret require user
                   consent  . . . . . . . . . . . . . . . . . . . . . 55
         5.2.3.3.  Client_id only in combination with redirect_uri  . 55
         5.2.3.4.  Deployment-specific client secrets . . . . . . . . 56
         5.2.3.5.  Validation of pre-registered redirect_uri  . . . . 56
         5.2.3.6.  Client secret revocation . . . . . . . . . . . . . 57
         5.2.3.7.  Use strong client authentication (e.g.
                   client_assertion / client_token) . . . . . . . . . 57
       5.2.4.  End-user authorization . . . . . . . . . . . . . . . . 58
         5.2.4.1.  Automatic processing of repeated
                   authorizations requires client validation  . . . . 58
         5.2.4.2.  Informed decisions based on transparency . . . . . 58
         5.2.4.3.  Validation of client properties by end-user  . . . 58
         5.2.4.4.  Binding of authorization code to client_id . . . . 59
         5.2.4.5.  Binding of authorization code to redirect_uri  . . 59
     5.3.  Client App Security  . . . . . . . . . . . . . . . . . . . 59
       5.3.1.  Don't store credentials in code or resources
               bundled with software packages . . . . . . . . . . . . 59
       5.3.2.  Standard web server protection measures (for
               config files and databases)  . . . . . . . . . . . . . 60
       5.3.3.  Store secrets in a secure storage  . . . . . . . . . . 60
       5.3.4.  Utilize device lock to prevent unauthorized device
               access . . . . . . . . . . . . . . . . . . . . . . . . 60
       5.3.5.  Platform security measures . . . . . . . . . . . . . . 60
       5.3.6.  Link state parameter to user agent session . . . . . . 60
     5.4.  Resource Servers . . . . . . . . . . . . . . . . . . . . . 61
       5.4.1.  Authorization headers  . . . . . . . . . . . . . . . . 61
       5.4.2.  Authenticated requests . . . . . . . . . . . . . . . . 61
       5.4.3.  Signed requests  . . . . . . . . . . . . . . . . . . . 62
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 62
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 62
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 62
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 63
   Appendix A.  Document History  . . . . . . . . . . . . . . . . . . 63
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65

Lodderstedt, et al.      Expires August 22, 2012                [Page 5]
Internet-Draft             OAuth 2.0 Security              February 2012

1.  Introduction

   This document gives security considerations based on a comprehensive
   threat model for the OAuth 2.0 Protocol [I-D.ietf-oauth-v2].  It
   contains the following content:

   o  Documents any assumptions and scope considered when creating the
      threat model.

   o  Describes the security features in-built into the OAuth protocol
      and how they are intended to thwart attacks.

   o  Gives a comprehensive threat model for OAuth and describes the
      respective counter measures to thwart those threats.

   Threats include any intentional attacks on OAuth tokens and resources
   protected by OAuth tokens as well as security risks introduced if the
   proper security measures are not put in place.  Threats are
   structured along the lines of the protocol structure to aid
   development teams implement each part of the protocol securely.  For
   example all threats for granting access or all threats for a
   particular grant type or all threats for protecting the resource
   server.

2.  Overview

2.1.  Scope

   The security considerations document only considers clients bound to
   a particular deployment as supported by [I-D.ietf-oauth-v2].  Such
   deployments have the following characteristics:

   o  Resource server URLs are static and well-known at development
      time, authorization server URLs can be static or discovered.

   o  Token scope values (e.g. applicable URLs and methods) are well-
      known at development time.

   o  Client registration: Since registration of clients is out of scope
      of the current core spec, this document assumes a broad variety of
      options from static registration during development time to
      dynamic registration at runtime.

   The following are considered out of scope :

Lodderstedt, et al.      Expires August 22, 2012                [Page 6]
Internet-Draft             OAuth 2.0 Security              February 2012

   o  Communication between authorization server and resource server

   o  Token formats

   o  Except for "Resource Owner Password Credentials" (see
      [I-D.ietf-oauth-v2], section 4.3), the mechanism used by
      authorization servers to authenticate the user

   o  Mechanism by which a user obtained an assertion and any resulting
      attacks mounted as a result of the assertion being false.

   o  Clients not bound to a specific deployment: An example could be a
      mail client with support for contact list access via the portable
      contacts API (see [portable-contacts]).  Such clients cannot be
      registered upfront with a particular deployment and should
      dynamically discover the URLs relevant for the OAuth protocol.

2.2.  Attack Assumptions

   The following assumptions relate to an attacker and resources
   available to an attacker:

   o  It is assumed the attacker has full access to the network between
      the client and authorization servers and the client and the
      resource server, respectively.  The attacker may eavesdrop on any
      communications between those parties.  He is not assumed to have
      access to communication between authorization and resource server.

   o  It is assumed an attacker has unlimited resources to mount an
      attack.

   o  It is assumed that 2 of the 3 parties involved in the OAuth
      protocol may collude to mount an attack against the 3rd party.
      For example, the client and authorization server may be under
      control of an attacker and collude to trick a user to gain access
      to resources.

2.3.  Architectural assumptions

   This section documents the assumptions about the features,
   limitations, and design options of the different entities of a OAuth
   deployment along with the security-sensitive data-elements managed by
   those entity.  These assumptions are the foundation of the threat
   analysis.

   The OAuth protocol leaves deployments with a certain degree of
   freedom how to implement and apply the standard.  The core
   specification defines the core concepts of an authorization server

Lodderstedt, et al.      Expires August 22, 2012                [Page 7]
Internet-Draft             OAuth 2.0 Security              February 2012

   Sun, et al.              Expires April 16, 2016                [Page 13]
Internet-Draft                PCP PORT_SET                  October 2015

   Finally, asking for more ports could be considered abuse.  External
   ports are a resource that is to be shared among multiple PCP clients.
   A PCP client trying to obtain more than its fair share could trigger
   countermeasures according to local policy.

   In conclusion, it is expected that for most applications, asking for
   more ports would not yield benefits justifying the additional costs.

7.  Security Considerations

   The security considerations discussed in [RFC6887] apply to this
   extension.

   As described in Section 4.4.1, a single PCP request using the
   PORT_SET option may result in multiple responses.  For this to happen
   it is necessary that the request contain the nonce associated to
   multiple mappings on the server.  Therefore, an on-path attacker
   could use an eavesdropped nonce to mount an amplification attack.
   Use of PCP authentication ([RFC6887], Section 18) eliminates this
   attack vector.

8.  IANA Considerations

   IANA has allocated value TBD (note to IANA: to be allocated from the
   range 128-191) in the "PCP Options" registry at
   http://www.iana.org/assignments/pcp-parameters for the new PCP option
   defined in Section 4.

9.  Contributors

   The following are extended authors who contributed to the effort:

   Yunqing Chen

   China Telecom

   Room 502, No.118, Xizhimennei Street

   Beijing 100035

   P.R.China

   Chongfeng Xie

   China Telecom

   Room 502, No.118, Xizhimennei Street

Sun, et al.              Expires April 16, 2016                [Page 14]
Internet-Draft                PCP PORT_SET                  October 2015

   Beijing 100035

   P.R.China

   Yong Cui

   Tsinghua University

   Beijing 100084

   P.R.China

   Phone: +86-10-62603059

   Email: yong@csnet1.cs.tsinghua.edu.cn

   Qi Sun

   Tsinghua University

   Beijing 100084

   P.R.China

   Phone: +86-10-62785822

   Email: sunqibupt@gmail.com

   Gabor Bajko

   Nokia

   Email: gabor.bajko@nokia.com

   Xiaohong Deng

   France Telecom

   Email: xiaohong.deng@orange-ftgroup.com

10.  Acknowledgements

   The authors would like to show sincere appreciation to Alain Durand,
   Cong Liu, Dan Wing, Dave Thaler, Peter Koch, Reinaldo Penno, Sam
   Hartman, Stuart Cheshire, Ted Lemon, and Yoshihiro Ohba, for their
   useful comments and suggestions.

Sun, et al.              Expires April 16, 2016                [Page 15]
Internet-Draft                PCP PORT_SET                  October 2015

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6887]  Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
              2013.

11.2.  Informative References

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC6888]  Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
              and H. Ashida, "Common Requirements for Carrier-Grade NATs
              (CGNs)", BCP 127, RFC 6888, April 2013.

   [RFC7596]  Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and
              I. Farrer, "Lightweight 4over6: An Extension to the DS-
              Lite Architecture", RFC 7596, July 2015.

Authors' Addresses

   Qiong Sun
   China Telecom
   P.R.China

   Phone: 86 10 58552936
   Email: sunqiong@ctbri.com.cn

Sun, et al.              Expires April 16, 2016                [Page 16]
Internet-Draft                PCP PORT_SET                  October 2015

   Mohamed Boucadair
   France Telecom
   Rennes  35000
   France

   Email: mohamed.boucadair@orange.com

   Senthil Sivakumar
   Cisco Systems
   7100-8 Kit Creek Road
   Research Triangle Park, North Carolina  27709
   USA

   Phone: +1 919 392 5158
   Email: ssenthil@cisco.com

   Cathy Zhou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Email: cathy.zhou@huawei.com

   Tina Tsou
   Huawei Technologies (USA)
   2330 Central Expressway
   Santa Clara, CA 95050
   USA

   Phone: +1 408 330 4424
   Email: Tina.Tsou.Zouting@huawei.com

   Simon Perreault
   Jive Communications
   Quebec, QC
   Canada

   Email: sperreault@jive.com

Sun, et al.              Expires April 16, 2016                [Page 17]