< draft-ietf-sipcore-sip-token-authnz-01.txt   draft-ietf-sipcore-sip-token-authnz-02.txt >
SIP Core R. Shekh-Yusef, Ed. SIP Core R. Shekh-Yusef, Ed.
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: December 26, 2019 V. Pascual Expires: January 8, 2020 V. Pascual
webrtchacks webrtchacks
June 24, 2019 July 7, 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-01 draft-ietf-sipcore-sip-token-authnz-02
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 December 26, 2019. This Internet-Draft will expire on January 8, 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 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. SIP User Agent Types . . . . . . . . . . . . . . . . . . 3 1.2. SIP User Agent Types . . . . . . . . . . . . . . . . . . 3
2. Authentication and Authorization flow . . . . . . . . . . . . 4 2. Authentication and Authorization flow . . . . . . . . . . . . 4
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Configured AS . . . . . . . . . . . . . . . . . . . . 4 2.1.1. Configured AS . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Discovered AS . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Discovered AS . . . . . . . . . . . . . . . . . . . . 6
2.2. Initial Registration . . . . . . . . . . . . . . . . . . 7 2.2. Initial Registration . . . . . . . . . . . . . . . . . . 7
2.3. Subsequent Registrations . . . . . . . . . . . . . . . . 8 2.3. Subsequent Registrations . . . . . . . . . . . . . . . . 8
2.4. Non-Registration Requests . . . . . . . . . . . . . . . . 8
3. WWW-Authenticate Response Header Field . . . . . . . . . . . 8 3. WWW-Authenticate Response Header Field . . . . . . . . . . . 8
4. 'sip.token' Media Feature Tag . . . . . . . . . . . . . . . . 8 4. 'sip.token' Media Feature Tag . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. SIP Media Feaure Tag . . . . . . . . . . . . . . . . . . 9 6.1. SIP Media Feaure Tag . . . . . . . . . . . . . . . . . . 10
6.1.1. sip.token . . . . . . . . . . . . . . . . . . . . . . 9 6.1.1. sip.token . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . 10 8. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The SIP protocol [RFC3261] uses the framework used by the HTTP The SIP protocol [RFC3261] uses the framework used by the HTTP
protocol for authenticating users, which is a simple challenge- protocol for authenticating users, which is a simple challenge-
response authentication mechanism that allows a server to challenge a response authentication mechanism that allows a server to challenge a
client request and allows a client to provide authentication client request and allows a client to provide authentication
information in response to that challenge. information in response to that challenge.
OAuth 2.0 [RFC6749] defines a token based authorization framework to OAuth 2.0 [RFC6749] defines a token based authorization framework to
skipping to change at page 6, line 13 skipping to change at page 6, line 13
the 200 OK to complete the registration process. the 200 OK to complete the registration process.
2.1.2. Discovered AS 2.1.2. Discovered AS
The following figure provides a high level view of flow of messages The following figure provides a high level view of flow of messages
when the UA discovers the AS to conatc from the registrar: when the UA discovers the AS to conatc from the registrar:
UA Registrar AS UA Registrar AS
--------------------------------------------------------------------- ---------------------------------------------------------------------
| | | | | |
[07] The UA prompts the user to provides his credentials | | [07] REGISTER | |
| | |
| [08] REGISTER | |
|------------------------------>| | |------------------------------>| |
| | | | | |
| [09] 401 Unauthorized | | | [08] 401 Unauthorized | |
| WWW-Authenticate: Bearer "authz_server"="<authz_server>" | | WWW-Authenticate: Bearer "authz_server"="<authz_server>" |
|<------------------------------| | |<------------------------------| |
| | | | | |
[09] The UA prompts the user to provides his credentials |
| | |
| [10] HTTP POST /token | | | [10] HTTP POST /token | |
|-------------------------------------------------------------->| |-------------------------------------------------------------->|
| | | | | |
| [11] 200 OK {access_token, refresh_token, [id_token]} | | [11] 200 OK {access_token, refresh_token, [id_token]} |
|<--------------------------------------------------------------| |<--------------------------------------------------------------|
| | | | | |
| [12] REGISTER | | | [12] REGISTER | |
| Authorization: Bearer <access_token> | | Authorization: Bearer <access_token> |
|------------------------------>| | |------------------------------>| |
| | [13] HTTP POST /introspect | | | [13] HTTP POST /introspect |
| | {access_token} | | | {access_token} |
| |------------------------------>| | |------------------------------>|
| | | | | |
| | [14] 200 OK {metadata} | | | [14] 200 OK {metadata} |
| |<------------------------------| | |<------------------------------|
| | | | | |
| [15] 200 OK | | | [15] 200 OK | |
|<------------------------------| | |<------------------------------| |
| | | | | |
In step [07], the UA collects the user's credentials with the AS. In step [07] the UA starts the registration process by sending a SIP
In step [08] 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 in the form of sip.token media feature tag. The based autentication in the form of sip.token media feature tag. The
registrar then challenges the UA, in step [09], by responding with registrar then challenges the UA, in step [08], by responding with
401 Unauthorized and includes the authorization server to contact to 401 Unauthorized and includes the authorization server to contact to
obtain a token. obtain a token.
In step [09], the UA collects the user's credentials with the AS.
In steps [10] and [11], the UA contacts the Authorization Server to In steps [10] and [11], the UA contacts the Authorization Server to
authenticate the user and obtain tokens to be used to get access to authenticate the user and obtain tokens to be used to get access to
the SIP network. the SIP network.
The tokens returned to the UA depend on the type of server: with an The tokens returned to the UA depend on the type of server: with an
OAuth Authorization Server, the tokens provided are the access token OAuth Authorization Server, the tokens provided are the access token
and refresh token. With an OpenID Connect server, an additional ID- and refresh token. With an OpenID Connect server, an additional ID-
Token is returned, which contains the SIP URI of the user. The Token is returned, which contains the SIP URI of the user. The
method used to authenticate the user and obtain these tokens is out method used to authenticate the user and obtain these tokens is out
of scope for this document. of scope for this document.
skipping to change at page 7, line 35 skipping to change at page 7, line 35
was signed by a trusted entity, it inspects its claims and act upon was signed by a trusted entity, it inspects its claims and act upon
it. it.
2.2. Initial Registration 2.2. Initial Registration
If the UA has already obtained a token, then the UA starts the If the UA has already obtained a token, then the UA starts the
registration process, step [03], by sending a REGISTER request, with registration process, step [03], by sending a REGISTER request, with
the access token in the Authorization header, to the registrar. the access token in the Authorization header, to the registrar.
If the UA does not have a token, then the UA starts the registration If the UA does not have a token, then the UA starts the registration
process, step [08], by sending a REGISTER request without an process, step [07], by sending a REGISTER request without an
Authorization header. The registrar MUST then challenge the UA by Authorization header. The registrar MUST then challenge the UA by
responding with 401 Unauthorized and include the WWW-Authenticate responding with 401 Unauthorized and include the WWW-Authenticate
Response Header Field which includes the server to contact to obtain Response Header Field which includes the server to contact to obtain
a token, as specified in Section 3 a token, as specified in Section 3
The REGISTER request SHOULD include a sip.token media feature tag in The REGISTER request SHOULD include a sip.token media feature tag in
the Contact header field of the request, unless it knows (e.g., by the Contact header field of the request, unless it knows (e.g., by
means of configuration) that the registrar supports the token means of configuration) that the registrar supports the token
authentication mechanism. authentication mechanism.
skipping to change at page 8, line 18 skipping to change at page 8, line 18
access token. The UA MUST obtain a new access token before the access token. The UA MUST obtain a new access token before the
access token expiry period to continue to get service from the access token expiry period to continue to get service from the
system. The method used to obtain a new fresh access tokens is out system. The method used to obtain a new fresh access tokens is out
of scope for this document. of scope for this document.
The REGISTER request SHOULD include a sip.token media feature tag in The REGISTER request SHOULD include a sip.token media feature tag in
the Contact header field of the request, unless it knows (e.g., by the Contact header field of the request, unless it knows (e.g., by
means of configuration) that the registrar supports the token means of configuration) that the registrar supports the token
authentication mechanism. authentication mechanism.
2.4. Non-Registration Requests
The UA MUST NOT insert a token in a non-REGISTER request, unless the
non-REGISTER request has been challenged, or the peer is considered a
trusted entity.
If a non-REGISTER request from the UA is challenged with a WWW-
Authenticate header field to provide credentials for the same realm
specified in the challenge to the registration request, then the UA
MUST include a valid access token in the request retry. The UA MUST
include an Authorization header field with the Bearer scheme in the
request to carry the access token, as specified in [RFC6750].
Challenges with WWW-Authenticate with different realm specified in
the challenge to the registration request are out of scope for this
document. Challenges with Proxy-Authenticate are out of scope for
this document.
3. WWW-Authenticate Response Header Field 3. WWW-Authenticate Response Header Field
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 / domain / 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 realm, domain, and auth-param parameters are defined in The realm and auth-param parameters are defined in [RFC3261].
[RFC3261].
As per [RFC3261], the realm string alone defines the protection
domain. [RFC3261] states that the realm string must be globally
unique and recommends that the realm string contains a hostname or
domain name. It also states that the realm string should be human-
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].
The scope parameter could be used by the registrar/proxy to indicate
to the UAC the minimum scope that must be associated with the access
token to be able to get service. As defined in [RFC6749], the value
of the scope parameter is expressed as a list of space-delimited,
case-sensitive strings. The strings are defined by the authorization
server. The values of the scope parameter is out of scope for this
document.
The error parameter could be used by the registrar/proxy to indicate
to the UAC the reason for the error, with possible values of
"invalid_token" or "invalid_scope".
4. 'sip.token' Media Feature Tag 4. 'sip.token' Media Feature Tag
The sip.token media feature tag, when inserted in the Contact header The sip.token media feature tag, when inserted in the Contact header
field of a SIP REGISTER request, conveys that the SIP UA associated field of a SIP REGISTER request, conveys that the SIP UA associated
with the tag supports a token based authentication mechanism, where with the tag supports a token based authentication mechanism, where
the user authentication and SIP registration authorization is the user authentication and SIP registration authorization is
performed by a third party. The media feature tag has no values. performed by a third party. The media feature tag has no values.
token-mt = "+sip.token" token-mt = "+sip.token"
5. Security Considerations 5. Security Considerations
TODO The UAC MUST always make sure that it is communicating with the right
registrar/proxy using TLS and proper validation of the server
certificate and the identifier in that certificate to protect the
access token in transit.
If the token being used is a bearer token as specified in [RFC6750],
then the security considration of that document apply.
If the token being used is a JWT as specified in [RFC7519], then the
security considration of that document apply.
6. IANA Considerations 6. IANA Considerations
6.1. SIP Media Feaure Tag 6.1. SIP Media Feaure Tag
6.1.1. sip.token 6.1.1. sip.token
This section defines a new media feature tag that extends the "SIP This section defines a new media feature tag that extends the "SIP
Media Feature Tag Registration Tree" subregistry [RFC3840] under the Media Feature Tag Registration Tree" subregistry [RFC3840] under the
"Media Feature Tags" registry (https://www.iana.org/assignments/ "Media Feature Tags" registry (https://www.iana.org/assignments/
 End of changes. 19 change blocks. 
24 lines changed or deleted 69 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/