idnits 2.17.1 draft-ietf-sipcore-sip-token-authnz-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (30 April 2020) is 1450 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 263 -- Looks like a reference, but probably isn't: '2' on line 268 -- Looks like a reference, but probably isn't: '3' on line 248 -- Looks like a reference, but probably isn't: '4' on line 274 -- Looks like a reference, but probably isn't: '5' on line 279 -- Looks like a reference, but probably isn't: '6' on line 223 -- Looks like a reference, but probably isn't: '7' on line 228 -- Possible downref: Non-RFC (?) normative reference: ref. 'OPENID' ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Core R. Shekh-Yusef 3 Internet-Draft Avaya 4 Updates: 3261 (if approved) C. Holmberg 5 Intended status: Standards Track Ericsson 6 Expires: 1 November 2020 V. Pascual 7 webrtchacks 8 30 April 2020 10 Third-Party Token-based Authentication and Authorization for Session 11 Initiation Protocol (SIP) 12 draft-ietf-sipcore-sip-token-authnz-14 14 Abstract 16 This document defines the "Bearer" authentication scheme for the 17 Session Initiation Protocol (SIP), and a mechanism by which user 18 authentication and SIP registration authorization is delegated to a 19 third party, using the OAuth 2.0 framework and OpenID Connect Core 20 1.0. This document updates RFC 3261 to provide guidance on how a SIP 21 User Agent Client (UAC) responds to a SIP 401/407 response that 22 contains multiple WWW-Authenticate/Proxy-Authenticate header fields. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 1 November 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 60 1.3. Token Types and Formats . . . . . . . . . . . . . . . . . 3 61 1.4. Example Flows . . . . . . . . . . . . . . . . . . . . . . 4 62 1.4.1. Registration . . . . . . . . . . . . . . . . . . . . 4 63 1.4.2. Registration with Preconfigured AS . . . . . . . . . 6 64 2. SIP Procedures . . . . . . . . . . . . . . . . . . . . . . . 7 65 2.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 7 66 2.1.1. Obtaining Tokens and Responding to Challenges . . . . 7 67 2.1.2. Protecting the Access Token . . . . . . . . . . . . . 9 68 2.1.3. REGISTER Request . . . . . . . . . . . . . . . . . . 9 69 2.1.4. Non-REGISTER Request . . . . . . . . . . . . . . . . 9 70 2.2. User Agent Server (UAS) and Registrar Behavior . . . . . 10 71 2.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 10 72 3. Access Token Claims . . . . . . . . . . . . . . . . . . . . . 11 73 4. WWW-Authenticate Response Header Field . . . . . . . . . . . 11 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 6.1. New Proxy-Authenticate header field parameters . . . . . 14 77 6.2. New WWW-Authenticate header field parameters . . . . . . 14 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 79 8. Normative References . . . . . . . . . . . . . . . . . . . . 15 80 9. Informative References . . . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Introduction 85 The Session Initiation Protocol (SIP) [RFC3261] uses the same 86 framework as HTTP [RFC7230] to authenticate users: a simple 87 challenge-response authentication mechanism that allows a SIP User 88 Agent Server (UAS), proxy or registrar to challenge a SIP User Agent 89 Client (UAC) request and allows the UAC to provide authentication 90 information in response to that challenge. 92 OAuth 2.0 [RFC6749] defines a token-based authorization framework to 93 allow an OAuth client to access resources on behalf of its user. 95 The OpenID Connect 1.0 specification [OPENID] defines a simple 96 identity layer on top of the OAuth 2.0 protocol, which enables OAuth/ 97 OpenID clients to verify the identity of the user based on the 98 authentication performed by a dedicated authorization server (AS), 99 referred to as OpenID Provider (OP), as well as to obtain basic 100 profile information about the user. 102 This document defines the "Bearer" authentication scheme for the 103 Session Initiation Protocol (SIP), and a mechanism by which user 104 authentication and SIP registration authorization is delegated to a 105 third party, using the OAuth 2.0 framework and OpenID Connect Core 106 1.0. This kind of user authentication enables single sign-on, which 107 allows the user to authenticate once and gain access to both SIP and 108 non-SIP services. 110 This document also updates [RFC3261], by defining the UAC procedures 111 when a UAC receives a 401/407 response with multiple WWW- 112 Authenticate/Proxy-Authenticate header fields, providing challenges 113 using different authentication schemes for the same realm. 115 1.1. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 1.2. Applicability 125 This document covers cases where grants that allow the UAC to obtain 126 an access token from the AS are used. Cases where the UAC is not 127 able to obtain an access token (e.g., in the case of an authorization 128 code grant) are not covered. 130 1.3. Token Types and Formats 132 The tokens used in third-party authorization depend on the type of 133 AS. 135 An OAuth AS provides the following tokens to a successfully 136 authorized UAC: 138 * Access token: the UAC will use this token to gain access to 139 services by providing the token to a SIP server. 141 * Refresh token: the UAC will present this token to the AS to 142 refresh a stale access token. 144 An OP returns an additional token: 146 * ID Token: this token contains a SIP URI associated with the user 147 and other user-specific details that will be consumed by the UAC. 149 Tokens can be represented in two different formats: 151 * Structured Token: a token that consists of a structured object 152 that contains the claims associated with the token, e.g., JSON Web 153 Token (JWT) as defined in [RFC7519]. 155 * Reference Token: a token that consists of an opaque string that is 156 used to obtain the details of the token and its associated claims, 157 as defined in [RFC6749]. 159 Access Tokens are represented in one of the above two formats. 160 Refresh Tokens usually are represented in a reference format, as this 161 token is consumed only the AS that issued the token. ID Token is 162 defined as a structured token in the form of a JWT. 164 1.4. Example Flows 166 1.4.1. Registration 168 Figure 1 below shows an example of a SIP registration, where the 169 registrar informs the UAC about the AS from which the UAC can obtain 170 an access token. 172 UAC Registrar AS/OP 173 --------------------------------------------------------------------- 174 | | | 175 | [1] REGISTER | | 176 |------------------------------>| | 177 | | | 178 | [2] 401 Unauthorized | | 179 | WWW-Authenticate: Bearer "authz_server"="" | 180 |<------------------------------| | 181 | | | 182 | [3] The UAC interacts with the AS and obtains tokens, using | 183 | some out-of-scope mechanism. | 184 |<=============================================================>| 185 | | | 186 | [4] REGISTER | | 187 | Authorization: Bearer | 188 |------------------------------>| | 189 | | [5] HTTP POST /introspect | 190 | | {access_token} | 191 | | (OPTIONAL) | 192 | |------------------------------>| 193 | | | 194 | | [6] 200 OK {metadata} | 195 | | (OPTIONAL) | 196 | |<------------------------------| 197 | | | 198 | [7] 200 OK | | 199 |<------------------------------| | 200 | | | 202 Figure 1: Example Registration Flow 204 In step [1], the UAC starts the registration process by sending a SIP 205 REGISTER request to the registrar without any credentials. 207 In step [2], the registrar challenges the UA, by sending a SIP 401 208 (Unauthorized) response to the REGISTER request. In the response, 209 the registrar includes information about the AS to contact in order 210 to obtain a token. 212 In step [3], the UAC interacts with the AS via an out-of-scope 213 mechanism, potentially using the OAuth Native App mechanism defined 214 in [RFC8252]. The AS authenticates the user and provides the UAC 215 with the tokens needed to access the SIP service. 217 In step [4], the UAC retries the registration process by sending a 218 new REGISTER request that includes the access token that the UAC 219 obtained in the step above. 221 The registrar validates the access token. If the access token is a 222 reference token, the registrar MAY perform an introspection 223 [RFC7662], as in steps [5] and [6], in order to obtain more 224 information about the access token and its scope, per [RFC7662]. 225 Otherwise, after the registrar validates the token, it inspects its 226 claims and acts upon it. 228 In step [7], once the registrar has successfully verified and 229 accepted the access token, it sends a 200 (OK) response to the 230 REGISTER request. 232 1.4.2. Registration with Preconfigured AS 234 Figure 2 shows an example of a SIP registration where the UAC has 235 been preconfigured with information about the AS from which to obtain 236 the access token. 238 UAC Registrar AS/OP 239 --------------------------------------------------------------------- 240 | | | 241 | [1] The UAC interacts with the AS and obtains tokens, using | 242 | some out of scope mechanism. | 243 |<=============================================================>| 244 | | | 245 | [2] REGISTER | | 246 | Authorization: Bearer | 247 |------------------------------>| | 248 | | [3] HTTP POST /introspect | 249 | | {access_token} | 250 | | (OPTIONAL) | 251 | |------------------------------>| 252 | | | 253 | | [4] 200 OK {metadata} | 254 | | (OPTIONAL) | 255 | |<------------------------------| 256 | | | 257 | [5] 200 OK | | 258 |<------------------------------| | 259 | | | 261 Figure 2: Example Registration Flow - AS Information Preconfigured 263 In step [1], the UAC interacts with the AS using an out-of-scope 264 mechanism, potentially using the OAuth Native App mechanism defined 265 in [RFC8252]. The AS authenticates the user and provides the UAC 266 with the tokens needed to access the SIP service. 268 In step [2], the UAC initiates the registration process by sending a 269 new REGISTER request that includes the access token that the UAC 270 obtained in the step above. 272 The registrar validates the access token. If the access token is a 273 reference token, the registrar MAY perform an introspection 274 [RFC7662], as in steps [4] and [5], in order to obtain more 275 information about the access token and its scope, per [RFC7662]. 276 Otherwise, after the registrar validates the token, it inspects its 277 claims and acts upon it. 279 In step [5], once the registrar has successfully verified and 280 accepted the access token, it sends a 200 (OK) response to the 281 REGISTER request. 283 2. SIP Procedures 285 Section 22 of [RFC3261] defines the SIP procedures for the Digest 286 authentication mechanism. The same procedures apply to the Bearer 287 authentication mechanism, with the changes described in this section. 289 2.1. UAC Behavior 291 2.1.1. Obtaining Tokens and Responding to Challenges 293 When a UAC sends a request without credentials (or with invalid 294 credentials), it could receive either a 401 (Unauthorized) response 295 with a WWW-Authenticate header field or a 407 (Proxy Authentication 296 Required) response with a Proxy-Authenticate header field. If the 297 WWW-Authenticate or Proxy-Authenticate header field indicates 298 "Bearer" scheme authentication and contains an address to an AS, the 299 UAC contacts the AS in order to obtain tokens, and includes the 300 requested scopes, based on a local configuration (Figure 1). The UAC 301 MUST check the AS URL received in the 401/407 response against a list 302 of trusted ASs configured on the UAC, in order to prevent several 303 classes of possible vulnerabilities when a client blindly attempt to 304 use any provided authorization. 306 The detailed OAuth2 procedure to authenticate the user and obtain 307 these tokens is out of scope of this document. The address of the AS 308 might already be known to the UAC via configuration. In such cases, 309 the UAC can contact the AS for tokens before it sends a SIP request 310 (Figure 2). Procedures for native applications are defined in 311 [RFC8252]. When using the mechanism defined in [RFC8252] the user of 312 the UAC will be directed to interact with the AS using a web browser, 313 allowing the AS to prompt the user for multi-factor authentication, 314 to redirect the user to third-party identity providers, and to enable 315 the use of single sign-on sessions. 317 The tokens returned to the UAC depend on the type of AS: an OAuth AS 318 provides an access token and optionally a refresh token [RFC6749]. 319 The refresh token is only used between the UAC and the AS. If the AS 320 provides a refresh token to the UAC, the UAC uses it to to request a 321 new access token and refresh token from the AS before the currently 322 used access token expires token ([RFC6749], Section 1.5). If the AS 323 does not provide a refresh token, the UAC needs to re-authenticate 324 the user, in order to get a new access token, before the currently 325 used access token expires. An OP returns an additional ID Token that 326 contains claims about the authentication of the user by an 327 authorization server. The ID Token can potentially include other 328 optional claims about the user, e.g. the SIP URI, that will be 329 consumed by the UAC and later used to register with the registrar. 331 If the UAC receives a 401/407 response with multiple WWW- 332 Authenticate/Proxy-Authenticate header fields, providing challenges 333 using different authentication schemes for the same realm, the UAC 334 provides credentials for one of the schemes that it supports, based 335 on local policy. 337 NOTE: At the time of writing this document, detailed procedures for 338 the cases where a UAC receives multiple different authentication 339 schemes had not been defined. A future specification might define 340 such procedures. 342 NOTE: The address of the AS might be known to the UAC e.g., using 343 means of configuration, in which case the UAC can contact the AS in 344 order to obtain the access token before it sends SIP request without 345 credentials. 347 2.1.2. Protecting the Access Token 349 [RFC6749] mandates that access tokens are protected with TLS when in 350 transit. However, SIP makes have use of intermediary SIP proxies, 351 and TLS only guarantees hop-to-hop protection when used to protect 352 SIP signaling. Therefore the access token MUST be protected in a way 353 so that only authorized SIP servers will have access to it. SIP 354 endpoints that support this document MUST use encrypted JSON Web 355 Tokens (JWT) [RFC7519] for encoding and protecting access tokens when 356 they are included in SIP requests, unless some other mechanism is 357 used to guarantee that only authorized SIP endpoints have access to 358 the access token. TLS can still be used for protecting traffic 359 between SIP endpoints and the AS. 361 2.1.3. REGISTER Request 363 The procedures in this section apply when the UAC has received a 364 challenge that contains a "Bearer" scheme, and the UAC has obtained a 365 token as specified in Section 2.1.1. 367 The UAC sends a REGISTER request with an Authorization header field 368 containing the response to the challenge, including the Bearer scheme 369 carrying a valid access token in the request, as specified in 370 [RFC6750]. 372 Note that, if there were multiple challenges with different schemes, 373 then the UAC may be able to successfully retry the request using non- 374 Bearer credentials. 376 Typically, a UAC will obtain a new access token for each new binding, 377 However, based on local policy, a UAC MAY include an access token 378 that has been used for another binding associated with the same 379 Address Of Record (AOR) in the request. 381 If the access token included in a REGISTER request is not accepted, 382 and the UAC receives a 401 response or a 407 response, the UAC 383 follows the procedures in Section 2.1.1. 385 2.1.4. Non-REGISTER Request 387 The procedures in this section apply when the UAC has received a 388 challenge that contains a "Bearer" scheme, and the UAC has obtained a 389 token as specified in Section 2.1.1. 391 When the UAC sends a request, it MUST include an Authorization header 392 field with a Bearer scheme, carrying a valid access token obtained 393 from the AS indicated in the challenge, in the request, as specified 394 in [RFC6750]. Based on local policy, the UAC MAY include an access 395 token that has been used for another dialog, or for another stand- 396 alone request, if the target of the new request is the same. 398 If the access token included in a request is not accepted, and the 399 UAC receives a 401 response or a 407 response, the UAC follows the 400 procedures in Section 2.1.1. 402 2.2. User Agent Server (UAS) and Registrar Behavior 404 When a UAS or registrar receives a request that fails to contain 405 authorization credentials acceptable to it, the UAS/registrar SHOULD 406 challenge the request by sending a 401 (Unauthorized) response. If 407 the UAS/registrar chooses to challenge the request, and is willing to 408 accept an access token as a credential, it MUST include a WWW- 409 Authenticate header field in the response that indicates "Bearer" 410 scheme and includes an AS address, encoded as an https URI [RFC7230], 411 from which the UAC can obtain an access token. 413 When a UAS or registrar receives a SIP request that contains an 414 Authorization header field with an access token, the UAS/registrar 415 MUST validate the access token, using the procedures associated with 416 the type of access token (Structured or Reference) used, e.g., 417 [RFC7519]. If the token provided is an expired access token, then 418 the UAS/registrar MUST reply with a 401 (Unauthorized) response, as 419 defined in section 3 of [RFC6750]. If the validation is successful, 420 the UAS/registrar can continue to process the request using normal 421 SIP procedures. If the validation fails, the UAS/registrar MUST 422 reply with 401 (Unauthorized) response. 424 2.3. Proxy Behavior 426 When a proxy receives a request that fails to contain authorization 427 credentials acceptable to it, it SHOULD challenge the request by 428 sending a 407 (Proxy Authentication Required) response. If the proxy 429 chooses to challenge the request, and is willing to accept an access 430 token as a credential, it MUST include a Proxy-Authenticate header 431 field in the response that indicates "Bearer" scheme and includes an 432 AS address, encoded as an https URI [RFC7230], from which the UAC can 433 obtain an access token. 435 When a proxy wishes to authenticate a received request, it MUST 436 search the request for Proxy-Authorization header fields with 'realm' 437 parameters that match its realm. It then MUST successfully validate 438 the credentials from at least one Proxy-Authorization header field 439 for its realm. When the scheme is "Bearer", the proxy MUST validate 440 the access token, using the procedures associated with the type of 441 access token (Structured or Reference) used, e.g., [RFC7519]. 443 3. Access Token Claims 445 The type of services to which an access token grants access can be 446 determined using different methods. The methods used and the access 447 provided by the token are based on local policy agreed between the AS 448 and the registrar. 450 If an access token is encoded as a JWT, it will contain a list of 451 claims [RFC7519], including both registered and application-specific 452 claimes. The registrar can grant access to services based on such 453 claims, some other mechanism, or a combination of claims and some 454 other mechanism. If an access token is a reference token, the 455 registrar will grant access based on some other mechanism. Examples 456 of such other mechanisms are introspection [RFC7662] and user profile 457 lookups. 459 4. WWW-Authenticate Response Header Field 461 This section uses ABNF [RFC5234] to describe the syntax of the WWW- 462 Authenticate header field when used with the "Bearer" scheme to 463 challenge the UAC for credentials, by extending the 'challenge' 464 parameter defined by [RFC3261]. 466 challenge =/ ("Bearer" LWS bearer-cln *(COMMA bearer-cln)) 467 bearer-cln = realm / scope-param / authz-server-param / error-param / 468 auth-param 469 realm = 470 scope-param = "scope" EQUAL DQUOTE scope DQUTE 471 scope = 472 authz-server-param = "authz_server" EQUAL DQUOTE authz-server DQUOTE 473 authz-server = https-URI 474 https-URI = 475 error-param = "error" EQUAL DQUOTE error DQUOTE 476 error = 477 auth-param = 479 Figure 3: Bearer Scheme Syntax 481 The authz_server parameter contains the HTTPS URI, as defined in 482 [RFC7230], of the AS. The UAC can discover metadata about the AS 483 using a mechanism like the one defined in [RFC8414]. 485 The realm and auth-param parameters are defined in [RFC3261]. 487 Per [RFC3261], the realm string alone defines the protection domain. 488 [RFC3261] states that the realm string must be globally unique and 489 recommends that the realm string contain a hostname or domain name. 490 It also states that the realm string should be a human-readable 491 identifier that can be rendered to the user. 493 The scope and error parameters are defined in [RFC6749]. 495 The scope parameter can be used by the registrar/proxy to indicate to 496 the UAC the minimum scope that must be associated with the access 497 token to be able to get service. As defined in [RFC6749], the value 498 of the scope parameter is expressed as a list of space-delimited, 499 case-sensitive strings. The strings are defined by the AS. The 500 values of the scope parameter are out of scope of this document. The 501 UAC will use the scope provided by the registrar to contact the AS 502 and obtain a proper token with the requested scope. 504 The error parameter could be used by the registrar/proxy to indicate 505 to the UAC the reason for the error, with possible values of 506 "invalid_token" or "invalid_scope". 508 5. Security Considerations 510 The security considerations for OAuth are defined in [RFC6749]. The 511 security considerations for bearer tokens are defined in [RFC6750]. 512 The security considerations for JSON Web Tokens (JWT) are defined in 513 [RFC7519]. These security considerations also apply to SIP usage of 514 access token as defined in this document. 516 [RFC6749] mandates that access tokens are protected with TLS when in 517 transit. However, SIP makes have use of intermediary SIP proxies, 518 and TLS only guarantees hop-to-hop protection when used to protect 519 SIP signaling. Therefore the access token MUST be protected in a way 520 so that only authorized SIP servers will have access to it. SIP 521 endpoints that support this document MUST use encrypted JSON Web 522 Tokens (JWT) [RFC7519] for encoding and protecting access tokens when 523 they are included in SIP requests, unless some other mechanism is 524 used to guarantee that only authorized SIP endpoints have access to 525 the access token. TLS can still be used for protecting traffic 526 between SIP endpoints and the AS. 528 Single Sign-On (SSO) enables the user to use one set of credentials 529 to authenticate once and gain access to multiple SIP and non-SIP 530 services using access token(s). If the SSO login is compromised, 531 that single point of compromise has a much broader effect than is the 532 case without SSO. Further, an attacker can often use a compromised 533 account to set up Single Sign-On for other services that the victim 534 has not established an account with, and sometimes can even switch a 535 dedicated account into Single-Sign-On mode, creating a still broader 536 attack. 538 Because of that, it is critical to make sure that extra security 539 measures be taken to safeguard credentials used for Single Sign-On. 540 Examples of such measures include long passphrase instead of a 541 password, enabling multi-factor factor authentication, and the use of 542 embedded browser when possible, as defined in [RFC8252]. 544 Although this is out of scope for this document, it is important to 545 carefully consider the claims provided in the tokens used to access 546 these services to make sure of the privacy of the user accessing 547 these services. As mentioned above, this document calls for 548 encrypting JWT representing the access token. 550 It is important that both parties participating in SSO provide 551 mechanisms for users to sever the SSO relationship, so that it is 552 possible without undue difficulty to mitigate a compromise that has 553 already happened. 555 The operator of a Single-Sign-On authentication system has access to 556 private information about sites and services that their users log 557 into, and even, to some extent, about their usage patterns. It's 558 important to call these out in privacy disclosures and policies, and 559 to make sure that users can be aware of the tradeoffs between 560 convenience and privacy when they choose to use SSO. 562 When a registrar chooses to challenge a REGISTER request, if the 563 registrar can provide access to different levels of services, it is 564 RECOMMENDED that the registrar includes a scope in the response in 565 order to indicate the minimum scope needed to register and access 566 basic services. The access token might include an extended scope 567 that gives the user access to more advanced features beyond basic 568 services. 570 6. IANA Considerations 571 6.1. New Proxy-Authenticate header field parameters 573 This section defines new SIP header field parameters in the "Header 574 Field Parameters and Parameter Values" subregistry of the "Session 575 Initiation Protocol (SIP) Parameters" registry: 576 https://www.iana.org/assignments/sip-parameters 578 Header Field: Proxy-Authenticate 580 Parameter Name: authz_server 581 Predefined Values: No 582 Reference: RFC XXXX 584 Parameter Name: error 585 Predefined Values: No 586 Reference: RFC XXXX 588 Parameter Name: scope 589 Predefined Values: No 590 Reference: RFC XXXX 592 Figure 4 594 6.2. New WWW-Authenticate header field parameters 596 This section defines new SIP header field parameters in the "Header 597 Field Parameters and Parameter Values" subregistry of the "Session 598 Initiation Protocol (SIP) Parameters" registry: 599 https://www.iana.org/assignments/sip-parameters 601 Header Field: WWW-Authenticate 603 Parameter Name: authz_server 604 Predefined Values: No 605 Reference: RFC XXXX 607 Parameter Name: error 608 Predefined Values: No 609 Reference: RFC XXXX 611 Parameter Name: scope 612 Predefined Values: No 613 Reference: RFC XXXX 615 Figure 5 617 7. Acknowledgments 619 The authors would like to specially thank Paul Kyzivat for his 620 multiple detailed reviews and suggested text that significantly 621 improved the quality of the document. 623 The authors would also like to thank the following for their review 624 and feedback on this document: 626 Olle Johansson, Roman Shpount, Dale Worley, and Jorgen Axell. 628 The authors would also like to thank the following for their review 629 and feedback of the original document that was replaced with this 630 document: 632 Andrew Allen, Martin Dolly, Keith Drage, Paul Kyzivat, Jon Peterson, 633 Michael Procter, Roy Radhika, Matt Ryan, Ivo Sedlacek, Roman Shpount, 634 Robert Sparks, Asveren Tolga, Dale Worley, and Yehoshua Gev. 636 Roman Danyliw, Benjamin Kaduk, Erik Kline, Barry Leiba, Eric Vyncke 637 and Magnus Westerlund provided feedback and suggestions for 638 improvements as part of the IESG evaluation of the document. 640 The authors would also like to specially thank Jean Mahoney for her 641 multiple reviews, editorial help, and the coversion of the XML source 642 file from v2 to v3. 644 8. Normative References 646 [OPENID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 647 C. Mortimore, "OpenID Connect Core 1.0", February 2014. 649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", BCP 14, RFC 2119, 651 DOI 10.17487/RFC2119, March 1997, 652 . 654 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 655 A., Peterson, J., Sparks, R., Handley, M., and E. 656 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 657 DOI 10.17487/RFC3261, June 2002, 658 . 660 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 661 Specifications: ABNF", STD 68, RFC 5234, 662 DOI 10.17487/RFC5234, January 2008, 663 . 665 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 666 RFC 6749, DOI 10.17487/RFC6749, October 2012, 667 . 669 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 670 Framework: Bearer Token Usage", RFC 6750, 671 DOI 10.17487/RFC6750, October 2012, 672 . 674 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 675 Protocol (HTTP/1.1): Message Syntax and Routing", 676 RFC 7230, DOI 10.17487/RFC7230, June 2014, 677 . 679 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 680 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 681 . 683 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 684 RFC 7662, DOI 10.17487/RFC7662, October 2015, 685 . 687 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 688 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 689 May 2017, . 691 9. Informative References 693 [RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", 694 BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, 695 . 697 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 698 Authorization Server Metadata", RFC 8414, 699 DOI 10.17487/RFC8414, June 2018, 700 . 702 Authors' Addresses 703 Rifaat Shekh-Yusef 704 Avaya 705 425 Legget Drive 706 Ottawa Ontario 707 Canada 709 Phone: +1-613-595-9106 710 Email: rifaat.ietf@gmail.com 712 Christer Holmberg 713 Ericsson 714 Hirsalantie 11 715 FI- Jorvas 02420 716 Finland 718 Email: christer.holmberg@ericsson.com 720 Victor Pascual 721 webrtchacks 722 Spain 724 Email: victor.pascual.avila@gmail.com