SIP Core                                                  R. Shekh-Yusef
Internet-Draft                                                     Avaya
Updates: 3261 (if approved)                                  C. Holmberg
Intended status: Standards Track                                Ericsson
Expires: 21 August 8 September 2020                                     V. Pascual
                                                             webrtchacks
                                                        18 February
                                                            7 March 2020

  Third-Party Token-based Authentication and Authorization for Session
                       Initiation Protocol (SIP)
                 draft-ietf-sipcore-sip-token-authnz-08
                 draft-ietf-sipcore-sip-token-authnz-09

Abstract

   This document defines a SIP mechanism that relies on the OAuth 2.0
   and OpenID Connect Core 1.0 to enable delegation of "Bearer" authentication scheme for the
   Session Initiation Protocol (SIP), and a mechanism by which user
   authentication and SIP registration authorization is delegated to a third-party.
   The
   third party, using the OAuth 2.0 framework and OpenID Connect Core
   1.0.  This document updates RFC 3261. 3261 to provide guidance on how a SIP
   User Agent Client (UAC) responds to a SIP 401/407 response that
   contains multiple WWW-Authenticate/Proxy-Authenticate header fields.

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 https://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 21 August 8 September 2020.

Copyright Notice

   Copyright (c) 2020 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 (https://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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  SIP User Agent Types  . . . . . . . . . . . . . . . . . .   3
   2.  SIP Procedures
     1.3.  Token Types . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  UAC Behavior   3
     1.4.  Example Flows . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.1.  Obtaining Tokens
       1.4.1.  Registration  . . . . . . . . . . . . . . . . . . . .   4
       2.1.2.  Protecting the Access Token
       1.4.2.  Registration with Preconfigured AS  . . . . . . . . .   5
   2.  SIP Procedures  . . . .   5
       2.1.3.  REGISTER Request . . . . . . . . . . . . . . . . . .   5
       2.1.4.  Non-REGISTER Request .   7
     2.1.  UAC Behavior  . . . . . . . . . . . . . . . .   5
     2.2.  UAS and Registrar Behavior . . . . . .   7
       2.1.1.  Obtaining Tokens and Responding to Challenges . . . .   7
       2.1.2.  Protecting the Access Token . . . . .   6
     2.3.  Proxy Behavior . . . . . . . .   8
       2.1.3.  REGISTER Request  . . . . . . . . . . . . .   6
   3.  Access Token Claims . . . . .   8
       2.1.4.  Non-REGISTER Request  . . . . . . . . . . . . . . . .   7
   4.  WWW-Authenticate Response Header Field   8
     2.2.  UAS and Registrar Behavior  . . . . . . . . . . .   7
   5.  Example Flows . . . .   9
     2.3.  Proxy Behavior  . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Registration .   9
   3.  Access Token Claims . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Registration with Pre-Configured AS  10
   4.  WWW-Authenticate Response Header Field  . . . . . . . . . . .  10
   6.
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   9.
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   The Session Initiation Protocol (SIP) [RFC3261] uses the same
   framework
   used by as HTTP [RFC7230] for authenticating users, which is to authenticate users: a simple
   challenge-response authentication mechanism that allows a SIP server
   to challenge a SIP client request and allows a SIP client to provide
   authentication information in response to that challenge.

   OAuth 2.0 [RFC6749] defines a token based token-based authorization framework to
   allow clients an OAuth client to access resources on behalf of their its user.

   The OpenID Connect 1.0 specification [OPENID] specifications defines a simple
   identity layer on top of the OAuth 2.0 protocol, which enables
   clients to verify the identity of the user based on the
   authentication performed by a dedicated authorization server, as well
   as to obtain basic profile information about the user.

   This document defines the "Bearer" authentication scheme for the
   Session Initiation Protocol (SIP), and a mechanism by which user
   authentication and SIP registration authorization is delegated to a
   third party, using the OAuth 2.0 framework and OpenID Connect Core
   1.0.  This kind of user authentication enables the single-sign-on
   feature, which allows the user to authenticate once and gain access
   to both SIP and non-SIP services.

   This document also updates [RFC3261], by defining the UAC User Agent
   Client (UAC) procedures if it when a UAC receives a 401/407 response with
   multiple WWW-Authenticate/Proxy-
   Authenticate WWW-Authenticate/Proxy-Authenticate header fields, providing
   challenges using different authentication schemes for the same realm.

   This document defines an mechanism for SIP, that relies on the OAuth
   2.0 and OpenID Connect Core 1.0 specifications, to enable the
   delegation of the user authentication and SIP registration
   authorization to a dedicated third-party entity that is separate from
   the SIP network elements that provide the SIP service.

1.1.  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 [RFC2119]. BCP 14 [RFC2119]
   [RFC8174] when, and only when, they appear in all capitals, as shown
   here.

1.2.  SIP User Agent Types

   The OAuth 2.0 authorization framework [RFC6749] defines two types of
   clients, confidential and public, that apply to the SIP User Agents. UACs.

   *  Confidential User Agent: is a SIP UA UAC that is capable of maintaining
      the confidentiality of the user credentials and any tokens
      obtained using these user credentials.

   *  Public User Agent: is a SIP UA UAC that is incapable of maintaining the
      confidentiality of the user credentials and any obtained tokens.

   The mechanism defined in this document MUST only be used with
   Confidential User Agents, as the UA UAC is expected to obtain and
   maintain tokens to be able to access the SIP network.

2.  SIP Procedures

   Section 22

1.3.  Token Types

   There are two types of [RFC3261] defines the SIP procedures for the Digest
   authentication mechanism procedures.  The same procedures apply to
   the Bearer authentication mechanism, tokens that might be used with the changes described in this section.

2.1.  UAC Behavior

2.1.1.  Obtaining Tokens

   When a UAC sends
   specification:

   *  Structured Token: a request without credentials (or with credentials token that are no longer valid), and receives a 401 (Unauthorized) or consists of a 407
   (Proxy Authentication Required) response structured object
      that contains the claims associated with the token, e.g.  JWT as
      defined in [RFC7519].

   *  Reference Token: a WWW-
   Authenticate header field (in case of a 401 response) or a Proxy-
   Authenticate header field (in case token that consists of a 407 response) random string that indicates
   "Bearer" scheme authentication and contains an address is
      used to an
   Authorization Server, obtain the UAC contacts details of the Authorization Server in
   order to obtain tokens, token and includes the requested scopes, based on its associated claims,
      as defined in [RFC6749].

1.4.  Example Flows

1.4.1.  Registration

   Figure 1 below shows an example of a
   local configuration.

   The tokens returned to SIP registration, where the UA depend on
   registrar informs the type of AS: with an OAuth
   AS, UAC about the tokens provided are authorization server from which
   the UAC can obtain an access token and refresh token.  The
   access token will be sent to the SIP servers to authorize UAC's
   access in a 401 response to the service. REGISTER
   request.

     UAC                         Registrar                          AS
   ---------------------------------------------------------------------
     |                               |                               |
     | [1] REGISTER                  |                               |
     |------------------------------>|                               |
     |                               |                               |
     | [2] 401 Unauthorized          |                               |
     |     WWW-Authenticate: Bearer "authz_server"="<authz_server>"  |
     |<------------------------------|                               |
     |                               |                               |
     | [3] The refresh token will only be used UAC interacts with the AS to get new access token and refresh token, before the expiry of obtains tokens, using   |
     |     some out-of-scope mechanism.                              |
     |<=============================================================>|
     |                               |                               |
     | [4] REGISTER                  |                               |
     |     Authorization: Bearer <access_token>                      |
     |------------------------------>|                               |
     |                               | [5] HTTP POST /introspect     |
     |                               |     {access_token}            |
     |                               |------------------------------>|
     |                               |                               |
     |                               | [6] 200 OK {metadata}         |
     |                               |<------------------------------|
     |                               |                               |
     | [7] 200 OK                    |                               |
     |<------------------------------|                               |
     |                               |                               |

                    Figure 1: Example Registration Flow

   In step [1], the current access token.  With an OpenID Connect server, an
   additional ID-Token is returned, which contains UAC starts the SIP URI and other
   user specific details, and will be consumed registration process by the UAC.

   The detailed OAuth2 procedure sending a SIP
   REGISTER request to authenticate the user and obtain
   these tokens is out of scope of this document.  [RFC8252] defines
   procedures for native applications.  When using registrar without any credentials.

   In step [2], the mechanism defined
   in [RFC8252] registrar challenges the user will be directed to use UA, by sending a browser for SIP 401
   (Unauthorized) response to the
   interaction with REGISTER request.  In the authorization server, allowing response,
   the authorization
   server registrar includes information about the AS to prompt contact in order
   to obtain a token.

   In step [3], the user for multi-factor authentication, redirect UAC interacts with the AS via an out-of-scope
   mechanism, potentially using the OAuth Native App mechanism defined
   in [RFC8252].  The AS authenticates the user to third-party identity providers, and the use of single-
   sign-on sessions.

   If provides the UAC receives a 401/407 response
   with multiple WWW-
   Authenticate/Proxy-Authenticate header fields, providing challenges
   using different authentication schemes for the same realm, tokens needed to access the SIP service.

   In step [4], the UAC
   provides credentials for one or more of retries the schemes registration process by sending a
   new REGISTER request that it supports,
   based on local policy.

   NOTE: The address of includes the Authorization Server might be known to access token that the UAC e.g., using means of configuration, in which case
   obtained previously.

   The registrar validates the UAC can
   contact access token.  If the Authorization Server access token is a
   reference token, the registrar MAY perform an introspection
   [RFC7662], as in steps [5] and [6], in order to obtain more
   information about the access token
   before and its scope, per [RFC7662].
   Otherwise, after the registrar validates the token to make sure it
   was signed by a trusted entity, it inspects its claims and acts upon
   it.

   In step [7], once the registrar has successfully verified and
   accepted the access token, it sends SIP request without credentials.

2.1.2.  Protecting a 200 (OK) response to the Access Token

   [RFC6749] mandates that Access Tokens are protected with TLS when in
   transit.  However, TLS only guarantees hop-to-hop protection when
   used to protect SIP signaling.  Therefore the Access Token MUST be
   protected in a way so that only authorized SIP servers will have
   access to it.  Endpoints that support this specification MUST support
   encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and protecting
   Access Token when included in SIP requests, unless some other
   mechanism is used to guarantee that only authorized SIP endpoints
   have access to the Access Token.

2.1.3.  REGISTER Request

   The procedures in this section assumes that the UAC has obtained a
   token as specified in section Section 2.1.1

   When the UAC sends a
   REGISTER request after it received a challenge
   containing the Bearer scheme, then to resolve that particular
   challenge it needs to send a request request.

1.4.2.  Registration with Preconfigured AS

   Figure 2 shows an Authorization header
   field containing the response to that challenge, including the Bearer
   scheme carrying example of a valid access token in the request, as specified in
   [RFC6750].

   Note that if there were multiple challenges with different schemes
   then it maybe able to successfully retry the request using non-Bearer
   credentials.

   Based on local policy, SIP registration where the UAC MAY include an access token that has
   been used for another binding associated preconfigured with information about the same AOR in the
   request.

   If AS from which to obtain
   the access token included in a REGISTER request is not accepted,
   and the token.

     UAC receives a 401 response or a 407 response, the                         Registrar                          AS
   ---------------------------------------------------------------------
     |                               |                               |
     | [1] The UAC
   follows interacts with the procedures in Section 2.1.1.

2.1.4.  Non-REGISTER Request

   The procedures in this section assumes that AS and obtains tokens, using   |
     |     some out of scope mechanism.                              |
     |<=============================================================>|
     |                               |                               |
     | [2] REGISTER                  |                               |
     |     Authorization: Bearer <access_token>                      |
     |------------------------------>|                               |
     |                               | [3] HTTP POST /introspect     |
     |                               |     {access_token}            |
     |                               |------------------------------>|
     |                               |                               |
     |                               | [4] 200 OK {metadata}         |
     |                               |<------------------------------|
     |                               |                               |
     | [5] 200 OK                    |                               |
     |<------------------------------|                               |
     |                               |                               |

         Figure 2: Example Registration Flow - Authorization Server
                         Information Preconfigured

   In step [1], the UAC has obtained a
   token as specified interacts with the AS using an out-of-scope
   mechanism, potentially using the OAuth Native App mechanism defined
   in section Section 2.1.1
   When a UAC sends a request, after it received a challenge containing [RFC8252].  The AS authenticates the Bearer scheme, then user and provides the UAC MUST include an Authorization header
   field
   with a Bearer scheme, carrying a valid the tokens needed to access token in the
   request, as specified in [RFC6750].  Based on local policy, SIP service.

   In step [2], the UAC
   MAY include an retries the registration process by sending a
   new REGISTER request that includes the access token that has been used for another dialog, or
   for another stand-alone request, if the target of the new request is UAC
   obtained previously.

   The registrar validates the same. access token.  If the access token included in a request is not accepted, and the
   UAC receives a 401 response or a 407 response, the UAC follows
   reference token, the
   procedures registrar MAY perform an introspection, as in Section 2.1.1.

2.2.  UAS
   steps [3] and Registrar Behavior

   When a UAS or Registrar receives a request that fails [4], in order to contain
   authorization credentials acceptable obtain more information about the
   access token and its scope, per [RFC7662].  Otherwise, after the
   registrar validates the token to it, make sure it SHOULD challenge the
   request was signed by sending a 401 (Unauthorized) response.  To indicate that trusted
   entity, it is willing to accept an OAuth2 token as a credential the UAS/
   Registrar MUST include a Proxy-Authentication header field in the
   response, indicate "Bearer" scheme inspects its claims and include an address of an
   Authorization Server from which the originator can obtain an access
   token.

   When a UAS/Registrar receives a SIP request that contains an
   Authorization header field with an access token, acts upon it.

   In step [5], once the UAS/Registrar
   MUST validate registrar has successfully verified and
   accepted the access token, using the procedures associated with it sends a 200 (OK) response to the type
   REGISTER request.

2.  SIP Procedures

   Section 22 of access token used, e.g.  [RFC7519].  If the validation is
   successful the UAS/Registrar can continue to process [RFC3261] defines the request
   using normal SIP procedures.  If procedures for the validation fails, Digest
   authentication mechanism.  The same procedures apply to the UAS/
   Registrar MUST reject Bearer
   authentication mechanism, with the request.

2.3.  Proxy changes described in this section.

2.1.  UAC Behavior

2.1.1.  Obtaining Tokens and Responding to Challenges

   When a proxy receives UAC sends a request that fails to contain authorization without credentials acceptable to it, (or with invalid
   credentials), it SHOULD challenge the request by
   sending could receive either a 401 (Unauthorized) response
   with a WWW-Authenticate header field or a 407 (Proxy Authentication
   Required) response.  To indicate
   that it is willing to accept an OAuth2 token as response with a credential Proxy-Authenticate header field.  If the
   proxy MUST include a Proxy-Authentication
   WWW-Authenticate or Proxy-Authenticate header field in the
   response, indicating indicates
   "Bearer" scheme authentication and including contains an address to an
   Authorization Server from which
   authorization server, the originator can UAC contacts the authorization server in
   order to obtain an access
   token.

   When tokens, and includes the requested scopes, based on a proxy wishes
   local configuration (Figure 1).

   The detailed OAuth2 procedure to authenticate a received request, it MUST
   search the request for Proxy-Authorization header fields with 'realm'
   parameters that match its realm.  It then MUST successfully validate user and obtain
   these tokens is out of scope of this document.  The address of the credentials from at least one Proxy-Authorization header field
   authorization server might already be known to the UAC via
   configuration.  In which case, the UAC can contact the authorization
   server for its realm. tokens before it sends a SIP request (Figure 2).
   Procedures for native applications are defined in [RFC8252].  When
   using the scheme is Bearer mechanism defined in [RFC8252] the proxy MUST validate user of the
   access token, UAC will be
   directed to interact with the authorization server using a web
   browser, allowing the procedures associated with authorization server to prompt the type user for
   multi-factor authentication, to redirect the user to third-party
   identity providers, and to enable the use of access
   token used, e.g.  [RFC7519].

3.  Access Token Claims single-sign-on sessions.

   The tokens returned to the UAC depend on the type of services that authorization
   server (AS): an OAuth AS provides an access token grants and refresh token
   [RFC6749].  The UAC provides the access token to can be
   determined using different methods.  Which methods are used and the
   granted SIP servers to
   authorize UAC's access provided by to the service.  The UAC uses the refresh
   token is based on local policy agreed
   between only with the AS to get a new access token and refresh token
   before the registrar.

   If an expiry of the current access token is encoded as a JWT, it might contain a list of
   claims [RFC7519], some registered and some are application specific
   claims.  The REGISTRAR can grant access to services either based on
   such claims, using some other mechanism, or a combination of claims
   and some other mechanism.  If (see [RFC6749], section
   1.5 Refresh Token for details).  An OpenID Connect server returns an access token is a reference token,
   additional ID-Token containing the REGISTRAR will grant access based on some other mechanism.
   Examples of such SIP URI and other mechanisms are introspection [RFC7662], user
   profile lookups, etc.

4.  WWW-Authenticate Response Header Field

   This section describes user-specific
   details that will be consumed by the syntax of UAC.

   If the WWW-Authenticate Response
   Header Field when used UAC receives a 401/407 response with multiple WWW-
   Authenticate/Proxy-Authenticate header fields, providing challenges
   using different authentication schemes for the Bearer scheme to challenge same realm, the UA UAC
   provides credentials for
   credentials, by extending one or more of the 'challnge' header field defined by
   [RFC3261].

       challenge  =/  ("Bearer" LWS bearer-cln *(COMMA bearer-cln))
       bearer-cln = realm / scope / authz-server / error /
                    auth-param
       authz-server = "authz_server" EQUAL authz-server-value
       authz-server-value = https-URI
       realm = <defined in RFC3261>
       auth-param = <defined in RFC3261>
       scope = <defined in RFC6749>
       error = <defined in RFC6749>
       https-URI = <defined in RFC7230>

                       Figure 1: Bearer Scheme Syntax schemes that it supports,
   based on local policy.

   NOTE: The authz-server parameters contains the HTTPS URI, as defined in
   [RFC7230], address of the authorization server.  The UA can discover metadata
   about Authorization Server might be known to the AS
   UAC e.g., using a mechanism like the one defined in [RFC8414].

   The realm and auth-param parameters are defined means of configuration, in [RFC3261].

   As per [RFC3261], the realm string alone defines which case the protection
   domain.  [RFC3261] states that UAC can
   contact the realm string must be globally
   unique and recommends that Authorization Server in order to obtain the realm string contains a hostname or
   domain name.  It also states access token
   before it sends SIP request without credentials.

2.1.2.  Protecting the Access Token

   [RFC6749] mandates that access tokens are protected with TLS when in
   transit.  However, TLS only guarantees hop-to-hop protection when
   used to protect SIP signaling.  Therefore the realm string should access token MUST be human-
   readable identifier
   protected in a way so that can be rendered only authorized SIP servers will have
   access to the user.

   The scope it.  Endpoints that support this specification MUST support
   encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and error parameters protecting
   access tokens when they are defined included in [RFC6749].

   The scope parameter could be SIP requests, unless some
   other mechanism is used by the registrar/proxy to indicate guarantee that only authorized SIP
   endpoints have access to the UAC access token.

2.1.3.  REGISTER Request

   The procedures in this section apply when the minimum scope UAC has received a
   challenge that must be associated contains a "Bearer" scheme, and the UAC has obtained a
   token as specified in Section 2.1.1.

   The UAC sends a REGISTER request with an Authorization header field
   containing the response to the challenge, including the Bearer scheme
   carrying a valid access token to in the request, as specified in
   [RFC6750].

   Note that, if there were multiple challenges with different schemes,
   then the UAC may be able to get service.  As defined in [RFC6749], successfully retry the value
   of request using non-
   Bearer credentials.

   Based on local policy, the scope parameter is expressed as a list of space-delimited,
   case-sensitive strings.  The strings are defined by UAC MAY include an access token that has
   been used for another binding associated with the authorization
   server.  The values of same AOR in the scope parameter
   request.

   If the access token included in a REGISTER request is out of scope of this
   document.  The not accepted,
   and the UAC will use receives a 401 response or a 407 response, the scope provided by UAC
   follows the registrar to
   contact procedures in Section 2.1.1.

2.1.4.  Non-REGISTER Request

   The procedures in this section apply when the AS UAC has received a
   challenge that contains a "Bearer" scheme, and obtain the UAC has obtained a proper
   token with as specified in Section 2.1.1.

   When the requested scope.

   The error parameter could be used by UAC sends a request, it MUST include an Authorization header
   field with a Bearer scheme, carrying a valid access token in the registrar/proxy to indicate
   to
   request, as specified in [RFC6750].  Based on local policy, the UAC the reason
   MAY include an access token that has been used for the error, with possible values of
   "invalid_token" another dialog, or "invalid_scope".

5.  Example Flows

5.1.  Registration

   The figure below shows an example
   for another stand-alone request, if the target of a SIP registration, where the UA new request is informed about
   the Authorization Server (AS) from where to obtain
   an same.

   If the access token by the registratar included in a request is not accepted, and the
   UAC receives a 401 response to or a 407 response, the REGISTER
   request.

     UA UAC follows the
   procedures in Section 2.1.1.

2.2.  UAS and Registrar                          AS
   ---------------------------------------------------------------------
     |                               |                               |
     | [1] REGISTER                  |                               |
     |------------------------------>|                               |
     |                               |                               |
     | [2] 401 Unauthorized          |                               |
     |     WWW-Authenticate: Bearer "authz_server"="<authz_server>"  |
     |<------------------------------|                               |
     |                               |                               |
     | [3] The UA interacts with the AS and obtains tokens, using    |
     |     some out of scope mechanism.                              |
     |<=============================================================>|
     |                               |                               |
     | [4] REGISTER                  |                               |
     |     Authorization: Bearer <access_token>                      |
     |------------------------------>|                               |
     |                               | [5] HTTP POST /introspect     |
     |                               |     {access_token}            |
     |                               |------------------------------>|
     |                               |                               |
     |                               | [6] 200 OK {metadata}         |
     |                               |<------------------------------|
     |                               |                               |
     | [7] 200 OK                    |                               |
     |<------------------------------|                               |
     |                               |                               |

                    Figure 2: Example Registration Flow

   In step [1], the UA starts the registration process by sending Behavior

   When a UAS or Registrar receives a SIP
   REGISTER request that fails to contain
   authorization credentials acceptable to it, it SHOULD challenge the registrar without any credentials.

   In step [2], the registrar challenges the UA,
   request by sending a SIP 401 (Unauthorized) response to the REGISTER request.  In the response the
   registrar includes information about the AS to contact in order response.  To indicate that
   it is willing to
   obtain accept an access token as a token.

   In step [3], the UA interacts with credential, the AS, potentially using the
   OAuth Native App mechanism defined UAS/
   Registrar MUST include a Proxy-Authentication header field in [RFC8252], authenticates the
   user
   response that indicates "Bearer" scheme and obtains includes an address of an
   authorization server from which the tokens needed to originator can obtain an access the SIP service.

   In step [4], the UA retries the registration process by sending
   token.

   When a UAS/Registrar receives a new SIP REGISTER request that includes the contains an
   Authorization header field with an access token that token, the UA
   obtrained previously.

   The registrar validates UAS/Registrar
   MUST validate the access token.  If token, using the procedures associated with
   the type of access token used, e.g.  [RFC7519].  If the access token
   provided is a
   reference an expired access token, then the registrar MAY perform an introspection, UAS MUST reply with 401
   Unauthorized, as defined in
   steps [5] and [6], in order section 3 of [RFC6750].  If the
   validation is successful, the UAS/Registrar can continue to obtain more information about process
   the
   access token and its scope, as per [RFC7662].  Otherwise, after request using normal SIP procedures.  If the
   registrar validates validation fails,
   the token UAS/Registrar MUST reject the request.

2.3.  Proxy Behavior

   When a proxy receives a request that fails to make sure contain authorization
   credentials acceptable to it, it was signed SHOULD challenge the request by
   sending a trusted
   entity, 407 (Proxy Authentication Required) response.  To indicate
   that it inspects its claims and act upon it.

   In step [7], once the registrar has succesfully verified and accepted
   the is willing to accept an access token, it sends token as a 200 (OK) credential, the
   proxy MUST include a Proxy-Authentication header field in the
   response that indicates "Bearer" scheme and includes an address to an
   authorization server from which the REGISTER
   request.

5.2.  Registration with Pre-Configured AS

   The figure below shows originator can obtain an example of access
   token.

   When a SIP registration, where proxy wishes to authenticate a received request, it MUST
   search the UA
   has pre-configured information about request for Proxy-Authorization header fields with 'realm'
   parameters that match its realm.  It then MUST successfully validate
   the Authorization Server (AS) credentials from where to obtain at least one Proxy-Authorization header field
   for its realm.  When the scheme is "Bearer", the proxy MUST validate
   the access token.

     UA                          Registrar                          AS
   ---------------------------------------------------------------------
     |                               |                               |
     | [1] The UA interacts token, using the procedures associated with the AS and obtains tokens, type of
   access token used, e.g., [RFC7519].

3.  Access Token Claims

   The type of services to which an access token grants access can be
   determined using    |
     | different methods.  The methods used and the access
   provided by the token is based on local policy agreed between the AS
   and the registrar.

   If an access token is encoded as a JWT, it might contain a list of
   claims [RFC7519], some out registered and some application-specific.  The
   REGISTRAR can grant access to services based on such claims, some
   other mechanism, or a combination of scope claims and some other mechanism.                              |
     |<=============================================================>|
     |                               |                               |
     | [2] REGISTER                  |                               |
     |     Authorization: Bearer <access_token>                      |
     |------------------------------>|                               |
     |                               | [3] HTTP POST /introspect     |
     |                               |     {access_token}            |
     |                               |------------------------------>|
     |                               |                               |
     |                               | [4] 200 OK {metadata}         |
     |                               |<------------------------------|
     |                               |                               |
     | [5] 200 OK                    |                               |
     |<------------------------------|                               |
     |                               |                               |
   If an access token is a reference token, the REGISTRAR will grant
   access based on some other mechanism.  Examples of such other
   mechanisms are introspection [RFC7662], user profile lookups, etc.

4.  WWW-Authenticate Response Header Field

   This section uses ABNF [RFC5234] to describe the syntax of the WWW-
   Authenticate header field when used with the "Bearer" scheme to
   challenge the UAC for credentials, by extending the 'challenge'
   parameter defined by [RFC3261].

       challenge  =/  ("Bearer" LWS bearer-cln *(COMMA bearer-cln))
       bearer-cln = realm / scope / authz-server / error /
                    auth-param
       authz-server = "authz_server" EQUAL authz-server-value
       authz-server-value = https-URI
       realm = <defined in RFC3261>
       auth-param = <defined in RFC3261>
       scope = <defined in RFC6749>
       error = <defined in RFC6749>
       https-URI = <defined in RFC7230>

                       Figure 3: Example Registration Flow - Authorization Server
                         Information Preconfigured

   In step [1], Bearer Scheme Syntax

   The authz-server parameter contains the UA interacts with HTTPS URI, as defined in
   [RFC7230], of the AS, potentially authorization server.  The UAC can discover
   metadata about the AS using a mechanism like the one defined in
   [RFC8414].

   The realm and auth-param parameters are defined in [RFC3261].

   Per [RFC3261], the realm string alone defines the protection domain.
   [RFC3261] states that the realm string must be globally unique and
   recommends that the realm string contain a hostname or domain name.
   It also states that the realm string should be a human-readable
   identifier that can be rendered to the
   OAuth Native App mechanism user.

   The scope and error parameters are defined in [RFC8252], authenticates the
   user and obtains [RFC6749].

   The scope parameter could be used by the tokens needed registrar/proxy to indicate
   to access the SIP service.

   In step [2], the UA retries UAC the registration process by sending a new
   SIP REGISTER request minimum scope that includes must be associated with the access
   token that the UA
   obtrained previously.

   The registrar validates to be able to get service.  As defined in [RFC6749], the access token.  If value
   of the access token scope parameter is expressed as a
   reference token, list of space-delimited,
   case-sensitive strings.  The strings are defined by the authorization
   server.  The values of the scope parameter are out of scope of this
   document.  The UAC will use the scope provided by the registrar MAY perform an introspection, as in
   steps [3] and [4], in order to obtain more information about
   contact the
   access token AS and its scope, as per [RFC7662].  Otherwise, after obtain a proper token with the
   registrar validates requested scope.

   The error parameter could be used by the token registrar/proxy to indicate
   to make sure it was signed by a trusted
   entity, it inspects its claims and act upon it.

   In step [5], once the registrar has succesfully verified and accepted UAC the access token, it sends a 200 (OK) response to reason for the REGISTER
   request.

6. error, with possible values of
   "invalid_token" or "invalid_scope".

5.  Security Considerations

   The security considerations for OAuth are defined in [RFC6749].  The
   security considerations for bearer tokens are defined in [RFC6750].
   The security considerations for JSON Web Tokens (JWT) are defined in
   [RFC7519].  These security considerations also apply to SIP usage of
   access token as defined in this document.

   [RFC6749] mandates that Access Tokens access tokens are protected with TLS.
   However, TLS only guarantees hop-to-hop protection when used to
   protect SIP signaling.  Therefore the Access Token access token MUST be protected
   in a way so that only authorized SIP endpoints will have access to
   it.  Endpoints that support this specifications specification MUST support encrypted
   JSON Web Tokens (JWT) [RFC7519] for encoding and protecting
   Access Token access
   tokens when included in SIP requests, unless some other mechanism is
   used to guarantee that only authorized SIP endpoints have access to
   the Access Token.

7. access token.

6.  IANA Considerations

8.

7.  Acknowledgments

   The authors would like to specially thank Paul Kyzivat for his
   multiple detailed reviews and suggested text that significanly significantly
   improved the quality of the document.

   The authors would also like to thank the following for their review
   and feedback on this document:

   Olle Johansson, Roman Shpount, Dale Worley, and Jorgen Axell.

   The authors would also like to thank the following for their review
   and feedback of the original document that was replaced with this
   document:

   Andrew Allen, Martin Dolly, Keith Drage, Paul Kyzivat, Jon Peterson,
   Michael Procter, Roy Radhika, Matt Ryan, Ivo Sedlacek, Roman Shpount,
   Robert Sparks, Asveren Tolga, and Dale Worley. Worley, and Yehoshua Gev.

   The authors would also like to specially thank Jean Mahoney for her review,
   multiple reviews, editorial help, and the coversion of the XML source
   file from v2 to v3.

9.

8.  Normative References

   [OPENID]   Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
              C. Mortimore, "OpenID Connect Core 1.0", February 2014.

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

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <https://www.rfc-editor.org/info/rfc3261>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

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

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

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <https://www.rfc-editor.org/info/rfc7230>.

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

   [RFC7662]  Richer, J., Ed., "OAuth 2.0 Token Introspection",
              RFC 7662, DOI 10.17487/RFC7662, October 2015,
              <https://www.rfc-editor.org/info/rfc7662>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8252]  Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",
              BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017,
              <https://www.rfc-editor.org/info/rfc8252>.

   [RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
              Authorization Server Metadata", RFC 8414,
              DOI 10.17487/RFC8414, June 2018,
              <https://www.rfc-editor.org/info/rfc8414>.

Authors' Addresses

   Rifaat Shekh-Yusef
   Avaya
   425 Legget Drive
   Ottawa Ontario
   Canada

   Phone: +1-613-595-9106
   Email: rifaat.ietf@gmail.com

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   FI- Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com
   Victor Pascual
   webrtchacks
   Spain

   Email: victor.pascual.avila@gmail.com