draft-ietf-sipcore-sip-token-authnz-03.txt   draft-ietf-sipcore-sip-token-authnz-04.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: April 14, 2020 V. Pascual Expires: April 21, 2020 V. Pascual
webrtchacks webrtchacks
October 12, 2019 October 19, 2019
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-03 draft-ietf-sipcore-sip-token-authnz-04
Abstract Abstract
This document defines a mechanism for SIP, that is based on the OAuth This document defines a mechanism for SIP, that is based on the OAuth
2.0 and OpenID Connect Core 1.0 specifications, to enable the 2.0 and OpenID Connect Core 1.0 specifications, to enable the
delegation of the user authentication and SIP registration delegation of the user authentication and SIP registration
authorization to a dedicated third-party entity that is separate from authorization to a dedicated third-party entity that is separate from
the SIP network elements that provide the SIP service. the SIP network elements that provide the SIP service.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 April 14, 2020. This Internet-Draft will expire on April 21, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. SIP User Agent Types . . . . . . . . . . . . . . . . . . 3 1.2. SIP User Agent Types . . . . . . . . . . . . . . . . . . 3
2. SIP Procedures . . . . . . . . . . . . . . . . . . . . . . . 4 2. SIP Procedures . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 4 2.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Obtaining Tokens . . . . . . . . . . . . . . . . . . 4 2.1.1. Obtaining Tokens . . . . . . . . . . . . . . . . . . 4
2.1.2. Protecting the Access Token . . . . . . . . . . . . . 4 2.1.2. Access Token Claims . . . . . . . . . . . . . . . . . 5
2.1.3. REGISTER Request . . . . . . . . . . . . . . . . . . 5 2.1.3. Protecting the Access Token . . . . . . . . . . . . . 5
2.1.4. Non-REGISTER Request . . . . . . . . . . . . . . . . 5 2.1.4. REGISTER Request . . . . . . . . . . . . . . . . . . 5
2.1.5. Non-REGISTER Request . . . . . . . . . . . . . . . . 6
2.2. UAS and Registrar Behavior . . . . . . . . . . . . . . . 6 2.2. UAS and Registrar Behavior . . . . . . . . . . . . . . . 6
2.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 6 2.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 7
3. WWW-Authenticate Response Header Field . . . . . . . . . . . 6 3. WWW-Authenticate Response Header Field . . . . . . . . . . . 7
4. 'sip.token' Media Feature Tag . . . . . . . . . . . . . . . . 7 4. 'sip.token' Media Feature Tag . . . . . . . . . . . . . . . . 8
5. Example Flows . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Example Flows . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Registration . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Registration . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Registration with Pre-Configured AS . . . . . . . . . . . 10 5.2. Registration with Pre-Configured AS . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.1. SIP Media Feaure Tag . . . . . . . . . . . . . . . . . . 12 7.1. SIP Media Feaure Tag . . . . . . . . . . . . . . . . . . 12
7.1.1. sip.token . . . . . . . . . . . . . . . . . . . . . . 12 7.1.1. sip.token . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . 13 9. Normative References . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
skipping to change at page 4, line 31 skipping to change at page 4, line 31
"Bearer" scheme authentication and contains an address to an "Bearer" scheme authentication and contains an address to an
Authorization Server, the UAC contacts the Authorization Server in Authorization Server, the UAC contacts the Authorization Server in
order to obtain tokens. The tokens returned to the UA depend on the order to obtain tokens. The tokens returned to the UA depend on the
type of server: with an OAuth AS, the tokens provided are the access type of server: with an OAuth AS, the tokens provided are the access
token and refresh token. With an OpenID Connect server, an token and refresh token. With an OpenID Connect server, an
additional ID-Token is returned, which contains the SIP URI and other additional ID-Token is returned, which contains the SIP URI and other
user specific details. The method used to authenticate the user and user specific details. The method used to authenticate the user and
obtain these tokens is out of scope for this document, with one obtain these tokens is out of scope for this document, with one
potential method is the Native App mechanism defined in [RFC8252]. potential method is the Native App mechanism defined in [RFC8252].
One of the advantages of using the mechanism defined in [RFC8252] is
that the user will be directed to use a browser to interact with the
authorization server. This allows the authorization server to prompt
the user for multi-factor authentication, redirect the user to third-
party identity providers, and the use of single-sign-on sessions.
If the UAC receives a 401/407 response with multiple WWW-
Authenticate/Proxy-Authenticate header fields, providing challenges
using different authentication schemes for the same realm, the UAC
provides credentials for one or more of the schemes that it supports,
based on local policy.
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. Access Token Claims
The type of services that an access token grants access to can be
determined using different methods. Which methods are used is based
on local policy. If an access token is encoded as a JWT, it might
contain a list of claims [RFC7519], some registered and some are
application specific claims. The REGISTRAR can grant access to
services either based on such claims, using some other mechanism, or
a combination of claims and some other mechanism. If an access token
is a reference token, the REGISTRAR will grant access based on some
other mechanism. Examples of such other mechanisms are introspection
[RFC7662], user profile lookups, etc.
2.1.3. 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
used to protect SIP signaling. Therefore the Access Token MUST be used to protect SIP signaling. Therefore the Access Token MUST be
protected in a way so that only authorized SIP servers will have protected in a way so that only authorized SIP servers will have
access to it. Endpoints that support this specifications MUST access to it. Endpoints that support this specifications MUST
support encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and support encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and
protecting Access Token when included in SIP requests, unless some protecting Access Token when included in SIP requests, unless some
other mechanism is used to guarantee that only authorized SIP other mechanism is used to guarantee that only authorized SIP
endpoints have access to the Access Token. endpoints have access to the Access Token.
2.1.3. REGISTER Request 2.1.4. REGISTER Request
The procedures in this section assumes that the UAC has obtained a The procedures in this section assumes that the UAC has obtained a
token as specified in section Section 2.1.1 token as specified in section Section 2.1.1
When a UAC sends a REGISTER request in order to create a binding, it When a UAC sends a REGISTER request in order to create a binding, it
MUST include an Authorization headerf field with a Bearer scheme, MUST include an Authorization headerf field with a Bearer scheme,
carrying the access token, in the request, as specified in [RFC6750]. carrying the access token, in the request, as specified in [RFC6750].
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 AOR in the
request. request.
When the UAC sends a binding refresh REGISTER request, it SHOULD When the UAC sends a binding refresh REGISTER request, it SHOULD
include an Authorization header field with either the access token include an Authorization header field with either the access token
previously used for the binding, or a new access token (obtained previously used for the binding, or a new access token (obtained
using the refresh token) if the previous one has expired. using the refresh token) if the previous one has expired.
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.5. Non-REGISTER Request
The procedures in this section assumes that the UAC has obtained a The procedures in this section assumes that the UAC has obtained a
token as specified in section Section 2.1.1 token as specified in section Section 2.1.1
When a UAC sends a request in order to initiate a SIP dialog, or When a UAC sends a request in order to initiate a SIP dialog, or
sends a stand-alone request, the UAC MUST include an Authorization sends a stand-alone request, the UAC MUST include an Authorization
header field with a Bearer scheme, carrying the access token, in the header field with a Bearer scheme, carrying the access token, in the
request, as specified in [RFC6750]. Based on local policy, the UAC request, as specified in [RFC6750]. Based on local policy, the UAC
MAY include an access token that has been used for another dialog, or MAY include an access token that has been used for another dialog, or
for another stand-alone request, if the target of the new request is for another stand-alone request, if the target of the new request is
skipping to change at page 7, line 11 skipping to change at page 7, line 36
This section describes the syntax of the WWW-Authenticate Response This section describes the syntax of the WWW-Authenticate Response
Header Field when used with the Bearer scheme to challenge the UA for Header Field when used with the Bearer scheme to challenge the UA for
credentials. credentials.
challenge =/ ("Bearer" LWS bearer-cln *(COMMA bearer-cln)) challenge =/ ("Bearer" LWS bearer-cln *(COMMA bearer-cln))
bearer-cln = realm / scope / authz-server / error / bearer-cln = realm / scope / authz-server / error /
auth-param auth-param
authz-server = "authz_server" EQUAL authz-server-value authz-server = "authz_server" EQUAL authz-server-value
authz-server-value = quoted-string authz-server-value = quoted-string
The authz-server parameters contains the HTTPS URL of the
authorization server.
The realm and auth-param parameters are defined in [RFC3261]. The realm and auth-param parameters are defined in [RFC3261].
As per [RFC3261], the realm string alone defines the protection As per [RFC3261], the realm string alone defines the protection
domain. [RFC3261] states that the realm string must be globally domain. [RFC3261] states that the realm string must be globally
unique and recommends that the realm string contains a hostname or unique and recommends that the realm string contains a hostname or
domain name. It also states that the realm string should be human- domain name. It also states that the realm string should be human-
readable identifier that can be rendered to the user. readable identifier that can be rendered to the user.
The scope and error parameters are defined in [RFC6749]. The scope and error parameters are defined in [RFC6749].
skipping to change at page 8, line 24 skipping to change at page 9, line 24
UA Registrar AS UA 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>" |
|<------------------------------| | |<------------------------------| |
| | | | | |
| [3] The UA colects the user AS credentials | | [3] The UA interacts with the AS and obtains tokens, using |
| | | | some out of scope mechanism. |
| [4] HTTP POST /token | | |<=============================================================>|
|- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ->|
| | |
| [5] 200 OK {access_token, refresh_token, [id_token]} |
|<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|
| | | | | |
| [6] REGISTER | | | [4] REGISTER | |
| Authorization: Bearer <access_token> | | Authorization: Bearer <access_token> |
|------------------------------>| | |------------------------------>| |
| | [7] HTTP POST /introspect | | | [5] HTTP POST /introspect |
| | {access_token} | | | {access_token} |
| |------------------------------>| | |------------------------------>|
| | | | | |
| | [8] 200 OK {metadata} | | | [6] 200 OK {metadata} |
| |<------------------------------| | |<------------------------------|
| | | | | |
| [9] 200 OK | | | [7] 200 OK | |
|<------------------------------| | |<------------------------------| |
| | | | | |
In step [1], the UA starts the registration process by sending a SIP In step [1], the UA starts the registration process by sending a SIP
REGISTER request to the registrar without any credentials. The REGISTER request to the registrar without any credentials. The
REGISTER request includes an indication that the UA supports token- REGISTER request includes an indication that the UA supports token-
based autentication, using a sip.token media feature tag. based autentication, using a sip.token media feature tag.
In step [2], the registrar challenges the UA, by sending a SIP 401 In step [2], the registrar challenges the UA, by sending a SIP 401
(Unauthorized) response to the REGISTER request. In the response the (Unauthorized) response to the REGISTER request. In the response the
registrar includes information about the AS to contact in order to registrar includes information about the AS to contact in order to
obtain a token. obtain a token.
In step [3], the UA collects the user credentials associated with the In step [3], the UA interacts with the AS, potentially using the
AS. OAuth Native App mechanism defined in [RFC8252], authenticates the
user and obtains the tokens needed to access the SIP service.
In steps [4] and [5], the UA contacts the AS in order to authenticate
the user and to obtain tokens to be used to get access to the SIP
network.
The tokens returned to the UA depend on the type of server: with an
OAuth AS, the tokens provided are the access token and refresh token.
With an OpenID Connect server, an additional ID-Token is returned,
which contains the SIP URI of the user. The method used to
authenticate the user and obtain these tokens is out of scope for
this document.
In step [6], the UA retries the registration process by sending a new In step [4], the UA retries the registration process by sending a new
SIP REGISTER request that includes the access token that the UA SIP REGISTER request that includes the access token that the UA
obtrained in steps [10] and [11]. obtrained 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 [7] and [8], in order to obtain more information about the steps [5] and [6], in order to obtain more information about the
access token and its scope, as per [RFC7662]. Otherwise, after the access token and its scope, as 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 act upon it. entity, it inspects its claims and act upon it.
In step [9], once the registrar has succesfully verified and accepted In step [7], once the registrar has succesfully verified and accepted
the access token, it sends a 200 (OK) response to the REGISTER the access token, it sends a 200 (OK) response to the REGISTER
request. request.
5.2. Registration with Pre-Configured AS 5.2. Registration with Pre-Configured AS
The figure belows show an example of a SIP registration, where the UA The figure belows show an example of a SIP registration, where the UA
is has pre-configured information about the Authorization Server (AS) has pre-configured information about the Authorization Server (AS)
from where to obtain the access token. from where to obtain the access token.
UA Registrar AS UA Registrar AS
--------------------------------------------------------------------- ---------------------------------------------------------------------
| | | | | |
| [1] The UA collects the user AS credentials | | [1] The UA interacts with the AS and obtains tokens, using |
| | | | some out of scope mechanism. |
| [2] HTTP POST /token | | |<=============================================================>|
|- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ->|
| | |
| [3] 200 OK {access_token, refresh_token, [id_token]} |
|<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|
| | |
| | | | | |
| [4] REGISTER | | | [2] REGISTER | |
| Authorization: Bearer <access_token> | | Authorization: Bearer <access_token> |
|------------------------------>| | |------------------------------>| |
| | [5] HTTP POST /introspect | | | [3] HTTP POST /introspect |
| | {access_token} | | | {access_token} |
| |------------------------------>| | |------------------------------>|
| | | | | |
| | [6] 200 OK {metadata} | | | [4] 200 OK {metadata} |
| |<------------------------------| | |<------------------------------|
| | | | | |
| [7] 200 OK | | | [5] 200 OK | |
|<------------------------------| | |<------------------------------| |
| | | | | |
In step [1], the UA collects the user credentials associated with the In step [1], the UA interacts with the AS, potentially using the
AS. OAuth Native App mechanism defined in [RFC8252], authenticates the
user and obtains the tokens needed to access the SIP service.
In steps [2] and [3], the UA contacts the AS in order to authenticate
the user and to obtain tokens to be used to get access to the SIP
network.
The tokens returned to the UA depend on the type of server: with an
OAuth AS, the tokens provided are the access token and refresh token.
With an OpenID Connect server, an additional ID-Token is returned,
which contains the SIP URI of the user. The method used to
authenticate the user and obtain these tokens is out of scope for
this document.
In step [4], the UA retries the registration process by sending a new In step [2], the UA retries the registration process by sending a new
SIP REGISTER request that includes the access token that the UA SIP REGISTER request that includes the access token that the UA
obtrained in steps [10] and [11]. obtrained 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 [5] and [6], 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, as per [RFC7662]. Otherwise, after the access token and its scope, as 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 act upon it. entity, it inspects its claims and act upon it.
In step [7], once the registrar has succesfully verified and accepted In step [5], once the registrar has succesfully verified and accepted
the access token, it sends a 200 (OK) response to the REGISTER the access token, it sends a 200 (OK) response to the REGISTER
request. request.
6. Security Considerations 6. Security Considerations
The security considerations for OAuth are defined in [RFC6749]. The The security considerations for OAuth are defined in [RFC6749]. The
security considerations for bearer tokens are defined in [RFC6750]. security considerations for bearer tokens are defined in [RFC6750].
The security considerations for JSON Web Tokens (JWT) are defined in The security considerations for JSON Web Tokens (JWT) are defined in
[RFC7519]. These security considerations also apply to SIP usage of [RFC7519]. These security considerations also apply to SIP usage of
access token as defined in this document. access token as defined in this document.
 End of changes. 33 change blocks. 
74 lines changed or deleted 74 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/