rfc8898xml2.original.xml   rfc8898.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<!-- [rfced] updated by Chris 05/13/20 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="Trust200902"
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true"
ipr="Trust200902" docName="draft-ietf-sipcore-sip-token-authnz-17" number="8898"
submissionType="IETF" xml:lang="en" updates="3261" tocInclude="true" symRefs="true"
category="std" sortRefs="true" version="3">
consensus="true"
docName="draft-ietf-sipcore-sip-token-authnz-17"
number="0000"
xml:lang="en"
updates="3261"
tocInclude="true"
symRefs="true"
sortRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 2.39.0 --> <!-- xml2rfc v2v3 conversion 2.39.0 -->
<!-- ********************************** FRONT ******************************** ** --> <!-- ********************************** FRONT ******************************** ** -->
<front> <front>
<title abbrev="3rd-Party Token-based AuthNZ for SIP"> <title abbrev="3rd-Party Token-Based SIP Authentication">
Third-Party Token-based Authentication and Authorization for Session In Third-Party Token-Based Authentication and Authorization for Session
itiation Protocol (SIP) Initiation Protocol (SIP)</title>
</title> <seriesInfo name="RFC" value="8898"/>
<seriesInfo name="RFC" value="0000"/>
<author initials="R." surname="Shekh-Yusef" fullname="Rifaat Shekh-Yusef"> <author initials="R." surname="Shekh-Yusef" fullname="Rifaat Shekh-Yusef">
<organization>Avaya</organization> <organization>Auth0</organization>
<address> <address>
<postal> <postal>
<street>425 Legget Drive</street> <street></street>
<city>Ottawa</city> <city>Ottawa</city>
<region>Ontario</region> <region>Ontario</region>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<phone>+1-613-595-9106</phone> <phone></phone>
<email>rifaat.ietf@gmail.com</email> <email>rifaat.s.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author initials="C." surname="Holmberg" fullname="Christer Holmberg"> <author initials="C." surname="Holmberg" fullname="Christer Holmberg">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Hirsalantie 11</street> <street>Hirsalantie 11</street>
<city>Jorvas</city><code>02420</code> <city>Jorvas</city>
<code>02420</code>
<region/> <region/>
<country>Finland</country> <country>Finland</country>
</postal> </postal>
<email>christer.holmberg@ericsson.com</email> <email>christer.holmberg@ericsson.com</email>
</address> </address>
</author> </author>
<author initials="V." surname="Pascual" fullname="Victor Pascual"> <author initials="V." surname="Pascual" fullname="Victor Pascual">
<organization>webrtchacks</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<region/> <city>Barcelona</city>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<email>victor.pascual.avila@gmail.com</email> <email>victor.pascual_avila@nokia.com</email>
</address> </address>
</author> </author>
<date year="2020" month="May" /> <date year="2020" month="September"/>
<area>RAI</area> <area>RAI</area>
<workgroup>SIP Core</workgroup> <workgroup>SIP Core</workgroup>
<keyword>SIP OAuth</keyword> <keyword>SIP OAuth</keyword>
<keyword>3rd party authentication</keyword> <keyword>3rd party authentication</keyword>
<keyword>Third party authentication</keyword> <keyword>Third party authentication</keyword>
<abstract> <abstract>
<t> <t>
This document defines the "Bearer" authentication scheme for This document defines the "Bearer" authentication scheme for
the Session Initiation Protocol (SIP), and a mechanism by the Session Initiation Protocol (SIP) and a mechanism by
which user authentication and SIP registration authorization which user authentication and SIP registration authorization
is delegated to a third party, using the OAuth 2.0 framework is delegated to a third party, using the OAuth 2.0 framework
and OpenID Connect Core 1.0. This document updates RFC 3261 and OpenID Connect Core 1.0. This document updates RFC 3261
to provide guidance on how a SIP User Agent Client (UAC) to provide guidance on how a SIP User Agent Client (UAC)
responds to a SIP 401/407 response that contains multiple responds to a SIP 401/407 response that contains multiple
WWW-Authenticate/Proxy-Authenticate header fields. WWW-Authenticate/Proxy-Authenticate header fields.
</t> </t>
</abstract> </abstract>
</front> </front>
<!-- ********************************** MIDDLE ******************************* *** --> <!-- ********************************** MIDDLE ******************************* *** -->
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t> <t>
The Session Initiation Protocol (SIP) <xref target="RFC3261"/> uses the sa me framework The Session Initiation Protocol (SIP) <xref target="RFC3261"/> uses the sa me framework
as HTTP <xref target="RFC7230"/> to authenticate users: a simple as HTTP <xref target="RFC7230"/> to authenticate users: a simple
challenge-response authentication mechanism that allows a SIP User Agent S challenge-response authentication mechanism that allows a SIP User Agent S
erver (UAS), proxy or erver (UAS), proxy, or
registrar to challenge a SIP User Agent Client (UAC) request and allows th registrar to challenge a SIP User Agent Client (UAC) request and allows
e UAC to provide authentication the UAC to provide authentication information in response to that
information in response to that challenge. challenge.
</t> </t>
<t> <t>
OAuth 2.0 <xref target="RFC6749"/> defines a token-based authorization OAuth 2.0 <xref target="RFC6749"/> defines a token-based authorization
framework to allow an OAuth client to access resources on behalf of its us er. framework to allow an OAuth client to access resources on behalf of its us er.
</t> </t>
<t> <t>
The OpenID Connect 1.0 specification <xref target="OPENID"/> defines The OpenID Connect Core 1.0 specification <xref target="OPENID"/> defines
a simple identity layer on top of the OAuth 2.0 protocol, which enables 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 authe ntication OAuth/OpenID clients to verify the identity of the user based on the authe ntication
performed by a dedicated authorization server (AS), referred to as performed by a dedicated authorization server (AS), referred to as
OpenID Provider (OP), as well as to obtain basic profile information about the user. OpenID Provider (OP), as well as to obtain basic profile information about the user.
</t> </t>
<t> <t>
This document defines the "Bearer" authentication scheme for the This document defines the "Bearer" authentication scheme for
Session Initiation Protocol (SIP), and a mechanism by which user SIP and a mechanism by which user
authentication and SIP registration authorization is delegated to a authentication and SIP registration authorization is delegated to a
third party, using the OAuth 2.0 framework and OpenID Connect Core third party, using the OAuth 2.0 framework and OpenID Connect Core
1.0. This kind of user authentication enables single sign-on, 1.0. This kind of user authentication enables single sign-on,
which allows the user to authenticate once and gain access to both SIP which allows the user to authenticate once and gain access to both SIP
and non-SIP services. and non-SIP services.
</t> </t>
<t> <t>
This document also updates <xref target="RFC3261"/>, by defining the UAC p rocedures This document also updates <xref target="RFC3261"/> by defining the UAC pr ocedures
when a UAC receives a 401/407 response with multiple WWW-Authenticate/Prox y-Authenticate when a UAC receives a 401/407 response with multiple WWW-Authenticate/Prox y-Authenticate
header fields, providing challenges using different authentication schemes header fields, providing challenges using different authentication schemes
for the same realm. for the same realm.
</t> </t>
<t> </t> <t> </t>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"MAY", and "OPTIONAL" in this document are to be interpreted as NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t> </t>
<t> </t>
</section> </section>
<section anchor="section.this"> <section anchor="section.this">
<name>Applicability</name> <name>Applicability</name>
<t> <t>
This document covers cases where grants that allow the UAC to obtain an 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 ob tain access token from the AS are used. Cases where the UAC is not able to ob tain
an access token (e.g., in the case of an authorization code grant) are n ot covered. an access token (e.g., in the case of an authorization code grant) are n ot covered.
</t> </t>
<t> </t> <t> </t>
</section> </section>
skipping to change at line 154 skipping to change at line 148
<name>Token Types and Formats</name> <name>Token Types and Formats</name>
<t> <t>
The tokens used in third-party authorization depend on the type of The tokens used in third-party authorization depend on the type of
AS. AS.
</t> </t>
<t> <t>
An OAuth AS provides the following tokens to a successfully An OAuth AS provides the following tokens to a successfully
authorized UAC: authorized UAC:
</t> </t>
<ul spacing="normal"> <dl newline="true" spacing="normal">
<li> <dt>Access Token:</dt>
Access token: the UAC will use this token to gain access to services by <dd>The UAC will use this token to gain access to services by
providing the token to a SIP server. providing the token to a SIP server.</dd>
</li> <dt>Refresh Token:</dt>
<li> <dd>The UAC will present this token to the AS
Refresh token: the UAC will present this token to the AS to refresh a stale access token.</dd>
to refresh a stale access token. </dl>
</li> <t>An OP returns an additional token:</t>
</ul> <dl newline="true" spacing="normal">
<dt>ID Token:</dt>
<t> <dd>This token contains a SIP URI associated with the user and other
An OP returns an additional token: user-specific details that will be consumed by the UAC.</dd>
</t> </dl>
<ul spacing="normal"> <t>Tokens can be represented in two different formats:</t>
<li> <dl newline="true" spacing="normal">
ID Token: this token contains a SIP URI associated with the user and other <dt>Structured Token:</dt>
user-specific details that will be consumed by the UAC. <dd>A token that consists of a structured object that contains the
</li> claims associated with the token, e.g., JSON Web Token (JWT), as defined
</ul> in <xref target="RFC7519"/>.</dd>
<dt>Reference Token:</dt>
<t> <dd>A token that consists of an opaque string that is used to obtain the
Tokens can be represented in two different formats: details of the token and its associated claims, as defined in <xref
</t> target="RFC6749"/>.</dd>
<ul spacing="normal"> </dl>
<li>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 <xref target="RFC7519"/>.
</li>
<li>Reference Token: a token that consists of an opaque string that is use
d
to obtain the details of the token and its associated claims, as defined i
n <xref target="RFC6749"/>.
</li>
</ul>
<t> <t>
Access Tokens are represented in one of the above two formats. Refresh Tok Access tokens are represented in one of the above two formats. Refresh tok
ens ens
usually are represented in a reference format, as this token is consumed o usually are represented in a reference format, as this token is consumed
nly the AS that only by the AS that
issued the token. ID Token is defined as a structured token in the form of issued the token. The ID token is defined as a structured token in the fo
a JWT. rm of a JWT.
</t> </t>
<t></t> <t/>
</section> </section>
<!-- Tokens --> <!-- Tokens -->
<section anchor="sec.authnz.flow"> <section anchor="sec.authnz.flow">
<name>Example Flows</name> <name>Example Flows</name>
<section anchor="sec.reg.discovered.as"> <section anchor="sec.reg.discovered.as">
<name>Registration</name> <name>Registration</name>
<t> <t>
<xref target="fig-register-flow"/> below shows an example of a SIP regis tration, where <xref target="fig-register-flow"/> below shows an example of a SIP regis tration where
the registrar informs the UAC about the AS from which the UAC can the registrar informs the UAC about the AS from which the UAC can
obtain an access token. obtain an access token.
</t> </t>
<figure anchor="fig-register-flow"> <figure anchor="fig-register-flow">
<name>Example Registration Flow</name> <name>Example Registration Flow</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
UAC Registrar AS/OP UAC Registrar AS/OP
--------------------------------------------------------------------- ---------------------------------------------------------------------
| | | | | |
| [1] REGISTER | | | [1] REGISTER | |
|------------------------------>| | |------------------------------>| |
| | | | | |
| [2] 401 Unauthorized | | | [2] 401 Unauthorized | |
| WWW-Authenticate: Bearer "authz_server"="<authz_server>" | | WWW-Authenticate: Bearer "authz_server"="<authz_server>" |
|<------------------------------| | |<------------------------------| |
| | | | | |
| [3] The UAC interacts with the AS and obtains tokens, using | | [3] The UAC interacts with the AS and obtains tokens using |
| some out-of-scope mechanism. | | some out-of-scope mechanism. |
|<=============================================================>| |<=============================================================>|
| | | | | |
| [4] REGISTER | | | [4] REGISTER | |
| Authorization: Bearer <access_token> | | Authorization: Bearer <access_token> |
|------------------------------>| | |------------------------------>| |
| | [5] HTTP POST /introspect | | | [5] HTTP POST /introspect |
| | {access_token} | | | {access_token} |
| | (OPTIONAL) | | | (OPTIONAL) |
| |------------------------------>| | |------------------------------>|
skipping to change at line 244 skipping to change at line 231
| [7] 200 OK | | | [7] 200 OK | |
|<------------------------------| | |<------------------------------| |
| | | | | |
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
In step [1], the UAC starts the registration process by sending a In step [1], the UAC starts the registration process by sending a
SIP REGISTER request to the registrar without any credentials. SIP REGISTER request to the registrar without any credentials.
</t> </t>
<t> <t>
In step [2], the registrar challenges the UA, by sending a SIP In step [2], the registrar challenges the UA by sending a SIP
401 (Unauthorized) response to the REGISTER request. In the response, 401 (Unauthorized) response to the REGISTER request. In the response,
the registrar includes information about the AS to contact in order the registrar includes information about the AS to contact in order
to obtain a token. to obtain a token.
</t> </t>
<t> <t>
In step [3], the UAC interacts with the AS via an out-of-scope mechanism , potentially using the OAuth Native In step [3], the UAC interacts with the AS via an out-of-scope mechanism , potentially using the OAuth Native
App mechanism defined in <xref target="RFC8252"/>. The AS authenticates the user and provides the UAC with the App mechanism defined in <xref target="RFC8252"/>. The AS authenticates the user and provides the UAC with the
tokens needed to access the SIP service. tokens needed to access the SIP service.
</t> </t>
<t> <t>
In step [4], the UAC retries the registration process by sending a new In step [4], the UAC retries the registration process by sending a new
REGISTER request that includes the access token that the UAC REGISTER request that includes the access token that the UAC
obtained in the step above. obtained in the step above.
</t> </t>
<t> <t>
The registrar validates the access token. If the access token is a The registrar validates the access token. If the access token is a
reference token, the registrar MAY perform an introspection reference token, the registrar <bcp14>MAY</bcp14> perform an introspecti on
<xref target="RFC7662"/>, as in steps [5] and [6], in order to obtain mo re <xref target="RFC7662"/>, as in steps [5] and [6], in order to obtain mo re
information about the access token and its scope, per <xref target="RFC7 662"/>. information about the access token and its scope, per <xref target="RFC7 662"/>.
Otherwise, after the registrar validates the token, it inspects its Otherwise, after the registrar validates the token, it inspects its
claims and acts upon it. claims and acts upon it.
</t> </t>
<t> <t>
In step [7], once the registrar has successfully verified and accepted t he In step [7], once the registrar has successfully verified and accepted t he
access token, it sends a 200 (OK) response to the REGISTER request. access token, it sends a 200 (OK) response to the REGISTER request.
</t> </t>
<t> </t> <t> </t>
skipping to change at line 284 skipping to change at line 271
<section anchor="sec.reg.preconfigured.as"> <section anchor="sec.reg.preconfigured.as">
<name>Registration with Preconfigured AS</name> <name>Registration with Preconfigured AS</name>
<t> <t>
<xref target="fig-config-ua"/> shows an example of a SIP registration wh ere <xref target="fig-config-ua"/> shows an example of a SIP registration wh ere
the UAC has been preconfigured with information about the AS the UAC has been preconfigured with information about the AS
from which to obtain the access token. from which to obtain the access token.
</t> </t>
<figure anchor="fig-config-ua"> <figure anchor="fig-config-ua">
<name>Example Registration Flow - AS Information Preconfigured</name> <name>Example Registration Flow - AS Information Preconfigured</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
UAC Registrar AS/OP UAC Registrar AS/OP
--------------------------------------------------------------------- ---------------------------------------------------------------------
| | | | | |
| [1] The UAC interacts with the AS and obtains tokens, using | | [1] The UAC interacts with the AS and obtains tokens using |
| some out of scope mechanism. | | some out-of-scope mechanism. |
|<=============================================================>| |<=============================================================>|
| | | | | |
| [2] REGISTER | | | [2] REGISTER | |
| Authorization: Bearer <access_token> | | Authorization: Bearer <access_token> |
|------------------------------>| | |------------------------------>| |
| | [3] HTTP POST /introspect | | | [3] HTTP POST /introspect |
| | {access_token} | | | {access_token} |
| | (OPTIONAL) | | | (OPTIONAL) |
| |------------------------------>| | |------------------------------>|
| | | | | |
skipping to change at line 321 skipping to change at line 308
App mechanism defined in <xref target="RFC8252"/>. The AS authenticates the user and provides the UAC with the App mechanism defined in <xref target="RFC8252"/>. The AS authenticates the user and provides the UAC with the
tokens needed to access the SIP service. tokens needed to access the SIP service.
</t> </t>
<t> <t>
In step [2], the UAC initiates the registration process by sending a new In step [2], the UAC initiates the registration process by sending a new
REGISTER request that includes the access token that the UAC REGISTER request that includes the access token that the UAC
obtained in the step above. obtained in the step above.
</t> </t>
<t> <t>
The registrar validates the access token. If the access token is a The registrar validates the access token. If the access token is a
reference token, the registrar MAY perform an introspection reference token, the registrar <bcp14>MAY</bcp14> perform an introspecti on
<xref target="RFC7662"/>, as in steps [4] and [5], in order to obtain mo re <xref target="RFC7662"/>, as in steps [4] and [5], in order to obtain mo re
information about the access token and its scope, per <xref target="RFC7 662"/>. information about the access token and its scope, per <xref target="RFC7 662"/>.
Otherwise, after the registrar validates the token, it inspects its Otherwise, after the registrar validates the token, it inspects its
claims and acts upon it. claims and acts upon it.
</t> </t>
<t> <t>
In step [5], once the registrar has successfully verified and accepted t he In step [5], once the registrar has successfully verified and accepted t he
access token, it sends a 200 (OK) response to the REGISTER request. access token, it sends a 200 (OK) response to the REGISTER request.
</t> </t>
<t> </t> <t> </t>
</section> </section>
<!-- Registration with Preconfigured AS--> <!-- Registration with Preconfigured AS-->
</section> </section>
<!-- Example Flows--> <!-- Example Flows-->
</section> </section>
<!-- Introduction --> <!-- Introduction -->
<section anchor="sec.sip"> <section anchor="sec.sip">
<name>SIP Procedures</name> <name>SIP Procedures</name>
<t> <t><xref target="RFC3261" sectionFormat="of" section="22"/> defines the
Section 22 of <xref target="RFC3261"/> defines the SIP procedures for the SIP procedures for the Digest authentication mechanism. The same
Digest authentication mechanism. The same procedures apply to procedures apply to the "Bearer" authentication mechanism, with the
the Bearer authentication mechanism, with the changes described in this se changes described in this section.</t>
ction.
</t>
<section anchor="sec.sip.uac"> <section anchor="sec.sip.uac">
<name>UAC Behavior</name> <name>UAC Behavior</name>
<section anchor="sec.sip.uac.obtain"> <section anchor="sec.sip.uac.obtain">
<name>Obtaining Tokens and Responding to Challenges</name> <name>Obtaining Tokens and Responding to Challenges</name>
<t> <t>
When a UAC sends a request without credentials (or with invalid creden tials), When a UAC sends a request without credentials (or with invalid creden tials),
it could receive either a 401 (Unauthorized) response with a WWW-Authe nticate header field or a 407 (Proxy it could receive either a 401 (Unauthorized) response with a WWW-Authe nticate header field or a 407 (Proxy
Authentication Required) response with a Proxy-Authenticate header fie ld. Authentication Required) response with a Proxy-Authenticate header fie ld.
If the WWW-Authenticate or Proxy-Authenticate header field indicates " Bearer" scheme authentication If the WWW-Authenticate or Proxy-Authenticate header field indicates " Bearer" scheme authentication
and contains an address to an AS, the UAC contacts the and contains an address to an AS, the UAC contacts the
AS in order to obtain tokens, and includes the requested AS in order to obtain tokens and includes the requested
scopes, based on a local configuration (<xref target="fig-register-flo w"/>). scopes, based on a local configuration (<xref target="fig-register-flo w"/>).
The UAC MUST check the AS URL received in the 401/407 response The UAC <bcp14>MUST</bcp14> check the AS URL received in the 401/407 r
against a list of trusted ASs configured on the UAC, in order esponse
against a list of trusted ASs configured on the UAC in order
to prevent several classes of possible vulnerabilities when a client b lindly to prevent several classes of possible vulnerabilities when a client b lindly
attempts to use any provided AS. attempts to use any provided AS.
</t> </t>
<t> <t>
The detailed OAuth2 procedure to authenticate the user and obtain The detailed OAuth2 procedure to authenticate the user and obtain
these tokens is out of scope of this document. these tokens is out of scope of this document.
The address of the AS might already be known to the UAC via configurat ion. The address of the AS might already be known to the UAC via configurat ion.
In such cases, the UAC can contact the AS for tokens In such cases, the UAC can contact the AS for tokens
before it sends a SIP request (<xref target="fig-config-ua"/>). before it sends a SIP request (<xref target="fig-config-ua"/>).
Procedures for native applications are defined in <xref target="RFC825 2"/>. Procedures for native applications are defined in <xref target="RFC825 2"/>.
When using the mechanism defined When using the mechanism defined
in <xref target="RFC8252"/> the user of the UAC will be directed to in in <xref target="RFC8252"/>, the user of the UAC will be directed to i
teract nteract
with the AS using a web browser, allowing the AS with the AS using a web browser, which allows the AS
to prompt the user for multi-factor authentication, to redirect the us er to to prompt the user for multi-factor authentication, to redirect the us er to
third-party identity providers, and to enable the use of single sign-o n sessions. third-party identity providers, and to enable the use of single sign-o n sessions.
</t> </t>
<t> <t>
The tokens returned to the UAC depend on the type of AS: an OAuth AS p The tokens returned to the UAC depend on the type of AS; an OAuth AS p
rovides an rovides an
access token and optionally a refresh token <xref target="RFC6749"/>. access token and, optionally, a refresh token <xref target="RFC6749"/>
The refresh . The refresh
token is only used between the UAC and the AS. If the AS provides a re fresh token token is only used between the UAC and the AS. If the AS provides a re fresh token
to the UAC, the UAC uses it to request a new access token from to the UAC, the UAC uses it to request a new access token from
the AS before the currently used access token expires (<xref target="R the AS before the currently used access token expires (<xref
FC6749"/>, Section 1.5). target="RFC6749" sectionFormat="comma" section="1.5"/>).
If the AS does not provide a refresh token, the UAC needs to re-authen If the AS does not provide a refresh token, the UAC needs to reauthent
ticate the user, icate the user
in order to get a new access token, before the currently used access t in order to get a new access token before the currently used access to
oken expires. ken expires.
An OP returns an additional ID Token that contains claims about An OP returns an additional ID token that contains claims about
the authentication of the user by an authorization server. The ID Toke the authentication of the user by an authorization server. The ID toke
n can potentially n can potentially
include other optional claims about the user, e.g. the SIP URI, that w include other optional claims about the user, e.g., the SIP URI, that
ill be consumed by will be consumed by
the UAC and later used to register with the registrar. the UAC and later used to register with the registrar.
</t> </t>
<t> <t>
If the UAC receives a 401/407 response with multiple WWW- If the UAC receives a 401/407 response with multiple WWW-
Authenticate/Proxy-Authenticate header fields, providing challenges Authenticate/Proxy-Authenticate header fields, providing challenges
using different authentication schemes for the same realm, the UAC using different authentication schemes for the same realm, the UAC
provides credentials for one of the schemes that it supports, provides credentials for one of the schemes that it supports,
based on local policy. based on local policy.
</t> </t>
<aside>
<t> <t>
NOTE: At the time of writing this document, detailed procedures for th NOTE: At the time of writing, detailed
e procedures for the cases where a UAC receives multiple
cases where a UAC receives multiple different authentication schemes h different authentication schemes had not been defined. A
ad not been future specification might define such procedures.
defined. A future specification might define such procedures. </t></aside>
</t> <aside><t>
<t>
NOTE: The address of the AS might be known to the NOTE: The address of the AS might be known to the
UAC e.g., using means of configuration, in which case the UAC can UAC, e.g., using means of configuration, in which case the UAC can
contact the AS in order to obtain the access token contact the AS in order to obtain the access token
before it sends SIP request without credentials. before it sends SIP request without credentials.
</t> </t></aside>
</section> </section>
<section anchor="sec.sip.uac.protect"> <section anchor="sec.sip.uac.protect">
<name>Protecting the Access Token</name> <name>Protecting the Access Token</name>
<t> <t>
<xref target="RFC6749"/> mandates that access tokens are protected wit h <xref target="RFC6749"/> mandates that access tokens are protected wit h
TLS when in transit. However, SIP makes use of intermediary SIP proxie s, TLS when in transit. However, SIP makes use of intermediary SIP proxie s,
and TLS only guarantees hop-to-hop protection when used to protect SIP signaling. 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 aut Therefore, the access token <bcp14>MUST</bcp14> be protected in a way
horized SIP so that only authorized SIP
servers will have access to it. SIP endpoints that support this docume servers will have access to it. SIP endpoints that support this docume
nt MUST nt <bcp14>MUST</bcp14>
use encrypted JSON Web Tokens (JWT) <xref target="RFC7519"/> for encod use encrypted JWTs <xref target="RFC7519"/> for encoding and protectin
ing and protecting g
access tokens when they are included in SIP requests, unless some othe r mechanism access tokens when they are included in SIP requests, unless some othe r mechanism
is used to guarantee that only authorized SIP endpoints have access to is used to guarantee that only authorized SIP endpoints have access to
the access token. TLS can still be used for protecting traffic between the access token. TLS can still be used for protecting traffic between
SIP endpoints and the AS, as defined in <xref target="RFC6749"/>. SIP endpoints and the AS, as defined in <xref target="RFC6749"/>.
</t> </t>
<t> </t> <t> </t>
</section> </section>
<section anchor="sec.sip.uac.req.reg"> <section anchor="sec.sip.uac.req.reg">
<name>REGISTER Request</name> <name>REGISTER Request</name>
<t>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 <xref target="sec.sip.uac.obtain"/>.</t>
<t>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
<xref target="RFC6750"/>.</t>
<t> <t>
The procedures in this section apply when the UAC has received a challen Note that if there were multiple challenges with different schemes, then
ge that contains a "Bearer" scheme, and the UAC has obtained a token as the UAC may be
specified in <xref target="sec.sip.uac.obtain"/>. able to successfully retry the request using non-"Bearer" credentials.
</t>
<t>
The UAC sends a REGISTER request with an Authorization header field cont
aining
the response to the challenge, including the Bearer scheme carrying a va
lid
access token in the request, as specified in <xref target="RFC6750"/>.
</t>
<t>
Note that, if there were multiple challenges with different schemes, the
n the UAC may be
able to successfully retry the request using non-Bearer credentials.
</t>
<t>
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 bindi
ng associated with the same
Address Of Record (AOR) in the request.
</t> </t>
<t>Typically, a UAC will obtain a new access token for each new
binding. However, based on local policy, a UAC <bcp14>MAY</bcp14>
include an access token that has been used for another binding
associated with the same Address Of Record (AOR) in the request.</t>
<t> <t>
If the access token included in a REGISTER request is not accepted, 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 and the UAC receives a 401 response or a 407 response, the UAC
follows the procedures in <xref target="sec.sip.uac.obtain"/>. follows the procedures in <xref target="sec.sip.uac.obtain"/>.
</t> </t>
<t> </t> <t> </t>
</section> </section>
<section anchor="sec.sip.uac.req.nonreg"> <section anchor="sec.sip.uac.req.nonreg">
<name>Non-REGISTER Request</name> <name>Non-REGISTER Request</name>
<t>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 <xref target="sec.sip.uac.obtain"/>.</t>
<t> <t>
The procedures in this section apply when the UAC has received a challen When the UAC sends a request, it <bcp14>MUST</bcp14> include an Author
ge that contains a "Bearer" scheme, and the UAC has obtained a token as ization header field
specified in <xref target="sec.sip.uac.obtain"/>. with a "Bearer" scheme carrying a valid access token obtained from the
</t> AS indicated
<t> in the challenge in the request, as specified in <xref target="RFC6750
When the UAC sends a request, it MUST include an Authorization header "/>.
field Based on local policy, the UAC <bcp14>MAY</bcp14> include an access to
with a Bearer scheme, carrying a valid access token obtained from the ken that has been used
AS indicated
in the challenge, in the request, as specified in <xref target="RFC675
0"/>.
Based on local policy, the UAC MAY include an access token that has be
en used
for another dialog, or for another stand-alone request, if the target of the for another dialog, or for another stand-alone request, if the target of the
new request is the same. new request is the same.
</t> </t>
<t> <t>
If the access token included in a request is not accepted, and the UAC receives 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 a 401 response or a 407 response, the UAC follows the procedures in
<xref target="sec.sip.uac.obtain"/>. <xref target="sec.sip.uac.obtain"/>.
</t> </t>
<t> </t> <t> </t>
</section> </section>
</section> </section>
<!-- UAC Behavior --> <!-- UAC Behavior -->
<section anchor="sec.sip.uas"> <section anchor="sec.sip.uas">
<name>User Agent Server (UAS) and Registrar Behavior</name> <name>User Agent Server (UAS) and Registrar Behavior</name>
<t> <t>
When a UAS or registrar receives a request that fails to contain When a UAS or registrar receives a request that fails to contain
authorization credentials acceptable to it, the UAS/registrar SHOULD cha llenge the authorization credentials acceptable to it, the UAS/registrar <bcp14>SHO ULD</bcp14> challenge the
request by sending a 401 (Unauthorized) response. If the UAS/registrar request by sending a 401 (Unauthorized) response. If the UAS/registrar
chooses to challenge the request, and is willing to accept an access tok chooses to challenge the request and is willing to accept an access toke
en n
as a credential, it MUST include a WWW-Authenticate header as a credential, it <bcp14>MUST</bcp14> include a WWW-Authenticate heade
field in the response that indicates "Bearer" scheme and includes an AS r
address, field in the response that indicates a "Bearer" scheme and includes an A
S address,
encoded as an https URI <xref target="RFC7230"/>, from which the UAC can obtain encoded as an https URI <xref target="RFC7230"/>, from which the UAC can obtain
an access token. an access token.
</t> </t>
<t> <t>
When a UAS or registrar receives a SIP request that contains an Authoriz ation When a UAS or registrar receives a SIP request that contains an Authoriz ation
header field with an access token, the UAS/registrar MUST validate the a header field with an access token, the UAS/registrar <bcp14>MUST</bcp14>
ccess validate the access
token, using the procedures associated with the type of access token (St token using the procedures associated with the type of access token (str
ructured uctured
or Reference) used, e.g., <xref target="RFC7519"/>. or reference) used, e.g., <xref target="RFC7519"/>.
If the token provided is an expired access token, then the UAS/registrar If the token provided is an expired access token, then the UAS/registrar
MUST reply with <bcp14>MUST</bcp14> reply with
a 401 (Unauthorized) response, as defined in section 3 of <xref target=" a 401 (Unauthorized) response, as defined in <xref
RFC6750"/>. target="RFC6750" sectionFormat="of" section="3"/>.
If the validation is successful, the UAS/registrar can continue to proce ss If the validation is successful, the UAS/registrar can continue to proce ss
the request using normal SIP procedures. If the validation fails, the UA S/registrar the request using normal SIP procedures. If the validation fails, the UA S/registrar
MUST reply with 401 (Unauthorized) response. <bcp14>MUST</bcp14> reply with a 401 (Unauthorized) response.
</t> </t>
<t> </t> <t> </t>
</section> </section>
<!-- UAS and Registrar Behavior --> <!-- UAS and Registrar Behavior -->
<section anchor="sec.sip.proxy"> <section anchor="sec.sip.proxy">
<name>Proxy Behavior</name> <name>Proxy Behavior</name>
<t> <t>
When a proxy receives a request that fails to contain When a proxy receives a request that fails to contain
authorization credentials acceptable to it, it SHOULD challenge the authorization credentials acceptable to it, it <bcp14>SHOULD</bcp14> cha llenge the
request by sending a 407 (Proxy Authentication Required) response. request by sending a 407 (Proxy Authentication Required) response.
If the proxy chooses to challenge the request, and is willing to accept If the proxy chooses to challenge the request and is willing to accept a
an access token n access token
as a credential, it MUST include a Proxy-Authenticate as a credential, it <bcp14>MUST</bcp14> include a Proxy-Authenticate
header field in the response that indicates "Bearer" scheme and includes header field in the response that indicates a "Bearer" scheme and includ
an AS address, es an AS address,
encoded as an https URI <xref target="RFC7230"/>, from which the UAC can obtain encoded as an https URI <xref target="RFC7230"/>, from which the UAC can obtain
an access token. an access token.
</t> </t>
<t> <t>
When a proxy wishes to authenticate a received request, it MUST When a proxy wishes to authenticate a received request, it <bcp14>MUST</ bcp14>
search the request for Proxy-Authorization header fields with 'realm' search the request for Proxy-Authorization header fields with 'realm'
parameters that match its realm. It then MUST successfully validate parameters that match its realm. It then <bcp14>MUST</bcp14> successfull y validate
the credentials from at least one Proxy-Authorization header field the credentials from at least one Proxy-Authorization header field
for its realm. When the scheme is "Bearer", the proxy MUST validate the for its realm. When the scheme is "Bearer", the proxy <bcp14>MUST</bcp14
access token, using the procedures associated with the type of access > validate the
token (Structured or Reference) used, e.g., <xref target="RFC7519"/>. access token using the procedures associated with the type of access
token (structured or reference) used, e.g., <xref target="RFC7519"/>.
</t> </t>
<t> </t> <t> </t>
</section> </section>
<!-- Proxy Behavior --> <!-- Proxy Behavior -->
</section> </section>
<!-- SIP Procedures --> <!-- SIP Procedures -->
<section anchor="at.claims"> <section anchor="at.claims">
<name>Access Token Claims</name> <name>Access Token Claims</name>
<t> <t>
skipping to change at line 547 skipping to change at line 533
registrar can grant access to services based on such claims, registrar can grant access to services based on such claims,
some other mechanism, or a combination of claims and some other mechanism. 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 If an access token is a reference token, the registrar will grant access
based on some other mechanism. Examples of such other mechanisms are based on some other mechanism. Examples of such other mechanisms are
introspection <xref target="RFC7662"/> and user profile lookups. introspection <xref target="RFC7662"/> and user profile lookups.
</t> </t>
<t> </t> <t> </t>
</section> </section>
<section anchor="www-authenticate.response.header"> <section anchor="www-authenticate.response.header">
<name>WWW-Authenticate Response Header Field</name> <name>WWW-Authenticate Response Header Field</name>
<t> <t>This section uses ABNF <xref target="RFC5234"/> to describe the
This section uses ABNF <xref target="RFC5234"/> to describe the syntax of syntax of the WWW-Authenticate header field when used with the "Bearer"
the WWW-Authenticate header scheme to challenge the UAC for credentials by extending the
field when used with the "Bearer" scheme to challenge the UAC for credenti 'challenge' parameter defined by <xref target="RFC3261"/>.</t>
als, <figure anchor="bearer-syntax">
by extending the 'challenge' parameter defined by <xref target="RFC3261"/> <name>"Bearer" Scheme Syntax</name>
.
</t> <sourcecode type="abnf">
<figure>
<name>Bearer Scheme Syntax</name>
<sourcecode type="abnf"><![CDATA[
challenge =/ ("Bearer" LWS bearer-cln *(COMMA bearer-cln)) challenge =/ ("Bearer" LWS bearer-cln *(COMMA bearer-cln))
bearer-cln = realm / scope-param / authz-server-param / error-param / bearer-cln = realm / scope-param / authz-server-param / error-param /
auth-param auth-param
realm = <defined in RFC3261> realm = &lt;defined in RFC 3261&gt;
scope-param = "scope" EQUAL DQUOTE scope DQUTE scope-param = "scope" EQUAL DQUOTE scope DQUOTE
scope = <defined in RFC6749> scope = &lt;defined in RFC 6749&gt;
authz-server-param = "authz_server" EQUAL DQUOTE authz-server DQUOTE authz-server-param = "authz_server" EQUAL DQUOTE authz-server DQUOTE
authz-server = https-URI authz-server = https-URI
https-URI = <defined in RFC7230&gt; https-URI = <defined in RFC 7230&gt;
error-param = "error" EQUAL DQUOTE error DQUOTE error-param = "error" EQUAL DQUOTE error DQUOTE
error = <defined in RFC6749> error = &lt;defined in RFC 6749&gt;
auth-param = <defined in RFC3261> auth-param = &lt;defined in RFC 3261&gt;
]]></sourcecode> </sourcecode>
</figure> </figure>
<t> <t>
The authz_server parameter contains the HTTPS URI, as defined in The authz_server parameter contains the HTTPS URI, as defined in
<xref target="RFC7230"/>, of the AS. The UAC can discover <xref target="RFC7230"/>, of the AS. The UAC can discover
metadata about the AS using a mechanism like the one defined in <xref target=" RFC8414"/>. metadata about the AS using a mechanism like the one defined in <xref target=" RFC8414"/>.
</t> </t>
<t> <t>
The realm and auth-param parameters are defined in <xref target="RFC3261"/>. The realm and auth-param parameters are defined in <xref target="RFC3261"/>.
</t> </t>
<t> <t>
Per <xref target="RFC3261"/>, the realm string alone defines the protection Per <xref target="RFC3261"/>, "the realm string alone defines the protection
domain. <xref target="RFC3261"/> states that the realm string must be domain". <xref target="RFC3261"/> states that the realm string must be
globally unique and recommends that the realm string contain a hostname or 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 i dentifier domain name. It also states that the realm string should be a human-readable i dentifier
that can be rendered to the user. that can be rendered to the user.
</t> </t>
<t> <t>
The scope and error parameters are defined in <xref target="RFC6749"/>. The scope and error parameters are defined in <xref target="RFC6749"/>.
</t> </t>
<t> <t>
The scope parameter can be used by the registrar/proxy to indicate to the UAC 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 the minimum scope that must be associated with the access token to be able to get
skipping to change at line 608 skipping to change at line 594
the reason for the error, with possible values of "invalid_token" or "invalid_ scope". the reason for the error, with possible values of "invalid_token" or "invalid_ scope".
</t> </t>
<t> </t> <t> </t>
</section> </section>
<!-- WWW-Authenticate Response Header Field --> <!-- WWW-Authenticate Response Header Field -->
<section anchor="security.considerations"> <section anchor="security.considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
The security considerations for OAuth are defined in <xref target="RFC6749 "/>. The security considerations for OAuth are defined in <xref target="RFC6749 "/>.
The security considerations for bearer tokens are defined in <xref target= The security considerations for "Bearer" tokens are defined in <xref targe
"RFC6750"/>. t="RFC6750"/>.
The security considerations for JSON Web Tokens (JWT) are defined in <xre The security considerations for JWTs are defined in <xref target="RFC7519"
f target="RFC7519"/>. />.
These security considerations also apply to SIP usage of access token as d These security considerations also apply to SIP usage of access tokens, as
efined in this defined in this
document. document.
</t> </t>
<t> <t>
<xref target="RFC6749"/> mandates that access tokens are protected with <xref target="RFC6749"/> mandates that access tokens are protected with
TLS when in transit. However, SIP makes have use of intermediary SIP proxi es, 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 sig naling. and TLS only guarantees hop-to-hop protection when used to protect SIP sig naling.
Therefore the access token MUST be protected in a way so that only authori Therefore, the access token <bcp14>MUST</bcp14> be protected in a way so t
zed SIP hat only authorized SIP
servers will have access to it. SIP endpoints that support this document M servers will have access to it. SIP endpoints that support this document <
UST bcp14>MUST</bcp14>
use encrypted JSON Web Tokens (JWT) <xref target="RFC7519"/> for encoding use encrypted JWTs <xref target="RFC7519"/> for encoding and protecting
and protecting
access tokens when they are included in SIP requests, unless some other me chanism access tokens when they are included in SIP requests, unless some other me chanism
is used to guarantee that only authorized SIP endpoints have access to is used to guarantee that only authorized SIP endpoints have access to
the access token. TLS can still be used for protecting traffic between the access token. TLS can still be used for protecting traffic between
SIP endpoints and the AS, as defined in <xref target="RFC6749"/>. SIP endpoints and the AS, as defined in <xref target="RFC6749"/>.
</t> </t>
<t> <t>
Single Sign-On (SSO) enables the user to use one set of credentials to 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 authenticate once and gain access to multiple SIP and non-SIP services
using access token(s). If the SSO login is compromised, that single 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 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 SSO. Further, an attacker can often use a compromised account to set
up Single Sign-On for other services that the victim has not up Single Sign-On for other services that the victim has not
established an account with, and sometimes can even switch a dedicated established an account with and sometimes can even switch a dedicated
account into Single-Sign-On mode, creating a still broader attack. account into SSO mode, creating a still broader attack.
</t> </t>
<t> <t>
Because of that, it is critical to make sure that extra security Because of that, it is critical to make sure that extra security
measures be taken to safeguard credentials used for Single Sign-On. measures be taken to safeguard credentials used for Single Sign-On.
Examples of such measures include long passphrase instead of a Examples of such measures include a long passphrase instead of a
password, enabling multi-factor factor authentication, and the use of password, enabling multi-factor authentication, and the use of
the native platform browser when possible, as defined in <xref target="RFC 8252"/>. the native platform browser when possible, as defined in <xref target="RFC 8252"/>.
</t> </t>
<t> <t>
Although this is out of scope for this document, it is important to Although this is out of scope for this document, it is important to
carefully consider the claims provided in the tokens used to access carefully consider the claims provided in the tokens used to access
these services to make sure of the privacy of the user accessing these these services to make sure of the privacy of the user accessing these
services. As mentioned above, this document calls for encrypting JWT services. As mentioned above, this document calls for encrypting JWTs
representing the access token. representing the access token.
</t> </t>
<t> <t>
It is important that both parties participating in SSO provide It is important that both parties participating in SSO provide
mechanisms for users to sever the SSO relationship, so that it is mechanisms for users to sever the SSO relationship so that it is
possible without undue difficulty to mitigate a compromise that has possible without undue difficulty to mitigate a compromise that has
already happened. already happened.
</t> </t>
<t> <t>
The operator of a Single-Sign-On authentication system has access to The operator of an SSO authentication system has access to
private information about sites and services that their users log private information about sites and services that their users log
into, and even, to some extent, about their usage patterns. It's into and even, to some extent, their usage patterns. It's
important to call these out in privacy disclosures and policies, and important to call these out in privacy disclosures and policies and
to make sure that users can be aware of the tradeoffs between to make sure that users can be aware of the trade-offs between
convenience and privacy when they choose to use SSO. convenience and privacy when they choose to use SSO.
</t> </t>
<t> <t>
When a registrar chooses to challenge a REGISTER request, if the registrar When a registrar chooses to challenge a REGISTER request, if the registrar
can provide access to different levels of services, it is RECOMMENDED that can provide access to different levels of services, it is <bcp14>RECOMMEND
the registrar includes a scope in the response in order to indicate the mi ED</bcp14> that
nimum the registrar include a scope in the response in order to indicate the min
imum
scope needed to register and access basic services. The access token might scope needed to register and access basic services. The access token might
include an extended scope that gives the user access to more advanced feat ures include an extended scope that gives the user access to more advanced feat ures
beyond basic services. In SIP, the AS administrator will typically decide what level beyond basic services. In SIP, the AS administrator will typically decide what level
of access is provided for a given user. of access is provided for a given user.
</t> </t>
<t> <t>
The UAC MUST check the AS URL received in the 401/407 response The UAC <bcp14>MUST</bcp14> check the AS URL received in the 401/407 respo
against a list of trusted ASs configured on the UAC, in order nse
against a list of trusted ASs configured on the UAC in order
to prevent several classes of possible vulnerabilities when a client blind ly to prevent several classes of possible vulnerabilities when a client blind ly
attempts to use any provided AS. attempts to use any provided AS.
</t> </t>
<t> </t> <t> </t>
</section> </section>
<!-- Security Considerations --> <!-- Security Considerations -->
<section anchor="iana.considerations"> <section anchor="iana.considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="iana.considerations.proxy-authenticate.param"> <section anchor="iana.considerations.proxy-authenticate.param">
<name>New Proxy-Authenticate header field parameters</name> <name>New Proxy-Authenticate Header Field Parameters</name>
<t> <t>
This section defines new SIP header field parameters in the "Header Fiel d This section defines new SIP header field parameters in the "Header Fiel d
Parameters and Parameter Values" subregistry of the "Session Parameters and Parameter Values" subregistry of the "Session
Initiation Protocol (SIP) Parameters" registry: https://www.iana.org/ass Initiation Protocol (SIP) Parameters" registry: <eref
ignments/sip-parameters target="https://www.iana.org/assignments/sip-parameters" brackets="angle"
/>
</t> </t>
<table anchor="proxy-authenticate" align="center">
<figure align="center"><artwork> <name>Header Field: Proxy-Authenticate</name>
<![CDATA[ <thead>
Header Field: Proxy-Authenticate <tr>
<th>Parameter Name</th>
Parameter Name: authz_server <th>Predefined Values</th>
Predefined Values: No <th>Reference</th>
Reference: RFC XXXX </tr>
</thead>
Parameter Name: error <tbody>
Predefined Values: No <tr>
Reference: RFC XXXX <td>authz_server</td>
<td>No</td>
Parameter Name: scope <td>RFC 8898</td>
Predefined Values: No </tr>
Reference: RFC XXXX <tr>
]]></artwork></figure> <td>error</td>
<td>No</td>
<td>RFC 8898</td>
</tr>
<tr>
<td>scope</td>
<td>No</td>
<td>RFC 8898</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="iana.considerations.www-authenticate.param"> <section anchor="iana.considerations.www-authenticate.param">
<name>New WWW-Authenticate header field parameters</name> <name>New WWW-Authenticate Header Field Parameters</name>
<t> <t>
This section defines new SIP header field parameters in the "Header Fiel d This section defines new SIP header field parameters in the "Header Fiel d
Parameters and Parameter Values" subregistry of the "Session Parameters and Parameter Values" subregistry of the "Session
Initiation Protocol (SIP) Parameters" registry: https://www.iana.org/ass Initiation Protocol (SIP) Parameters" registry: <eref
ignments/sip-parameters target="https://www.iana.org/assignments/sip-parameters" brackets="angle"
/>
</t> </t>
<table anchor="www-authenticate" align="center">
<figure align="center"><artwork> <name>Header Field: WWW-Authenticate</name>
<![CDATA[ <thead>
Header Field: WWW-Authenticate <tr>
<th>Parameter Name</th>
Parameter Name: authz_server <th>Predefined Values</th>
Predefined Values: No <th>Reference</th>
Reference: RFC XXXX </tr>
</thead>
Parameter Name: error <tbody>
Predefined Values: No <tr>
Reference: RFC XXXX <td>authz_server</td>
<td>No</td>
Parameter Name: scope <td>RFC 8898</td>
Predefined Values: No </tr>
Reference: RFC XXXX <tr>
]]></artwork></figure> <td>error</td>
<td>No</td>
<td>RFC 8898</td>
</tr>
<tr>
<td>scope</td>
<td>No</td>
<td>RFC 8898</td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
<!-- IANA Considerations --> <!-- IANA Considerations -->
<section anchor="acknowledgments">
<name>Acknowledgments</name>
<t>
The authors would like to specially thank Paul Kyzivat for his multiple de
tailed reviews
and suggested text that significantly improved the quality of the document
.
</t>
<t>
The authors would also like to thank the following for their review and
feedback on this document:
</t>
<t>
Olle Johansson, Roman Shpount, Dale Worley, and Jorgen Axell.
</t>
<t>
The authors would also like to thank the following for their review and
feedback of the original document that was replaced with this document:
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
The authors would also like to specially thank Jean Mahoney for her multip
le
reviews, editorial help, and the coversion of the XML source file from v2
to v3.
</t>
<t></t>
<t></t>
<t></t>
<t></t>
</section>
<!-- Acknowledgments --> <!-- Acknowledgments -->
</middle> </middle>
<!-- ********************************** BACK ********************************* * --> <!-- ********************************** BACK ********************************* * -->
<back> <back>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.2119.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.3261.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.3261.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.6749.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.6749.xml"/>
<!-- [rfced] [OPENID] URL https://openid.net/specs/openid-connect-core-1_0-final
.html -->
<reference anchor="OPENID"> <reference anchor="OPENID">
<front> <front>
<title abbrev="OpenID">OpenID Connect Core 1.0</title> <title abbrev="OpenID">OpenID Connect Core 1.0</title>
<author initials="N." surname="Sakimura" fullname="Nat Sakimura"/> <author initials="N." surname="Sakimura" fullname="Nat Sakimura"/>
<author initials="J." surname="Bradley" fullname="John Bradley"/> <author initials="J." surname="Bradley" fullname="John Bradley"/>
<author initials="M." surname="Jones" fullname="Michael Jones"/> <author initials="M." surname="Jones" fullname="Michael Jones"/>
<author initials="B." surname="de Medeiros" fullname="Breno de Medeiro s"/> <author initials="B." surname="de Medeiros" fullname="Breno de Medeiro s"/>
<author initials="C." surname="Mortimore" fullname="Chuck Mortimore"/> <author initials="C." surname="Mortimore" fullname="Chuck Mortimore"/>
<date month="February" year="2014"/> <date month="February" year="2014"/>
</front> </front>
skipping to change at line 812 skipping to change at line 781
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.6750.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.6750.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.7230.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.7230.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.8174.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.5234.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.5234.xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.8252.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.8252.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.8414.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.8414.xml"/>
</references> </references>
<section anchor="acknowledgments" numbered="false">
<name>Acknowledgments</name>
<t>The authors would like to specially thank <contact fullname="Paul
Kyzivat"/> for his multiple detailed reviews and suggested text that
significantly improved the quality of the document.</t>
<t>The authors would also like to thank the following for their review
and feedback on this document:</t>
<t><contact fullname="Olle Johansson"/>, <contact fullname="Roman
Shpount"/>, <contact fullname="Dale Worley"/>, and <contact
fullname="Jorgen Axell"/>.</t>
<t>The authors would also like to thank the following for their review
and feedback of the original document that was replaced with this
document:</t>
<t><contact fullname="Andrew Allen"/>, <contact fullname="Martin
Dolly"/>, <contact fullname="Keith Drage"/>, <contact fullname="Paul
Kyzivat"/>, <contact fullname="Jon Peterson"/>, <contact
fullname="Michael Procter"/>, <contact fullname="Roy Radhika"/>,
<contact fullname="Matt Ryan"/>, <contact fullname="Ivo Sedlacek"/>,
<contact fullname="Roman Shpount"/>, <contact fullname="Robert
Sparks"/>, <contact fullname="Asveren Tolga"/>, <contact fullname="Dale
Worley"/>, and <contact fullname="Yehoshua Gev"/>.</t>
<t><contact fullname="Roman Danyliw"/>, <contact fullname="Benjamin
Kaduk"/>, <contact fullname="Erik Kline"/>, <contact fullname="Barry
Leiba"/>, <contact fullname="Eric Vyncke"/>, and <contact
fullname="Magnus Westerlund"/> provided feedback and suggestions for
improvements as part of the IESG evaluation of the document. Special
thanks to <contact fullname="Benjamin Kaduk"/> for his detailed and
comprehensive reviews and comments.</t>
<t>The authors would also like to specially thank <contact
fullname="Jean Mahoney"/> for her multiple reviews, editorial help, and
the conversion of the XML source file from v2 to v3.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 82 change blocks. 
338 lines changed or deleted 319 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/