draft-ietf-sipcore-sip-token-authnz-05.txt   draft-ietf-sipcore-sip-token-authnz-06.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 25, 2020 V. Pascual Expires: May 23, 2020 V. Pascual
webrtchacks webrtchacks
October 23, 2019 November 20, 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-05 draft-ietf-sipcore-sip-token-authnz-06
Abstract Abstract
This document updates RFC 3261 and defines a mechanism for SIP, that This document updates RFC 3261 and defines a mechanism for SIP, that
is based on the OAuth 2.0 and OpenID Connect Core 1.0 specifications, is based on the OAuth 2.0 and OpenID Connect Core 1.0 specifications,
to enable the delegation of the user authentication and SIP to enable the delegation of the user authentication and SIP
registration authorization to a dedicated third-party entity that is registration authorization to a dedicated third-party entity that is
separate from the SIP network elements that provide the SIP service. separate from the SIP network elements that provide the SIP service.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 25, 2020. This Internet-Draft will expire on May 23, 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 (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
skipping to change at page 2, line 36 skipping to change at page 2, line 36
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. Access Token Claims . . . . . . . . . . . . . . . . . 5 2.1.2. Access Token Claims . . . . . . . . . . . . . . . . . 5
2.1.3. Protecting the Access Token . . . . . . . . . . . . . 5 2.1.3. Protecting the Access Token . . . . . . . . . . . . . 5
2.1.4. REGISTER Request . . . . . . . . . . . . . . . . . . 5 2.1.4. REGISTER Request . . . . . . . . . . . . . . . . . . 5
2.1.5. Non-REGISTER Request . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . 7 2.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 7
3. WWW-Authenticate Response Header Field . . . . . . . . . . . 7 3. WWW-Authenticate Response Header Field . . . . . . . . . . . 7
4. 'sip.token' Media Feature Tag . . . . . . . . . . . . . . . . 8 4. 'sip.oauth2' Media Feature Tag . . . . . . . . . . . . . . . 8
5. Example Flows . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Example Flows . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Registration . . . . . . . . . . . . . . . . . . . . . . 9 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.oauth2 . . . . . . . . . . . . . . . . . . . . . 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
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 [RFC7230] for authenticating users, which is a simple
response authentication mechanism that allows a server to challenge a challenge- response authentication mechanism that allows a server to
client request and allows a client to provide authentication challenge a client request and allows a client to provide
information in response to that challenge. authentication 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
allow clients to access resources on behalf of their user. allow clients to access resources on behalf of their user.
The OpenID Connect 1.0 [OPENID] specifications defines a simple The OpenID Connect 1.0 [OPENID] specifications 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.
skipping to change at page 8, line 14 skipping to change at page 8, line 14
token to be able to get service. As defined in [RFC6749], the value 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, of the scope parameter is expressed as a list of space-delimited,
case-sensitive strings. The strings are defined by the authorization case-sensitive strings. The strings are defined by the authorization
server. The values of the scope parameter is out of scope for this server. The values of the scope parameter is out of scope for this
document. document.
The error parameter could be used by the registrar/proxy to indicate The error parameter could be used by the registrar/proxy to indicate
to the UAC the reason for the error, with possible values of to the UAC the reason for the error, with possible values of
"invalid_token" or "invalid_scope". "invalid_token" or "invalid_scope".
4. 'sip.token' Media Feature Tag 4. 'sip.oauth2' Media Feature Tag
The sip.token media feature tag, when inserted in the Contact header The sip.oauth2 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.oauth2"
5. Example Flows 5. Example Flows
5.1. Registration 5.1. Registration
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 informed about the Authorization Server (AS) from where to obtain is informed about the Authorization Server (AS) from where to obtain
an access token by the registratar in a 401 response to the REGISTER an access token by the registratar in a 401 response to the REGISTER
request. request.
skipping to change at page 9, line 45 skipping to change at page 9, line 45
| | [6] 200 OK {metadata} | | | [6] 200 OK {metadata} |
| |<------------------------------| | |<------------------------------|
| | | | | |
| [7] 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.oauth2 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 interacts with the AS, potentially using the In step [3], the UA interacts with the AS, potentially using the
OAuth Native App mechanism defined in [RFC8252], authenticates the OAuth Native App mechanism defined in [RFC8252], authenticates the
user and obtains the tokens needed to access the SIP service. user and obtains the tokens needed to access the SIP service.
skipping to change at page 12, line 9 skipping to change at page 12, line 9
it. Endpoints that support this specifications MUST support it. Endpoints that support this specifications MUST support
encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and protecting encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and protecting
Access Token when included in SIP requests, unless some other Access Token when included in SIP requests, unless some other
mechanism is used to guarantee that only authorized SIP endpoints mechanism is used to guarantee that only authorized SIP endpoints
have access to the Access Token. have access to the Access Token.
7. IANA Considerations 7. IANA Considerations
7.1. SIP Media Feaure Tag 7.1. SIP Media Feaure Tag
7.1.1. sip.token 7.1.1. sip.oauth2
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.oauth2
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
of a SIP REGISTER request, conveys that the SIP UA associated of a SIP REGISTER request, conveys that the SIP UA associated
with the tag supports a token based authentication mechanism, with the tag supports a token based authentication mechanism,
where the user authentication and SIP registration authorization where the user authentication and SIP registration
is performed by a third party. authorization is performed by a third party.
Values appropriate for use with this feature tag: none Values appropriate for use with this feature tag: none
Related standards or documents: RFC XXXX Related standards or documents: RFC XXXX
Security considerations: This media feature tag does not introduce Security considerations: This media feature tag does not introduce
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)
8. Acknowledgments 8. Acknowledgments
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 on this document: and feedback on this document:
Paul Kyzivat, Olle Johansson, Roman Shpount, and Dale Worley. 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
skipping to change at page 13, line 16 skipping to change at page 13, line 16
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.
9. 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-
<https://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc3261>. editor.org/info/rfc3261>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, Initiation Protocol (SIP)", RFC 3840,
DOI 10.17487/RFC3840, August 2004, DOI 10.17487/RFC3840, August 2004, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc3840>. editor.org/info/rfc3840>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6750>. editor.org/info/rfc6750>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
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", [RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",
BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017,
<https://www.rfc-editor.org/info/rfc8252>. <https://www.rfc-editor.org/info/rfc8252>.
Authors' Addresses Authors' Addresses
 End of changes. 26 change blocks. 
53 lines changed or deleted 43 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/