doc: Add RFC documents

1 files changed, 744 insertions, 0 deletions

diff --git a/doc/rfc/rfc8898.txt b/doc/rfc/rfc8898.txt
new file mode 100644
index 0000000..f45922c
--- /dev/null
+++ b/doc/rfc/rfc8898.txt
@@ -0,0 +1,744 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                    R. Shekh-Yusef
+Request for Comments: 8898                                         Auth0
+Updates: 3261                                                C. Holmberg
+Category: Standards Track                                       Ericsson
+ISSN: 2070-1721                                               V. Pascual
+                                                                   Nokia
+                                                          September 2020
+
+
+  Third-Party Token-Based Authentication and Authorization for Session
+                       Initiation Protocol (SIP)
+
+Abstract
+
+   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 document updates RFC 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 is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8898.
+
+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.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Terminology
+     1.2.  Applicability
+     1.3.  Token Types and Formats
+     1.4.  Example Flows
+       1.4.1.  Registration
+       1.4.2.  Registration with Preconfigured AS
+   2.  SIP Procedures
+     2.1.  UAC Behavior
+       2.1.1.  Obtaining Tokens and Responding to Challenges
+       2.1.2.  Protecting the Access Token
+       2.1.3.  REGISTER Request
+       2.1.4.  Non-REGISTER Request
+     2.2.  User Agent Server (UAS) and Registrar Behavior
+     2.3.  Proxy Behavior
+   3.  Access Token Claims
+   4.  WWW-Authenticate Response Header Field
+   5.  Security Considerations
+   6.  IANA Considerations
+     6.1.  New Proxy-Authenticate Header Field Parameters
+     6.2.  New WWW-Authenticate Header Field Parameters
+   7.  Normative References
+   8.  Informative References
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   The Session Initiation Protocol (SIP) [RFC3261] uses the same
+   framework as HTTP [RFC7230] to authenticate users: a simple
+   challenge-response authentication mechanism that allows a SIP User
+   Agent Server (UAS), proxy, or registrar to challenge a SIP User Agent
+   Client (UAC) request and allows the UAC to provide authentication
+   information in response to that challenge.
+
+   OAuth 2.0 [RFC6749] defines a token-based authorization framework to
+   allow an OAuth client to access resources on behalf of its user.
+
+   The OpenID Connect Core 1.0 specification [OPENID] defines a simple
+   identity layer on top of the OAuth 2.0 protocol, which enables OAuth/
+   OpenID clients to verify the identity of the user based on the
+   authentication performed by a dedicated authorization server (AS),
+   referred to as OpenID Provider (OP), as well as to obtain basic
+   profile information about the user.
+
+   This document defines the "Bearer" authentication scheme for 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 single sign-on, 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 procedures
+   when a UAC receives a 401/407 response with multiple WWW-
+   Authenticate/Proxy-Authenticate header fields, providing challenges
+   using different authentication schemes for the same realm.
+
+
+1.1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+1.2.  Applicability
+
+   This document covers cases where grants that allow the UAC to obtain
+   an access token from the AS are used.  Cases where the UAC is not
+   able to obtain an access token (e.g., in the case of an authorization
+   code grant) are not covered.
+
+
+1.3.  Token Types and Formats
+
+   The tokens used in third-party authorization depend on the type of
+   AS.
+
+   An OAuth AS provides the following tokens to a successfully
+   authorized UAC:
+
+   Access Token:
+      The UAC will use this token to gain access to services by
+      providing the token to a SIP server.
+
+   Refresh Token:
+      The UAC will present this token to the AS to refresh a stale
+      access token.
+
+   An OP returns an additional token:
+
+   ID Token:
+      This token contains a SIP URI associated with the user and other
+      user-specific details that will be consumed by the UAC.
+
+   Tokens can be represented in two different formats:
+
+   Structured Token:
+      A token that consists of a structured object that contains the
+      claims associated with the token, e.g., JSON Web Token (JWT), as
+      defined in [RFC7519].
+
+   Reference Token:
+      A token that consists of an opaque string that is used to obtain
+      the details of the token and its associated claims, as defined in
+      [RFC6749].
+
+   Access tokens are represented in one of the above two formats.
+   Refresh tokens usually are represented in a reference format, as this
+   token is consumed only by the AS that issued the token.  The ID token
+   is defined as a structured token in the form of a JWT.
+
+
+1.4.  Example Flows
+
+1.4.1.  Registration
+
+   Figure 1 below shows an example of a SIP registration where the
+   registrar informs the UAC about the AS from which the UAC can obtain
+   an access token.
+
+     UAC                         Registrar                         AS/OP
+   ---------------------------------------------------------------------
+     |                               |                               |
+     | [1] REGISTER                  |                               |
+     |------------------------------>|                               |
+     |                               |                               |
+     | [2] 401 Unauthorized          |                               |
+     |     WWW-Authenticate: Bearer "authz_server"="<authz_server>"  |
+     |<------------------------------|                               |
+     |                               |                               |
+     | [3] The UAC 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}            |
+     |                               |       (OPTIONAL)              |
+     |                               |------------------------------>|
+     |                               |                               |
+     |                               | [6] 200 OK {metadata}         |
+     |                               |       (OPTIONAL)              |
+     |                               |<------------------------------|
+     |                               |                               |
+     | [7] 200 OK                    |                               |
+     |<------------------------------|                               |
+     |                               |                               |
+
+                    Figure 1: Example Registration Flow
+
+   In step [1], the UAC starts the registration process by sending a SIP
+   REGISTER request to the registrar without any credentials.
+
+   In step [2], the registrar challenges the UA 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
+   to obtain a token.
+
+   In step [3], the 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 and provides the UAC
+   with the tokens needed to access the SIP service.
+
+   In step [4], the UAC retries the registration process by sending a
+   new REGISTER request that includes the access token that the UAC
+   obtained in the step above.
+
+   The registrar validates the access token.  If the 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 and its scope, per [RFC7662].
+   Otherwise, after the registrar validates the token, it inspects its
+   claims and acts upon it.
+
+   In step [7], once the registrar has successfully verified and
+   accepted the access token, it sends a 200 (OK) response to the
+   REGISTER request.
+
+
+1.4.2.  Registration with Preconfigured AS
+
+   Figure 2 shows an example of a SIP registration where the UAC has
+   been preconfigured with information about the AS from which to obtain
+   the access token.
+
+     UAC                         Registrar                         AS/OP
+   ---------------------------------------------------------------------
+     |                               |                               |
+     | [1] The UAC interacts with the AS and obtains tokens using    |
+     |     some out-of-scope mechanism.                              |
+     |<=============================================================>|
+     |                               |                               |
+     | [2] REGISTER                  |                               |
+     |     Authorization: Bearer <access_token>                      |
+     |------------------------------>|                               |
+     |                               | [3] HTTP POST /introspect     |
+     |                               |     {access_token}            |
+     |                               |       (OPTIONAL)              |
+     |                               |------------------------------>|
+     |                               |                               |
+     |                               | [4] 200 OK {metadata}         |
+     |                               |       (OPTIONAL)              |
+     |                               |<------------------------------|
+     |                               |                               |
+     | [5] 200 OK                    |                               |
+     |<------------------------------|                               |
+     |                               |                               |
+
+     Figure 2: Example Registration Flow - AS Information Preconfigured
+
+   In step [1], the UAC interacts with the AS using an out-of-scope
+   mechanism, potentially using the OAuth Native App mechanism defined
+   in [RFC8252].  The AS authenticates the user and provides the UAC
+   with the tokens needed to access the SIP service.
+
+   In step [2], the UAC initiates the registration process by sending a
+   new REGISTER request that includes the access token that the UAC
+   obtained in the step above.
+
+   The registrar validates the access token.  If the access token is a
+   reference token, the registrar MAY perform an introspection
+   [RFC7662], as in steps [4] and [5], in order to obtain more
+   information about the access token and its scope, per [RFC7662].
+   Otherwise, after the registrar validates the token, it inspects its
+   claims and acts upon it.
+
+   In step [5], once the registrar has successfully verified and
+   accepted the access token, it sends a 200 (OK) response to the
+   REGISTER request.
+
+
+2.  SIP Procedures
+
+   Section 22 of [RFC3261] defines the SIP procedures for the Digest
+   authentication mechanism.  The same procedures apply to the "Bearer"
+   authentication mechanism, with the changes described in this section.
+
+2.1.  UAC Behavior
+
+2.1.1.  Obtaining Tokens and Responding to Challenges
+
+   When a UAC sends a request without credentials (or with invalid
+   credentials), it could receive either a 401 (Unauthorized) response
+   with a WWW-Authenticate header field or a 407 (Proxy Authentication
+   Required) response with a Proxy-Authenticate header field.  If the
+   WWW-Authenticate or Proxy-Authenticate header field indicates
+   "Bearer" scheme authentication and contains an address to an AS, the
+   UAC contacts the AS in order to obtain tokens and includes the
+   requested scopes, based on a local configuration (Figure 1).  The UAC
+   MUST check the AS URL received in the 401/407 response against a list
+   of trusted ASs configured on the UAC in order to prevent several
+   classes of possible vulnerabilities when a client blindly attempts to
+   use any provided AS.
+
+   The detailed OAuth2 procedure to authenticate the user and obtain
+   these tokens is out of scope of this document.  The address of the AS
+   might already be known to the UAC via configuration.  In such cases,
+   the UAC can contact the AS for tokens before it sends a SIP request
+   (Figure 2).  Procedures for native applications are defined in
+   [RFC8252].  When using the mechanism defined in [RFC8252], the user
+   of the UAC will be directed to interact with the AS using a web
+   browser, which allows the AS to prompt the user for multi-factor
+   authentication, to redirect the user to third-party identity
+   providers, and to enable the use of single sign-on sessions.
+
+   The tokens returned to the UAC depend on the type of AS; an OAuth AS
+   provides an access token and, optionally, a refresh token [RFC6749].
+   The refresh token is only used between the UAC and the AS.  If the AS
+   provides a refresh token to the UAC, the UAC uses it to request a new
+   access token from the AS before the currently used access token
+   expires ([RFC6749], Section 1.5).  If the AS does not provide a
+   refresh token, the UAC needs to reauthenticate the user in order to
+   get a new access token before the currently used access token
+   expires.  An OP returns an additional ID token that contains claims
+   about the authentication of the user by an authorization server.  The
+   ID token can potentially include other optional claims about the
+   user, e.g., the SIP URI, that will be consumed by the UAC and later
+   used to register with the registrar.
+
+   If 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, the UAC
+   provides credentials for one of the schemes that it supports, based
+   on local policy.
+
+      |  NOTE: At the time of writing, detailed procedures for the cases
+      |  where a UAC receives multiple different authentication schemes
+      |  had not been defined.  A future specification might define such
+      |  procedures.
+
+      |  NOTE: The address of the AS might be known to the UAC, e.g.,
+      |  using means of configuration, in which case the UAC can contact
+      |  the AS in order to obtain the 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, SIP makes use of intermediary SIP proxies, and 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.  SIP
+   endpoints that support this document MUST use encrypted JWTs
+   [RFC7519] for encoding and protecting access tokens when they are
+   included in SIP requests, unless some other mechanism is used to
+   guarantee that only authorized SIP endpoints have access to the
+   access token.  TLS can still be used for protecting traffic between
+   SIP endpoints and the AS, as defined in [RFC6749].
+
+
+2.1.3.  REGISTER Request
+
+   The procedures in this section apply when the UAC has received a
+   challenge that 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 in the request, as specified in
+   [RFC6750].
+
+   Note that if there were multiple challenges with different schemes,
+   then the UAC may be able to successfully retry the request using
+   non-"Bearer" credentials.
+
+   Typically, a UAC will obtain a new access token for each new binding.
+   However, based on local policy, a UAC MAY include an access token
+   that has been used for another binding associated with the same
+   Address Of Record (AOR) in the request.
+
+   If the access token included in a REGISTER request is not accepted
+   and the UAC receives a 401 response or a 407 response, the UAC
+   follows the procedures in Section 2.1.1.
+
+
+2.1.4.  Non-REGISTER Request
+
+   The procedures in this section apply when the UAC has received a
+   challenge that contains a "Bearer" scheme and the UAC has obtained a
+   token, as specified in Section 2.1.1.
+
+   When the UAC sends a request, it MUST include an Authorization header
+   field with a "Bearer" scheme carrying a valid access token obtained
+   from the AS indicated in the challenge in the request, as specified
+   in [RFC6750].  Based on local policy, the UAC MAY include an access
+   token that has been used for another dialog, or for another stand-
+   alone request, if the target of the new request is the same.
+
+   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 the
+   procedures in Section 2.1.1.
+
+
+2.2.  User Agent Server (UAS) and Registrar Behavior
+
+   When a UAS or registrar receives a request that fails to contain
+   authorization credentials acceptable to it, the UAS/registrar SHOULD
+   challenge the request by sending a 401 (Unauthorized) response.  If
+   the UAS/registrar chooses to challenge the request and is willing to
+   accept an access token as a credential, it MUST include a WWW-
+   Authenticate header field in the response that indicates a "Bearer"
+   scheme and includes an AS address, encoded as an https URI [RFC7230],
+   from which the UAC can obtain an access token.
+
+   When a UAS or registrar receives a SIP request that contains an
+   Authorization header field with an access token, the UAS/registrar
+   MUST validate the access token using the procedures associated with
+   the type of access token (structured or reference) used, e.g.,
+   [RFC7519].  If the token provided is an expired access token, then
+   the UAS/registrar MUST reply with a 401 (Unauthorized) response, as
+   defined in Section 3 of [RFC6750].  If the validation is successful,
+   the UAS/registrar can continue to process the request using normal
+   SIP procedures.  If the validation fails, the UAS/registrar MUST
+   reply with a 401 (Unauthorized) response.
+
+
+2.3.  Proxy Behavior
+
+   When a proxy receives a request that fails to contain authorization
+   credentials acceptable to it, it SHOULD challenge the request by
+   sending a 407 (Proxy Authentication Required) response.  If the proxy
+   chooses to challenge the request and is willing to accept an access
+   token as a credential, it MUST include a Proxy-Authenticate header
+   field in the response that indicates a "Bearer" scheme and includes
+   an AS address, encoded as an https URI [RFC7230], from which the UAC
+   can obtain an access token.
+
+   When a proxy wishes 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
+   the credentials from at least one Proxy-Authorization header field
+   for its realm.  When the scheme is "Bearer", the proxy MUST validate
+   the access token using the procedures associated with the type of
+   access token (structured or reference) 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 are based on local policy agreed between the AS
+   and the registrar.
+
+   If an access token is encoded as a JWT, it will contain a list of
+   claims [RFC7519], including both registered and application-specific
+   claims.  The registrar can grant access to services based on such
+   claims, some other mechanism, or a combination of claims and some
+   other mechanism.  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] and user profile
+   lookups.
+
+
+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-param / authz-server-param / error-param /
+                auth-param
+   realm = <defined in RFC 3261>
+   scope-param = "scope" EQUAL DQUOTE scope DQUOTE
+   scope = <defined in RFC 6749>
+   authz-server-param = "authz_server" EQUAL DQUOTE authz-server DQUOTE
+   authz-server = https-URI
+   https-URI = <defined in RFC 7230>
+   error-param = "error" EQUAL DQUOTE error DQUOTE
+   error = <defined in RFC 6749>
+   auth-param = <defined in RFC 3261>
+
+                      Figure 3: "Bearer" Scheme Syntax
+
+   The authz_server parameter contains the HTTPS URI, as defined in
+   [RFC7230], of the AS.  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 user.
+
+   The scope and error parameters are defined in [RFC6749].
+
+   The scope parameter can be used by the registrar/proxy to indicate to
+   the UAC the minimum scope that must be associated with the access
+   token to be able to get service.  As defined in [RFC6749], the value
+   of the scope parameter is expressed as a list of space-delimited,
+   case-sensitive strings.  The strings are defined by the AS.  The
+   values of the scope parameter are out of scope of this document.  The
+   UAC will use the scope provided by the registrar to contact the AS
+   and obtain a proper token with the requested scope.
+
+   The error parameter could be used by the registrar/proxy to indicate
+   to the UAC the reason for the 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 JWTs are defined in [RFC7519].  These
+   security considerations also apply to SIP usage of access tokens, as
+   defined in this document.
+
+   [RFC6749] mandates that access tokens are protected with TLS when in
+   transit.  However, SIP makes use of intermediary SIP proxies, and 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.  SIP
+   endpoints that support this document MUST use encrypted JWTs
+   [RFC7519] for encoding and protecting access tokens when they are
+   included in SIP requests, unless some other mechanism is used to
+   guarantee that only authorized SIP endpoints have access to the
+   access token.  TLS can still be used for protecting traffic between
+   SIP endpoints and the AS, as defined in [RFC6749].
+
+   Single Sign-On (SSO) enables the user to use one set of credentials
+   to authenticate once and gain access to multiple SIP and non-SIP
+   services using access token(s).  If the SSO login is compromised,
+   that single point of compromise has a much broader effect than is the
+   case without SSO.  Further, an attacker can often use a compromised
+   account to set up Single Sign-On for other services that the victim
+   has not established an account with and sometimes can even switch a
+   dedicated account into SSO mode, creating a still broader attack.
+
+   Because of that, it is critical to make sure that extra security
+   measures be taken to safeguard credentials used for Single Sign-On.
+   Examples of such measures include a long passphrase instead of a
+   password, enabling multi-factor authentication, and the use of the
+   native platform browser when possible, as defined in [RFC8252].
+
+   Although this is out of scope for this document, it is important to
+   carefully consider the claims provided in the tokens used to access
+   these services to make sure of the privacy of the user accessing
+   these services.  As mentioned above, this document calls for
+   encrypting JWTs representing the access token.
+
+   It is important that both parties participating in SSO provide
+   mechanisms for users to sever the SSO relationship so that it is
+   possible without undue difficulty to mitigate a compromise that has
+   already happened.
+
+   The operator of an SSO authentication system has access to private
+   information about sites and services that their users log into and
+   even, to some extent, their usage patterns.  It's important to call
+   these out in privacy disclosures and policies and to make sure that
+   users can be aware of the trade-offs between convenience and privacy
+   when they choose to use SSO.
+
+   When a registrar chooses to challenge a REGISTER request, if the
+   registrar can provide access to different levels of services, it is
+   RECOMMENDED that the registrar include a scope in the response in
+   order to indicate the minimum scope needed to register and access
+   basic services.  The access token might include an extended scope
+   that gives the user access to more advanced features beyond basic
+   services.  In SIP, the AS administrator will typically decide what
+   level of access is provided for a given user.
+
+   The UAC MUST check the AS URL received in the 401/407 response
+   against a list of trusted ASs configured on the UAC in order to
+   prevent several classes of possible vulnerabilities when a client
+   blindly attempts to use any provided AS.
+
+
+6.  IANA Considerations
+
+6.1.  New Proxy-Authenticate Header Field Parameters
+
+   This section defines new SIP header field parameters in the "Header
+   Field Parameters and Parameter Values" subregistry of the "Session
+   Initiation Protocol (SIP) Parameters" registry:
+   <https://www.iana.org/assignments/sip-parameters>
+
+            +================+===================+===========+
+            | Parameter Name | Predefined Values | Reference |
+            +================+===================+===========+
+            | authz_server   | No                | RFC 8898  |
+            +----------------+-------------------+-----------+
+            | error          | No                | RFC 8898  |
+            +----------------+-------------------+-----------+
+            | scope          | No                | RFC 8898  |
+            +----------------+-------------------+-----------+
+
+                Table 1: Header Field: Proxy-Authenticate
+
+6.2.  New WWW-Authenticate Header Field Parameters
+
+   This section defines new SIP header field parameters in the "Header
+   Field Parameters and Parameter Values" subregistry of the "Session
+   Initiation Protocol (SIP) Parameters" registry:
+   <https://www.iana.org/assignments/sip-parameters>
+
+            +================+===================+===========+
+            | Parameter Name | Predefined Values | Reference |
+            +================+===================+===========+
+            | authz_server   | No                | RFC 8898  |
+            +----------------+-------------------+-----------+
+            | error          | No                | RFC 8898  |
+            +----------------+-------------------+-----------+
+            | scope          | No                | RFC 8898  |
+            +----------------+-------------------+-----------+
+
+                 Table 2: Header Field: WWW-Authenticate
+
+7.  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>.
+
+8.  Informative References
+
+   [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>.
+
+Acknowledgments
+
+   The authors would like to specially thank Paul Kyzivat for his
+   multiple detailed reviews and suggested text that 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, Dale Worley, and Yehoshua Gev.
+
+   Roman Danyliw, Benjamin Kaduk, Erik Kline, Barry Leiba, Eric Vyncke,
+   and Magnus Westerlund provided feedback and suggestions for
+   improvements as part of the IESG evaluation of the document.  Special
+   thanks to Benjamin Kaduk for his detailed and comprehensive reviews
+   and comments.
+
+   The authors would also like to specially thank Jean Mahoney for her
+   multiple reviews, editorial help, and the conversion of the XML
+   source file from v2 to v3.
+
+Authors' Addresses
+
+   Rifaat Shekh-Yusef
+   Auth0
+   Ottawa Ontario
+   Canada
+
+   Email: rifaat.s.ietf@gmail.com
+
+
+   Christer Holmberg
+   Ericsson
+   Hirsalantie 11
+   FI-02420 Jorvas
+   Finland
+
+   Email: christer.holmberg@ericsson.com
+
+
+   Victor Pascual
+   Nokia
+   Barcelona
+   Spain
+
+   Email: victor.pascual_avila@nokia.com