draft-ietf-sipcore-sip-token-authnz-02.txt   draft-ietf-sipcore-sip-token-authnz-03.txt 
SIP Core R. Shekh-Yusef, Ed. 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: January 8, 2020 V. Pascual Expires: April 14, 2020 V. Pascual
webrtchacks webrtchacks
July 7, 2019 October 12, 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-02 draft-ietf-sipcore-sip-token-authnz-03
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 January 8, 2020. This Internet-Draft will expire on April 14, 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 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . . . . . . . . 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. SIP Procedures . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Configured AS . . . . . . . . . . . . . . . . . . . . 4 2.1.1. Obtaining Tokens . . . . . . . . . . . . . . . . . . 4
2.1.2. Discovered AS . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Protecting the Access Token . . . . . . . . . . . . . 4
2.2. Initial Registration . . . . . . . . . . . . . . . . . . 7 2.1.3. REGISTER Request . . . . . . . . . . . . . . . . . . 5
2.3. Subsequent Registrations . . . . . . . . . . . . . . . . 8 2.1.4. Non-REGISTER Request . . . . . . . . . . . . . . . . 5
2.4. Non-Registration Requests . . . . . . . . . . . . . . . . 8 2.2. UAS and Registrar Behavior . . . . . . . . . . . . . . . 6
3. WWW-Authenticate Response Header Field . . . . . . . . . . . 8 2.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 6
4. 'sip.token' Media Feature Tag . . . . . . . . . . . . . . . . 9 3. WWW-Authenticate Response Header Field . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. 'sip.token' Media Feature Tag . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Example Flows . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. SIP Media Feaure Tag . . . . . . . . . . . . . . . . . . 10 5.1. Registration . . . . . . . . . . . . . . . . . . . . . . 8
6.1.1. sip.token . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Registration with Pre-Configured AS . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. SIP Media Feaure Tag . . . . . . . . . . . . . . . . . . 12
7.1.1. sip.token . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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 4, line 5 skipping to change at page 4, line 5
apply to the SIP User Agents. apply to the SIP User Agents.
o Confidential User Agent: is a SIP UA that is capable of o Confidential User Agent: is a SIP UA that is capable of
maintaining the confidentiality of the user credentials and any maintaining the confidentiality of the user credentials and any
tokens obtained using these user credentials. tokens obtained using these user credentials.
o Public User Agent: is a SIP UA that is incapable of maintainings o Public User Agent: is a SIP UA that is incapable of maintainings
the confidentiality of the user credentials and any obtained the confidentiality of the user credentials and any obtained
tokens. tokens.
2. Authentication and Authorization flow 2. SIP Procedures
This flow is used by a Confidential UA with rich UI to authenticate
to an authorization server and to directly obtain tokens to be able
to register and get service from the SIP network.
2.1. Overview
The following sections provide overview of the supported flows.
2.1.1. Configured AS
The following figure provides a high level view of flow of messages
when the UA is aware of the AS ahead of time:
UA Registrar AS
---------------------------------------------------------------------
| | |
[00] The UA prompts the user to provides his credentials |
| | |
| [01] HTTP POST /token | |
|-------------------------------------------------------------->|
| | |
| [02] 200 OK {access_token, refresh_token, [id_token]} |
|<--------------------------------------------------------------|
| | |
| | |
| [03] REGISTER | |
| Authorization: Bearer <access_token> |
|------------------------------>| |
| | |
| | [04] HTTP POST /introspect |
| | {access_token} |
| |------------------------------>|
| | |
| | [05] 200 OK {metadata} |
| |<------------------------------|
| | |
| [06] 200 OK | |
|<------------------------------| |
| | |
In step [00], the UA collects the user's credentials with the AS.
In steps [01] and [02], the UA first contacts the Authorization
Server to authenticate the user and 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 Authorization Server, 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 [03], the UA starts the registration process with the SIP
registrar by sending a REGISTER request with the access token it
obtained previously.
The registrar validates the access token, and if the access token
provided by the UA is an opaque token, then the registrar MAY perform
an introspection, steps [04] and [05], to obtain more information
about the token and its scope, as per [RFC7662]. Otherwise, after
the registrar validates the token to make sure it was signed by a
trusted entity, it inspects its claims and act upon it.
When the registrar is satisfied with the token, it then replies with Section 22 of [RFC3261] defines the SIP procedures for the Digest
the 200 OK to complete the registration process. authentication mechanism procedures. The same procedures apply to
the Bearer authentication mechanism, with the changes described in
this section.
2.1.2. Discovered AS 2.1. UAC Behavior
The following figure provides a high level view of flow of messages 2.1.1. Obtaining Tokens
when the UA discovers the AS to conatc from the registrar:
UA Registrar AS When a UAC sends a request without credentials (or with credentials
--------------------------------------------------------------------- that are no longer valid), and receives a 401 (Unauthorized) or a 407
| | | (Proxy Authentication Required) response that contains a WWW-
| [07] REGISTER | | Authenticate header field (in case of a 401 response) or a Proxy-
|------------------------------>| | Authenticate header field (in case of a 407 response) that indicates
| | | "Bearer" scheme authentication and contains an address to an
| [08] 401 Unauthorized | | Authorization Server, the UAC contacts the Authorization Server in
| WWW-Authenticate: Bearer "authz_server"="<authz_server>" | 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
| | | token and refresh token. With an OpenID Connect server, an
[09] The UA prompts the user to provides his credentials | additional ID-Token is returned, which contains the SIP URI and other
| | | user specific details. The method used to authenticate the user and
| [10] HTTP POST /token | | obtain these tokens is out of scope for this document, with one
|-------------------------------------------------------------->| potential method is the Native App mechanism defined in [RFC8252].
| | |
| [11] 200 OK {access_token, refresh_token, [id_token]} |
|<--------------------------------------------------------------|
| | |
| [12] REGISTER | |
| Authorization: Bearer <access_token> |
|------------------------------>| |
| | [13] HTTP POST /introspect |
| | {access_token} |
| |------------------------------>|
| | |
| | [14] 200 OK {metadata} |
| |<------------------------------|
| | |
| [15] 200 OK | |
|<------------------------------| |
| | |
In step [07] the UA starts the registration process by sending a SIP NOTE: The address of the Authorization Server might be known to the
REGISTER request to the registrar without any credentials. The UAC e.g., using means of configuration, in which case the UAC can
REGISTER request includes an indication that the UA supports token- contact the Authorization Server in order to obtain the access token
based autentication in the form of sip.token media feature tag. The before it sends SIP request without credentials.
registrar then challenges the UA, in step [08], by responding with
401 Unauthorized and includes the authorization server to contact to
obtain a token.
In step [09], the UA collects the user's credentials with the AS. 2.1.2. Protecting the Access Token
In steps [10] and [11], the UA contacts the Authorization Server to [RFC6749] mandates that Access Tokens are protected with TLS when in
authenticate the user and obtain tokens to be used to get access to transit. However, TLS only guarantees hop-to-hop protection when
the SIP network. used to protect SIP signaling. Therefore the Access Token MUST be
protected in a way so that only authorized SIP servers will have
access to it. Endpoints that support this specifications MUST
support encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and
protecting Access Token when included in SIP requests, unless some
other mechanism is used to guarantee that only authorized SIP
endpoints have access to the Access Token.
The tokens returned to the UA depend on the type of server: with an 2.1.3. REGISTER Request
OAuth Authorization Server, 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 [12], the UA retries the registration process with the SIP The procedures in this section assumes that the UAC has obtained a
registrar by sending a REGISTER request with the access token it token as specified in section Section 2.1.1
obtained previously.
The registrar validates the access token, and if the access token When a UAC sends a REGISTER request in order to create a binding, it
provided by the UA is an opaque token, then then registrar MAY MUST include an Authorization headerf field with a Bearer scheme,
perform an introspection, steps [13] and [14], to obtain more carrying the access token, in the request, as specified in [RFC6750].
information about the token and its scope, as per [RFC7662]. Based on local policy, the UAC MAY include an access token that has
Otherwise, after the registrar validates the token to make sure it been used for another binding associated with the same AOR in the
was signed by a trusted entity, it inspects its claims and act upon request.
it.
2.2. Initial Registration When the UAC sends a binding refresh REGISTER request, it SHOULD
include an Authorization header field with either the access token
previously used for the binding, or a new access token (obtained
using the refresh token) if the previous one has expired.
If the UA has already obtained a token, then the UA starts the If the access token included in a REGISTER request is not accepted,
registration process, step [03], by sending a REGISTER request, with and the UAC receives a 401 response or a 407 response, the UAC
the access token in the Authorization header, to the registrar. follows the procedures in Section 2.1.1.
If the UA does not have a token, then the UA starts the registration 2.1.4. Non-REGISTER Request
process, step [07], by sending a REGISTER request without an
Authorization header. The registrar MUST then challenge the UA by
responding with 401 Unauthorized and include the WWW-Authenticate
Response Header Field which includes the server to contact to obtain
a token, as specified in Section 3
The REGISTER request SHOULD include a sip.token media feature tag in The procedures in this section assumes that the UAC has obtained a
the Contact header field of the request, unless it knows (e.g., by token as specified in section Section 2.1.1
means of configuration) that the registrar supports the token
authentication mechanism.
The UA MUST include an Authorization header field with the Bearer When a UAC sends a request in order to initiate a SIP dialog, or
scheme in the request to carry the access token, as specified in sends a stand-alone request, the UAC MUST include an Authorization
[RFC6750]. header field with a Bearer scheme, carrying the access token, in the
request, as specified in [RFC6750]. Based on local policy, the UAC
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
the same.
When the registrar is satisfied with the token, it then replies with When the UAC sends a mid-dialog request, the UAC SHOULD include an
the 200 OK to complete the registration process. Authorization header field with either the access token previously
used within the dialog, or with a new access token if the previous
one has expired or the UAC refreshed the access token before its
expiry time.
2.3. Subsequent Registrations If the access token included in a request is not accepted, and the
UAC receives a 401 response or a 407 response, the UAC follows the
procedures in Section 2.1.1.
All subsequent REGISTER requests from the UA MUST include a valid 2.2. UAS and Registrar Behavior
access token. The UA MUST obtain a new access token before 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
of scope for this document.
The REGISTER request SHOULD include a sip.token media feature tag in When a UAS or a Registrar receives a SIP request that does not
the Contact header field of the request, unless it knows (e.g., by contain an Authorization header field with a valid access token, and
means of configuration) that the registrar supports the token the UAS/Proxy decides to challenge the originator of the request, the
authentication mechanism. proxy MUST challenge the request and send a 401 (Unauthorized)
response. The UAS/Proxy MUST include a Proxy-Authentication header
field in the response, indicate "Bearer" scheme and include an
address to an Authorization Server from there the originator can
obtain an access token.
2.4. Non-Registration Requests When a UAS/Registrar receives a SIP request that contains an
Authorization header field with an access token, the UAS/Registrar
MUST validate the access token, using the procedures associated with
the type of access token used. If the validation is successful the
UAS/Registrar can continue to process the request using normal SIP
procedures. If the validation fails, the UAS/Registrar MUST reject
the request.
The UA MUST NOT insert a token in a non-REGISTER request, unless the 2.3. Proxy Behavior
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- When a proxy receives a SIP request that does not contain a Proxy-
Authenticate header field to provide credentials for the same realm Authorization header field with a valid access token, and the proxy
specified in the challenge to the registration request, then the UA decides to challenge the originator of the request, the proxy MUST
MUST include a valid access token in the request retry. The UA MUST challenge the request and send a 407 (Proxy Authentication Required)
include an Authorization header field with the Bearer scheme in the response. The proxy MUST include a Proxy-Authentication header field
request to carry the access token, as specified in [RFC6750]. in the response, indicate "Bearer" scheme and include an address to
an Authorization Server from there the originator can obtain an
access token.
Challenges with WWW-Authenticate with different realm specified in When a proxy receives a SIP request that contains an Proxy-
the challenge to the registration request are out of scope for this Authorization header field with an access token, and the proxy has
document. Challenges with Proxy-Authenticate are out of scope for previously challenged the originator of the request, the proxy MUST
this document. validate the access token, using the procedures associated with the
type of access token used. If the validation is successful the proxy
can continue to process the request using normal SIP procedure. If
the validation fails, the UAS/Registrar MUST reject the request.
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 / scope / authz-server / error / bearer-cln = realm / scope / authz-server / error /
auth-param auth-param
skipping to change at page 9, line 35 skipping to change at page 8, line 5
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. Example Flows
The UAC MUST always make sure that it is communicating with the right 5.1. Registration
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], The figure belows show an example of a SIP registration, where the UA
then the security considration of that document apply. is informed about the Authorization Server (AS) from where to obtain
an access token by the registratar in a 401 response to the REGISTER
request.
If the token being used is a JWT as specified in [RFC7519], then the UA Registrar AS
security considration of that document apply. ---------------------------------------------------------------------
| | |
| [1] REGISTER | |
|------------------------------>| |
| | |
| [2] 401 Unauthorized | |
| WWW-Authenticate: Bearer "authz_server"="<authz_server>" |
|<------------------------------| |
| | |
| [3] The UA colects the user AS credentials |
| | |
| [4] HTTP POST /token | |
|- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ->|
| | |
| [5] 200 OK {access_token, refresh_token, [id_token]} |
|<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|
| | |
| [6] REGISTER | |
| Authorization: Bearer <access_token> |
|------------------------------>| |
| | [7] HTTP POST /introspect |
| | {access_token} |
| |------------------------------>|
| | |
| | [8] 200 OK {metadata} |
| |<------------------------------|
| | |
| [9] 200 OK | |
|<------------------------------| |
| | |
6. IANA Considerations In step [1], the UA starts the registration process by sending a SIP
REGISTER request to the registrar without any credentials. The
REGISTER request includes an indication that the UA supports token-
based autentication, using a sip.token media feature tag.
6.1. SIP Media Feaure Tag In step [2], the registrar challenges the UA, by sending a SIP 401
(Unauthorized) response to the REGISTER request. In the response the
registrar includes information about the AS to contact in order to
obtain a token.
6.1.1. sip.token In step [3], the UA collects the user credentials associated with the
AS.
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
SIP REGISTER request that includes the access token that the UA
obtrained in steps [10] and [11].
The registrar validates the access token. If the access token is a
reference token, the registrar MAY perform an introspection, as in
steps [7] and [8], in order to obtain more information about 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
entity, it inspects its claims and act upon it.
In step [9], once the registrar has succesfully verified and accepted
the access token, it sends a 200 (OK) response to the REGISTER
request.
5.2. Registration with Pre-Configured AS
The figure belows show an example of a SIP registration, where the UA
is has pre-configured information about the Authorization Server (AS)
from where to obtain the access token.
UA Registrar AS
---------------------------------------------------------------------
| | |
| [1] The UA collects the user AS credentials |
| | |
| [2] HTTP POST /token | |
|- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ->|
| | |
| [3] 200 OK {access_token, refresh_token, [id_token]} |
|<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|
| | |
| | |
| [4] REGISTER | |
| Authorization: Bearer <access_token> |
|------------------------------>| |
| | [5] HTTP POST /introspect |
| | {access_token} |
| |------------------------------>|
| | |
| | [6] 200 OK {metadata} |
| |<------------------------------|
| | |
| [7] 200 OK | |
|<------------------------------| |
| | |
In step [1], the UA collects the user credentials associated with the
AS.
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
SIP REGISTER request that includes the access token that the UA
obtrained in steps [10] and [11].
The registrar validates the access token. If the access token is a
reference token, the registrar MAY perform an introspection, as in
steps [5] and [6], in order to obtain more information about 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
entity, it inspects its claims and act upon it.
In step [7], once the registrar has succesfully verified and accepted
the access token, it sends a 200 (OK) response to the REGISTER
request.
6. Security Considerations
The security considerations for OAuth are defined in [RFC6749]. The
security considerations for bearer tokens are defined in [RFC6750].
The security considerations for JSON Web Tokens (JWT) are defined in
[RFC7519]. These security considerations also apply to SIP usage of
access token as defined in this document.
[RFC6749] mandates that Access Tokens are protected with TLS.
However, TLS only guarantees hop-to-hop protection when used to
protect SIP signaling. Therefore the Access Token MUST be protected
in a way so that only authorized SIP endpoints will have access to
it. Endpoints that support this specifications MUST support
encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and protecting
Access Token when included in SIP requests, unless some other
mechanism is used to guarantee that only authorized SIP endpoints
have access to the Access Token.
7. IANA Considerations
7.1. SIP Media Feaure Tag
7.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/
media-feature-tags). media-feature-tags).
Media feature tag name: sip.token Media feature tag name: sip.token
Summary of the media feature indicated by this feature tag: This Summary of the media feature indicated by this feature tag: This
media feature tag, when inserted in the Contact header field media feature tag, when inserted in the Contact header field
skipping to change at page 10, line 40 skipping to change at page 12, line 40
new security considerations, as it simply indicates support for new security considerations, as it simply indicates support for
a basic SIP feature. However, if an attacker manages to remove a basic SIP feature. However, if an attacker manages to remove
the media feature tag from a SIP REGISTER request, the SIP UA the media feature tag from a SIP REGISTER request, the SIP UA
that inserted it might not be able to authenticate itself with that inserted it might not be able to authenticate itself with
the SIP registrar to which the SIP request is addressed, as the the SIP registrar to which the SIP request is addressed, as the
SIP registrar might not be aware that the SIP UA supports the SIP registrar might not be aware that the SIP UA supports the
feature associated with the media feature tag. feature associated with the media feature tag.
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
7. Acknowledgments 8. Acknowledgments
The authors would also like to thank Paul Kyzivat for his reviews and The authors would also like to thank the following for their review
feedback on this document. and feedback on this document:
Paul Kyzivat, Olle Johansson, Roman Shpount, and Dale Worley.
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, and Dale Worley. Robert Sparks, Asveren Tolga, and Dale Worley.
8. Normative References 9. 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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
skipping to change at page 12, line 14 skipping to change at page 14, line 14
[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and (JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
2015, <https://www.rfc-editor.org/info/rfc7523>. 2015, <https://www.rfc-editor.org/info/rfc7523>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015, RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>. <https://www.rfc-editor.org/info/rfc7662>.
[RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",
BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017,
<https://www.rfc-editor.org/info/rfc8252>.
Authors' Addresses Authors' Addresses
Rifaat Shekh-Yusef (editor) Rifaat Shekh-Yusef
Avaya Avaya
425 Legget Drive 425 Legget Drive
Ottawa, Ontario Ottawa, Ontario
Canada Canada
Phone: +1-613-595-9106 Phone: +1-613-595-9106
EMail: rifaat.ietf@gmail.com EMail: rifaat.ietf@gmail.com
Christer Holmberg Christer Holmberg
Ericsson Ericsson
 End of changes. 42 change blocks. 
209 lines changed or deleted 295 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/