draft-ietf-sipcore-sip-token-authnz-15.txt   draft-ietf-sipcore-sip-token-authnz-16.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
SIP Core R. Shekh-Yusef SIP Core R. Shekh-Yusef
Internet-Draft Avaya Internet-Draft Avaya
Updates: 3261 (if approved) C. Holmberg Updates: 3261 (if approved) C. Holmberg
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: 6 November 2020 V. Pascual Expires: 6 November 2020 V. Pascual
webrtchacks webrtchacks
5 May 2020 5 May 2020
Third-Party Token-based Authentication and Authorization for Session Third-Party Token-based Authentication and Authorization for Session
Initiation Protocol (SIP) Initiation Protocol (SIP)
draft-ietf-sipcore-sip-token-authnz-15 draft-ietf-sipcore-sip-token-authnz-16
Abstract Abstract
This document defines the "Bearer" authentication scheme for the This document defines the "Bearer" authentication scheme for the
Session Initiation Protocol (SIP), and a mechanism by which user Session Initiation Protocol (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 document updates RFC 3261 to provide guidance on how a SIP 1.0. This document updates RFC 3261 to provide guidance on how a SIP
User Agent Client (UAC) responds to a SIP 401/407 response that User Agent Client (UAC) responds to a SIP 401/407 response that
contains multiple WWW-Authenticate/Proxy-Authenticate header fields. contains multiple WWW-Authenticate/Proxy-Authenticate header fields.
skipping to change at page 2, line 31 skipping to change at page 2, line 31
2.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 7 2.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Obtaining Tokens and Responding to Challenges . . . . 7 2.1.1. Obtaining Tokens and Responding to Challenges . . . . 7
2.1.2. Protecting the Access Token . . . . . . . . . . . . . 9 2.1.2. Protecting the Access Token . . . . . . . . . . . . . 9
2.1.3. REGISTER Request . . . . . . . . . . . . . . . . . . 9 2.1.3. REGISTER Request . . . . . . . . . . . . . . . . . . 9
2.1.4. Non-REGISTER Request . . . . . . . . . . . . . . . . 9 2.1.4. Non-REGISTER Request . . . . . . . . . . . . . . . . 9
2.2. User Agent Server (UAS) and Registrar Behavior . . . . . 10 2.2. User Agent Server (UAS) and Registrar Behavior . . . . . 10
2.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 10 2.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 10
3. Access Token Claims . . . . . . . . . . . . . . . . . . . . . 11 3. Access Token Claims . . . . . . . . . . . . . . . . . . . . . 11
4. WWW-Authenticate Response Header Field . . . . . . . . . . . 11 4. WWW-Authenticate Response Header Field . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.1. New Proxy-Authenticate header field parameters . . . . . 14 6.1. New Proxy-Authenticate header field parameters . . . . . 14
6.2. New WWW-Authenticate header field parameters . . . . . . 14 6.2. New WWW-Authenticate header field parameters . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. Normative References . . . . . . . . . . . . . . . . . . . . 15 8. Normative References . . . . . . . . . . . . . . . . . . . . 15
9. Informative References . . . . . . . . . . . . . . . . . . . 16 9. Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [RFC3261] uses the same The Session Initiation Protocol (SIP) [RFC3261] uses the same
framework as HTTP [RFC7230] to authenticate users: a simple framework as HTTP [RFC7230] to authenticate users: a simple
challenge-response authentication mechanism that allows a SIP User challenge-response authentication mechanism that allows a SIP User
Agent Server (UAS), proxy or registrar to challenge a SIP User Agent Agent Server (UAS), proxy or registrar to challenge a SIP User Agent
Client (UAC) request and allows the UAC to provide authentication Client (UAC) request and allows the UAC to provide authentication
information in response to that challenge. information in response to that challenge.
skipping to change at page 7, line 40 skipping to change at page 7, line 40
When a UAC sends a request without credentials (or with invalid When a UAC sends a request without credentials (or with invalid
credentials), it could receive either a 401 (Unauthorized) response credentials), it could receive either a 401 (Unauthorized) response
with a WWW-Authenticate header field or a 407 (Proxy Authentication with a WWW-Authenticate header field or a 407 (Proxy Authentication
Required) response with a Proxy-Authenticate header field. If the Required) response with a Proxy-Authenticate header field. If the
WWW-Authenticate or Proxy-Authenticate header field indicates WWW-Authenticate or Proxy-Authenticate header field indicates
"Bearer" scheme authentication and contains an address to an AS, the "Bearer" scheme authentication and contains an address to an AS, the
UAC contacts the AS in order to obtain tokens, and includes the UAC contacts the AS in order to obtain tokens, and includes the
requested scopes, based on a local configuration (Figure 1). The UAC requested scopes, based on a local configuration (Figure 1). The UAC
MUST check the AS URL received in the 401/407 response against a list MUST check the AS URL received in the 401/407 response against a list
of trusted ASs configured on the UAC, in order to prevent several of trusted ASs configured on the UAC, in order to prevent several
classes of possible vulnerabilities when a client blindly attempt to classes of possible vulnerabilities when a client blindly attempts to
use any provided authorization. use any provided AS.
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. The address of the AS these tokens is out of scope of this document. The address of the AS
might already be known to the UAC via configuration. In such cases, might already be known to the UAC via configuration. In such cases,
the UAC can contact the AS for tokens before it sends a SIP request the UAC can contact the AS for tokens before it sends a SIP request
(Figure 2). Procedures for native applications are defined in (Figure 2). Procedures for native applications are defined in
[RFC8252]. When using the mechanism defined in [RFC8252] the user of [RFC8252]. When using the mechanism defined in [RFC8252] the user of
the UAC will be directed to interact with the AS using a web browser, the UAC will be directed to interact with the AS using a web browser,
allowing the AS to prompt the user for multi-factor authentication, allowing the AS to prompt the user for multi-factor authentication,
to redirect the user to third-party identity providers, and to enable to redirect the user to third-party identity providers, and to enable
the use of single sign-on sessions. the use of single sign-on sessions.
The tokens returned to the UAC depend on the type of AS: an OAuth AS The tokens returned to the UAC depend on the type of AS: an OAuth AS
provides an access token and optionally a refresh token [RFC6749]. provides an access token and optionally a refresh token [RFC6749].
The refresh token is only used between the UAC and the AS. If the AS The refresh token is only used between the UAC and the AS. If the AS
provides a refresh token to the UAC, the UAC uses it to request a new provides a refresh token to the UAC, the UAC uses it to request a new
access token and refresh token from the AS before the currently used access token from the AS before the currently used access token
access token expires ([RFC6749], Section 1.5). If the AS does not expires ([RFC6749], Section 1.5). If the AS does not provide a
provide a refresh token, the UAC needs to re-authenticate the user, refresh token, the UAC needs to re-authenticate the user, in order to
in order to get a new access token, before the currently used access get a new access token, before the currently used access token
token expires. An OP returns an additional ID Token that contains expires. An OP returns an additional ID Token that contains claims
claims about the authentication of the user by an authorization about the authentication of the user by an authorization server. The
server. The ID Token can potentially include other optional claims ID Token can potentially include other optional claims about the
about the user, e.g. the SIP URI, that will be consumed by the UAC user, e.g. the SIP URI, that will be consumed by the UAC and later
and later used to register with the registrar. used to register with the registrar.
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, based provides credentials for one of the schemes that it supports, based
on local policy. on local policy.
NOTE: At the time of writing this document, detailed procedures for NOTE: At the time of writing this document, detailed procedures for
the cases where a UAC receives multiple different authentication the cases where a UAC receives multiple different authentication
schemes had not been defined. A future specification might define schemes had not been defined. A future specification might define
skipping to change at page 11, line 22 skipping to change at page 11, line 22
3. Access Token Claims 3. Access Token Claims
The type of services to which an access token grants access can be The type of services to which an access token grants access can be
determined using different methods. The methods used and the access determined using different methods. The methods used and the access
provided by the token are based on local policy agreed between the AS provided by the token are based on local policy agreed between the AS
and the registrar. and the registrar.
If an access token is encoded as a JWT, it will contain a list of If an access token is encoded as a JWT, it will contain a list of
claims [RFC7519], including both registered and application-specific claims [RFC7519], including both registered and application-specific
claimes. The registrar can grant access to services based on such claims. The registrar can grant access to services based on such
claims, some other mechanism, or a combination of claims and some claims, some other mechanism, or a combination of claims and some
other mechanism. If an access token is a reference token, the other mechanism. If an access token is a reference token, the
registrar will grant access based on some other mechanism. Examples registrar will grant access based on some other mechanism. Examples
of such other mechanisms are introspection [RFC7662] and user profile of such other mechanisms are introspection [RFC7662] and user profile
lookups. lookups.
4. WWW-Authenticate Response Header Field 4. WWW-Authenticate Response Header Field
This section uses ABNF [RFC5234] to describe the syntax of the WWW- This section uses ABNF [RFC5234] to describe the syntax of the WWW-
Authenticate header field when used with the "Bearer" scheme to Authenticate header field when used with the "Bearer" scheme to
skipping to change at page 13, line 19 skipping to change at page 13, line 19
case without SSO. Further, an attacker can often use a compromised case without SSO. Further, an attacker can often use a compromised
account to set up Single Sign-On for other services that the victim account to set up Single Sign-On for other services that the victim
has not established an account with, and sometimes can even switch a has not established an account with, and sometimes can even switch a
dedicated account into Single-Sign-On mode, creating a still broader dedicated account into Single-Sign-On mode, creating a still broader
attack. attack.
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 long passphrase instead of a
password, enabling multi-factor factor authentication, and the use of password, enabling multi-factor factor authentication, and the use of
embedded browser when possible, as defined in [RFC8252]. the native platform browser when possible, as defined in [RFC8252].
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 services to make sure of the privacy of the user accessing
these services. As mentioned above, this document calls for these services. As mentioned above, this document calls for
encrypting JWT representing the access token. encrypting JWT representing the access token.
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
skipping to change at page 13, line 45 skipping to change at page 13, line 45
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 tradeoffs between
convenience and privacy when they choose to use SSO. convenience and privacy when they choose to use SSO.
When a registrar chooses to challenge a REGISTER request, if the When a registrar chooses to challenge a REGISTER request, if the
registrar can provide access to different levels of services, it is registrar can provide access to different levels of services, it is
RECOMMENDED that the registrar includes a scope in the response in RECOMMENDED that the registrar includes a scope in the response in
order to indicate the minimum scope needed to register and access order to indicate the minimum scope needed to register and access
basic services. The access token might include an extended scope basic services. The access token might include an extended scope
that gives the user access to more advanced features beyond basic that gives the user access to more advanced features beyond basic
services. services. In SIP, the AS administrator will typicall decide what
level of access is provided for a given user.
The UAC MUST check the AS URL received in the 401/407 response
against a list of trusted ASs configured on the UAC, in order to
prevent several classes of possible vulnerabilities when a client
blindly attempts to use any provided AS.
6. IANA Considerations 6. IANA Considerations
6.1. New Proxy-Authenticate header field parameters 6.1. New Proxy-Authenticate header field parameters
This section defines new SIP header field parameters in the "Header This section defines new SIP header field parameters in the "Header
Field Parameters and Parameter Values" subregistry of the "Session Field Parameters and Parameter Values" subregistry of the "Session
Initiation Protocol (SIP) Parameters" registry: Initiation Protocol (SIP) Parameters" registry:
https://www.iana.org/assignments/sip-parameters https://www.iana.org/assignments/sip-parameters
Header Field: Proxy-Authenticate Header Field: Proxy-Authenticate
Parameter Name: authz_server Parameter Name: authz_server
skipping to change at page 15, line 26 skipping to change at page 15, line 27
The authors would also like to thank the following for their review The authors would also like to thank the following for their review
and feedback of the original document that was replaced with this and feedback of the original document that was replaced with this
document: document:
Andrew Allen, Martin Dolly, Keith Drage, Paul Kyzivat, Jon Peterson, Andrew Allen, Martin Dolly, Keith Drage, Paul Kyzivat, Jon Peterson,
Michael Procter, Roy Radhika, Matt Ryan, Ivo Sedlacek, Roman Shpount, Michael Procter, Roy Radhika, Matt Ryan, Ivo Sedlacek, Roman Shpount,
Robert Sparks, Asveren Tolga, Dale Worley, and Yehoshua Gev. Robert Sparks, Asveren Tolga, Dale Worley, and Yehoshua Gev.
Roman Danyliw, Benjamin Kaduk, Erik Kline, Barry Leiba, Eric Vyncke Roman Danyliw, Benjamin Kaduk, Erik Kline, Barry Leiba, Eric Vyncke
and Magnus Westerlund provided feedback and suggestions for and Magnus Westerlund provided feedback and suggestions for
improvements as part of the IESG evaluation of the document. improvements as part of the IESG evaluation of the document. Special
thanks to Benjamin Kaduk for his detailed and comprehinsive reviews
and comments.
The authors would also like to specially thank Jean Mahoney for her The authors would also like to specially thank Jean Mahoney for her
multiple reviews, editorial help, and the coversion of the XML source multiple reviews, editorial help, and the coversion of the XML source
file from v2 to v3. file from v2 to v3.
8. Normative References 8. Normative References
[OPENID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and [OPENID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0", February 2014. C. Mortimore, "OpenID Connect Core 1.0", February 2014.
 End of changes. 10 change blocks. 
18 lines changed or deleted 27 lines changed or added

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