idnits 2.17.1 draft-ietf-sipcore-sip-token-authnz-17.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 (5 May 2020) is 1445 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: 6 November 2020 V. Pascual 7 webrtchacks 8 5 May 2020 10 Third-Party Token-based Authentication and Authorization for Session 11 Initiation Protocol (SIP) 12 draft-ietf-sipcore-sip-token-authnz-17 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 6 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 . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . . 17 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 attempts to 304 use any provided AS. 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 request a new 321 access token from the AS before the currently used access token 322 expires ([RFC6749], Section 1.5). If the AS does not provide a 323 refresh token, the UAC needs to re-authenticate the user, in order to 324 get a new access token, before the currently used access token 325 expires. An OP returns an additional ID Token that contains claims 326 about the authentication of the user by an authorization server. The 327 ID Token can potentially include other optional claims about the 328 user, e.g. the SIP URI, that will be consumed by the UAC and later 329 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 use of intermediary SIP proxies, and TLS 351 only guarantees hop-to-hop protection when used to protect SIP 352 signaling. Therefore the access token MUST be protected in a way so 353 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, as defined in [RFC6749]. 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 claims. 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, as defined in [RFC6749]. 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 the native platform 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. In SIP, the AS administrator will typically decide what 569 level of access is provided for a given user. 571 The UAC MUST check the AS URL received in the 401/407 response 572 against a list of trusted ASs configured on the UAC, in order to 573 prevent several classes of possible vulnerabilities when a client 574 blindly attempts to use any provided AS. 576 6. IANA Considerations 578 6.1. New Proxy-Authenticate header field parameters 580 This section defines new SIP header field parameters in the "Header 581 Field Parameters and Parameter Values" subregistry of the "Session 582 Initiation Protocol (SIP) Parameters" registry: 583 https://www.iana.org/assignments/sip-parameters 585 Header Field: Proxy-Authenticate 587 Parameter Name: authz_server 588 Predefined Values: No 589 Reference: RFC XXXX 591 Parameter Name: error 592 Predefined Values: No 593 Reference: RFC XXXX 595 Parameter Name: scope 596 Predefined Values: No 597 Reference: RFC XXXX 599 Figure 4 601 6.2. New WWW-Authenticate header field parameters 603 This section defines new SIP header field parameters in the "Header 604 Field Parameters and Parameter Values" subregistry of the "Session 605 Initiation Protocol (SIP) Parameters" registry: 606 https://www.iana.org/assignments/sip-parameters 608 Header Field: WWW-Authenticate 610 Parameter Name: authz_server 611 Predefined Values: No 612 Reference: RFC XXXX 614 Parameter Name: error 615 Predefined Values: No 616 Reference: RFC XXXX 618 Parameter Name: scope 619 Predefined Values: No 620 Reference: RFC XXXX 621 Figure 5 623 7. Acknowledgments 625 The authors would like to specially thank Paul Kyzivat for his 626 multiple detailed reviews and suggested text that significantly 627 improved the quality of the document. 629 The authors would also like to thank the following for their review 630 and feedback on this document: 632 Olle Johansson, Roman Shpount, Dale Worley, and Jorgen Axell. 634 The authors would also like to thank the following for their review 635 and feedback of the original document that was replaced with this 636 document: 638 Andrew Allen, Martin Dolly, Keith Drage, Paul Kyzivat, Jon Peterson, 639 Michael Procter, Roy Radhika, Matt Ryan, Ivo Sedlacek, Roman Shpount, 640 Robert Sparks, Asveren Tolga, Dale Worley, and Yehoshua Gev. 642 Roman Danyliw, Benjamin Kaduk, Erik Kline, Barry Leiba, Eric Vyncke 643 and Magnus Westerlund provided feedback and suggestions for 644 improvements as part of the IESG evaluation of the document. Special 645 thanks to Benjamin Kaduk for his detailed and comprehensive reviews 646 and comments. 648 The authors would also like to specially thank Jean Mahoney for her 649 multiple reviews, editorial help, and the coversion of the XML source 650 file from v2 to v3. 652 8. Normative References 654 [OPENID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 655 C. Mortimore, "OpenID Connect Core 1.0", February 2014. 657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 658 Requirement Levels", BCP 14, RFC 2119, 659 DOI 10.17487/RFC2119, March 1997, 660 . 662 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 663 A., Peterson, J., Sparks, R., Handley, M., and E. 664 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 665 DOI 10.17487/RFC3261, June 2002, 666 . 668 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 669 Specifications: ABNF", STD 68, RFC 5234, 670 DOI 10.17487/RFC5234, January 2008, 671 . 673 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 674 RFC 6749, DOI 10.17487/RFC6749, October 2012, 675 . 677 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 678 Framework: Bearer Token Usage", RFC 6750, 679 DOI 10.17487/RFC6750, October 2012, 680 . 682 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 683 Protocol (HTTP/1.1): Message Syntax and Routing", 684 RFC 7230, DOI 10.17487/RFC7230, June 2014, 685 . 687 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 688 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 689 . 691 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 692 RFC 7662, DOI 10.17487/RFC7662, October 2015, 693 . 695 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 696 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 697 May 2017, . 699 9. Informative References 701 [RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", 702 BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, 703 . 705 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 706 Authorization Server Metadata", RFC 8414, 707 DOI 10.17487/RFC8414, June 2018, 708 . 710 Authors' Addresses 712 Rifaat Shekh-Yusef 713 Avaya 714 425 Legget Drive 715 Ottawa Ontario 716 Canada 718 Phone: +1-613-595-9106 719 Email: rifaat.ietf@gmail.com 721 Christer Holmberg 722 Ericsson 723 Hirsalantie 11 724 FI- Jorvas 02420 725 Finland 727 Email: christer.holmberg@ericsson.com 729 Victor Pascual 730 webrtchacks 731 Spain 733 Email: victor.pascual.avila@gmail.com