draft-ietf-sipcore-sip-token-authnz-12.txt   draft-ietf-sipcore-sip-token-authnz-13.txt 
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: 25 September 2020 V. Pascual Expires: 17 October 2020 V. Pascual
webrtchacks webrtchacks
24 March 2020 15 April 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-12 draft-ietf-sipcore-sip-token-authnz-13
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 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 25 September 2020. This Internet-Draft will expire on 17 October 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
skipping to change at page 3, line 9 skipping to change at page 3, line 9
The OpenID Connect 1.0 specification [OPENID] defines a simple The OpenID Connect 1.0 specification [OPENID] defines a simple
identity layer on top of the OAuth 2.0 protocol, which enables identity layer on top of the OAuth 2.0 protocol, which enables
clients to verify the identity of the user based on the clients to verify the identity of the user based on the
authentication performed by a dedicated authorization server, as well authentication performed by a dedicated authorization server, as well
as to obtain basic profile information about the user. as to obtain basic profile information about the user.
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 kind of user authentication enables the single-sign-on 1.0. This kind of user authentication enables single sign-on, which
feature, which allows the user to authenticate once and gain access allows the user to authenticate once and gain access to both SIP and
to both SIP and non-SIP services. non-SIP services.
This document also updates [RFC3261], by defining the User Agent This document also updates [RFC3261], by defining the User Agent
Client (UAC) procedures when a UAC receives a 401/407 response with Client (UAC) procedures when a UAC receives a 401/407 response with
multiple WWW-Authenticate/Proxy-Authenticate header fields, providing multiple WWW-Authenticate/Proxy-Authenticate header fields, providing
challenges using different authentication schemes for the same realm. challenges using different authentication schemes for the same realm.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 4, line 37 skipping to change at page 4, line 37
Refresh Tokens usualy are represented in a reference format, as this Refresh Tokens usualy are represented in a reference format, as this
token is consumed only the AS that issued the token. ID Token is token is consumed only the AS that issued the token. ID Token is
defined as a structured token in the form of a JWT. defined as a structured token in the form of a JWT.
1.4. Example Flows 1.4. Example Flows
1.4.1. Registration 1.4.1. Registration
Figure 1 below shows an example of a SIP registration, where the Figure 1 below shows an example of a SIP registration, where the
registrar informs the UAC about the authorization server from which registrar informs the UAC about the authorization server from which
the UAC can obtain an access token in a 401 response to the REGISTER the UAC can obtain an access token.
request.
UAC Registrar AS UAC Registrar AS
--------------------------------------------------------------------- ---------------------------------------------------------------------
| | | | | |
| [1] REGISTER | | | [1] REGISTER | |
|------------------------------>| | |------------------------------>| |
| | | | | |
| [2] 401 Unauthorized | | | [2] 401 Unauthorized | |
| WWW-Authenticate: Bearer "authz_server"="<authz_server>" | | WWW-Authenticate: Bearer "authz_server"="<authz_server>" |
|<------------------------------| | |<------------------------------| |
skipping to change at page 5, line 50 skipping to change at page 5, line 50
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.
In step [3], the UAC interacts with the AS via an out-of-scope In step [3], the UAC interacts with the AS via an out-of-scope
mechanism, potentially using the OAuth Native App mechanism defined mechanism, potentially using the OAuth Native App mechanism defined
in [RFC8252]. The AS authenticates the user and provides the UAC in [RFC8252]. The AS authenticates the user and provides the UAC
with the tokens needed to access the SIP service. with the tokens needed to access the SIP service.
In step [4], the UAC retries the registration process by sending a In step [4], the UAC retries the registration process by sending a
new REGISTER request that includes the access token that the UAC new REGISTER request that includes the access token that the UAC
obtained previously. obtained in the step above.
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 MAY perform an introspection
[RFC7662], as in steps [5] and [6], in order to obtain more [RFC7662], as in steps [5] and [6], in order to obtain more
information about the access token and its scope, per [RFC7662]. information about the access token and its scope, per [RFC7662].
Otherwise, after the registrar validates the token to make sure it Otherwise, after the registrar validates the token to make sure it
was signed by a trusted entity, it inspects its claims and acts upon was signed by a trusted entity, it inspects its claims and acts upon
it. it.
In step [7], once the registrar has successfully verified and In step [7], once the registrar has successfully verified and
skipping to change at page 7, line 7 skipping to change at page 7, line 7
Figure 2: Example Registration Flow - Authorization Server Figure 2: Example Registration Flow - Authorization Server
Information Preconfigured Information Preconfigured
In step [1], the UAC interacts with the AS using an out-of-scope In step [1], the UAC interacts with the AS using an out-of-scope
mechanism, potentially using the OAuth Native App mechanism defined mechanism, potentially using the OAuth Native App mechanism defined
in [RFC8252]. The AS authenticates the user and provides the UAC in [RFC8252]. The AS authenticates the user and provides the UAC
with the tokens needed to access the SIP service. with the tokens needed to access the SIP service.
In step [2], the UAC initiates the registration process by sending a In step [2], the UAC initiates the registration process by sending a
new REGISTER request that includes the access token that the UAC new REGISTER request that includes the access token that the UAC
obtained previously. obtained in the step above.
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, as in reference token, the registrar MAY perform an introspection, as in
steps [3] and [4], in order to obtain more information about the steps [3] and [4], in order to obtain more information about the
access token and its scope, per [RFC7662]. Otherwise, after the access token and its scope, per [RFC7662]. Otherwise, after the
registrar validates the token to make sure it was signed by a trusted registrar validates the token to make sure it was signed by a trusted
entity, it inspects its claims and acts upon it. entity, it inspects its claims and acts upon it.
In step [5], once the registrar has successfully verified and In step [5], once the registrar has successfully verified and
accepted the access token, it sends a 200 (OK) response to the accepted the access token, it sends a 200 (OK) response to the
skipping to change at page 7, line 50 skipping to change at page 7, line 50
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 these tokens is out of scope of this document. The address of the
authorization server might already be known to the UAC via authorization server might already be known to the UAC via
configuration. In which case, the UAC can contact the authorization configuration. In which case, the UAC can contact the authorization
server for tokens before it sends a SIP request (Figure 2). server for tokens before it sends a SIP request (Figure 2).
Procedures for native applications are defined in [RFC8252]. When Procedures for native applications are defined in [RFC8252]. When
using the mechanism defined in [RFC8252] the user of the UAC will be using the mechanism defined in [RFC8252] the user of the UAC will be
directed to interact with the authorization server using a web directed to interact with the authorization server using a web
browser, allowing the authorization server to prompt the user for browser, allowing the authorization server to prompt the user for
multi-factor authentication, to redirect the user to third-party multi-factor authentication, to redirect the user to third-party
identity providers, and to enable the use of single-sign-on sessions. identity providers, and to enable the use of single sign-on sessions.
The tokens returned to the UAC depend on the type of authorization The tokens returned to the UAC depend on the type of authorization
server (AS): an OAuth AS provides an access token and refresh token server (AS): an OAuth AS provides an access token and refresh token
[RFC6749]. The UAC provides the access token to the SIP servers to [RFC6749]. The UAC provides the access token to the SIP servers to
authorize UAC's access to the service. The UAC uses the refresh authorize UAC's access to the service. The UAC uses the refresh
token only with the AS to get a new access token and refresh token token only with the AS to get a new access token and refresh token
before the expiry of the current access token (see [RFC6749], section before the expiry of the current access token (see [RFC6749], section
1.5 Refresh Token for details). An OpenID Connect server returns an 1.5 Refresh Token for details). An OpenID Connect server returns an
additional ID-Token containing the SIP URI and other user-specific additional ID-Token containing the SIP URI and other user-specific
details that will be consumed by the UAC. details that will be consumed by the UAC.
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 or more of the schemes that it supports, selects one or more of the provided schemes (based on local policy)
based on local policy. and provides credentials for those schemes.
NOTE: The address of the Authorization Server might be known to the NOTE: The address of the Authorization Server 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 Authorization Server in order to obtain the access token contact the Authorization Server in order to obtain the access token
before it sends SIP request without credentials. before it sends SIP request without credentials.
2.1.2. Protecting the Access Token 2.1.2. Protecting the Access Token
[RFC6749] mandates that access tokens are protected with TLS when in [RFC6749] mandates that access tokens are protected with TLS when in
transit. However, TLS only guarantees hop-to-hop protection when transit. However, TLS only guarantees hop-to-hop protection when
skipping to change at page 9, line 6 skipping to change at page 9, line 6
The UAC sends a REGISTER request with an Authorization header field The UAC sends a REGISTER request with an Authorization header field
containing the response to the challenge, including the Bearer scheme containing the response to the challenge, including the Bearer scheme
carrying a valid access token in the request, as specified in carrying a valid access token in the request, as specified in
[RFC6750]. [RFC6750].
Note that, if there were multiple challenges with different schemes, Note that, if there were multiple challenges with different schemes,
then the UAC may be able to successfully retry the request using non- then the UAC may be able to successfully retry the request using non-
Bearer credentials. Bearer credentials.
Based on local policy, the UAC MAY include an access token that has Based on local policy, the UAC MAY include an access token that has
been used for another binding associated with the same AOR in the been used for another binding associated with the same Address Of
request. Record (AOR) in the request.
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 Section 2.1.1. follows the procedures in Section 2.1.1.
2.1.4. Non-REGISTER Request 2.1.4. Non-REGISTER Request
The procedures in this section apply when the UAC has received a The procedures in this section apply when the UAC has received a
challenge that contains a "Bearer" scheme, and the UAC has obtained a challenge that contains a "Bearer" scheme, and the UAC has obtained a
token as specified in Section 2.1.1. token as specified in Section 2.1.1.
 End of changes. 11 change blocks. 
16 lines changed or deleted 15 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/