draft-ietf-sipcore-sip-token-authnz-11.txt   draft-ietf-sipcore-sip-token-authnz-12.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: 24 September 2020 V. Pascual Expires: 25 September 2020 V. Pascual
webrtchacks webrtchacks
23 March 2020 24 March 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-11 draft-ietf-sipcore-sip-token-authnz-12
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 24 September 2020. This Internet-Draft will expire on 25 September 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 4, line 26 skipping to change at page 4, line 26
Tokens can be represented in two different formats: Tokens can be represented in two different formats:
* Structured Token: a token that consists of a structured object * Structured Token: a token that consists of a structured object
that contains the claims associated with the token, e.g. JWT as that contains the claims associated with the token, e.g. JWT as
defined in [RFC7519]. defined in [RFC7519].
* Reference Token: a token that consists of a random string that is * Reference Token: a token that consists of a random string that is
used to obtain the details of the token and its associated claims, used to obtain the details of the token and its associated claims,
as defined in [RFC6749]. as defined in [RFC6749].
Access Tokens could be represnetd in one of the above two formats. Access Tokens could be represented in one of the above two formats.
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
skipping to change at page 7, line 5 skipping to change at page 7, line 5
| | | | | |
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 retries 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 previously.
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.
skipping to change at page 9, line 44 skipping to change at page 9, line 44
request by sending a 401 (Unauthorized) response. To indicate that request by sending a 401 (Unauthorized) response. To indicate that
it is willing to accept an access token as a credential, the UAS/ it is willing to accept an access token as a credential, the UAS/
Registrar MUST include a Proxy-Authentication header field in the Registrar MUST include a Proxy-Authentication header field in the
response that indicates "Bearer" scheme and includes an address of an response that indicates "Bearer" scheme and includes an address of an
authorization server from which the originator can obtain an access authorization server from which the originator can obtain an access
token. token.
When a UAS/Registrar receives a SIP request that contains an When a UAS/Registrar receives a SIP request that contains an
Authorization header field with an access token, the UAS/Registrar Authorization header field with an access token, the UAS/Registrar
MUST validate the access token, using the procedures associated with MUST validate the access token, using the procedures associated with
the type of access token used, e.g. [RFC7519]. If the token the type of access token (Structured or Reference) used, e.g.
provided is an expired access token, then the UAS MUST reply with 401 [RFC7519]. If the token provided is an expired access token, then
Unauthorized, as defined in section 3 of [RFC6750]. If the the UAS MUST reply with 401 Unauthorized, as defined in section 3 of
validation is successful, the UAS/Registrar can continue to process [RFC6750]. If the validation is successful, the UAS/Registrar can
the request using normal SIP procedures. If the validation fails, continue to process the request using normal SIP procedures. If the
the UAS/Registrar MUST reject the request. validation fails, the UAS/Registrar MUST reject the request.
2.3. Proxy Behavior 2.3. Proxy Behavior
When a proxy receives a request that fails to contain authorization When a proxy receives a request that fails to contain authorization
credentials acceptable to it, it SHOULD challenge the request by credentials acceptable to it, it SHOULD challenge the request by
sending a 407 (Proxy Authentication Required) response. To indicate sending a 407 (Proxy Authentication Required) response. To indicate
that it is willing to accept an access token as a credential, the that it is willing to accept an access token as a credential, the
proxy MUST include a Proxy-Authentication header field in the proxy MUST include a Proxy-Authentication header field in the
response that indicates "Bearer" scheme and includes an address to an response that indicates "Bearer" scheme and includes an address to an
authorization server from which the originator can obtain an access authorization server from which the originator can obtain an access
token. token.
When a proxy wishes to authenticate a received request, it MUST When a proxy wishes to authenticate a received request, it MUST
search the request for Proxy-Authorization header fields with 'realm' search the request for Proxy-Authorization header fields with 'realm'
parameters that match its realm. It then MUST successfully validate parameters that match its realm. It then MUST successfully validate
the credentials from at least one Proxy-Authorization header field the credentials from at least one Proxy-Authorization header field
for its realm. When the scheme is "Bearer", the proxy MUST validate for its realm. When the scheme is "Bearer", the proxy MUST validate
the access token, using the procedures associated with the type of the access token, using the procedures associated with the type of
access token used, e.g., [RFC7519]. access token (Structured or Reference) used, e.g., [RFC7519].
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 is based on local policy agreed between the AS provided by the token is based on local policy agreed between the AS
and the registrar. and the registrar.
If an access token is encoded as a JWT, it might contain a list of If an access token is encoded as a JWT, it might contain a list of
claims [RFC7519], some registered and some application-specific. The claims [RFC7519], some registered and some application-specific. The
 End of changes. 8 change blocks. 
13 lines changed or deleted 13 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/