draft-ietf-sipcore-sip-token-authnz-04.txt   draft-ietf-sipcore-sip-token-authnz-05.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 21, 2020 V. Pascual Expires: April 25, 2020 V. Pascual
webrtchacks webrtchacks
October 19, 2019 October 23, 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-04 draft-ietf-sipcore-sip-token-authnz-05
Abstract Abstract
This document defines a mechanism for SIP, that is based on the OAuth This document updates RFC 3261 and defines a mechanism for SIP, that
2.0 and OpenID Connect Core 1.0 specifications, to enable the is based on the OAuth 2.0 and OpenID Connect Core 1.0 specifications,
delegation of the user authentication and SIP registration to enable the delegation of the user authentication and SIP
authorization to a dedicated third-party entity that is separate from registration authorization to a dedicated third-party entity that is
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 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 21, 2020. This Internet-Draft will expire on April 25, 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 3, line 22 skipping to change at page 3, line 22
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.
This document updates [RFC3261], by defining the UAC procedures if it
receives a 401/407 response with multiple WWW-Authenticate/Proxy-
Authenticate header fields, providing challenges using different
authentication schemes for the same realm.
This document defines an mechanism for SIP, that is based on the This document defines an mechanism for SIP, that is based on the
OAuth 2.0 and OpenID Connect Core 1.0 specifications, to enable the OAuth 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.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 4, line 23 skipping to change at page 4, line 23
2.1.1. Obtaining Tokens 2.1.1. Obtaining Tokens
When a UAC sends a request without credentials (or with credentials When a UAC sends a request without credentials (or with credentials
that are no longer valid), and receives a 401 (Unauthorized) or a 407 that are no longer valid), and receives a 401 (Unauthorized) or a 407
(Proxy Authentication Required) response that contains a WWW- (Proxy Authentication Required) response that contains a WWW-
Authenticate header field (in case of a 401 response) or a Proxy- Authenticate header field (in case of a 401 response) or a Proxy-
Authenticate header field (in case of a 407 response) that indicates Authenticate header field (in case of a 407 response) that indicates
"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, and includes the requested scopes based on a
local configuration. 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. The access token will be sent to the SIP
additional ID-Token is returned, which contains the SIP URI and other servers to authorize UAC's access to the service. The refresh token
user specific details. The method used to authenticate the user and will only be used with the AS to get new access token and refresh
obtain these tokens is out of scope for this document, with one token, before the expiry of the current access token. With an OpenID
potential method is the Native App mechanism defined in [RFC8252]. Connect server, an additional ID-Token is returned, which contains
the SIP URI and other user specific details, and will be consumed by
the UAC.
One of the advantages of using the mechanism defined in [RFC8252] is The method used to authenticate the user and obtain these tokens is
that the user will be directed to use a browser to interact with the out of scope for this document, with one potential method is the
authorization server. This allows the authorization server to prompt Native App mechanism defined in [RFC8252]. The advantages of using
the user for multi-factor authentication, redirect the user to third- the mechanism defined in [RFC8252] is that the user will be directed
party identity providers, and the use of single-sign-on sessions. 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- If the UAC receives a 401/407 response with multiple WWW-
Authenticate/Proxy-Authenticate header fields, providing challenges Authenticate/Proxy-Authenticate header fields, providing challenges
using different authentication schemes for the same realm, the UAC using different authentication schemes for the same realm, the UAC
provides credentials for one or more of the schemes that it supports, provides credentials for one or more of the schemes that it supports,
based on local policy. 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
skipping to change at page 7, line 34 skipping to change at page 7, line 34
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
authz-server = "authz_server" EQUAL authz-server-value authz-server = "authz_server" EQUAL authz-server-value
authz-server-value = quoted-string authz-server-value = https-URI
The authz-server parameters contains the HTTPS URL of the The authz-server parameters contains the HTTPS URI, as defined in
authorization server. [RFC7230], 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 13, line 40 skipping to change at page 13, line 40
[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-editor.org/info/rfc6750>. <https://www.rfc-editor.org/info/rfc6750>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <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 [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
 End of changes. 12 change blocks. 
23 lines changed or deleted 39 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/