draft-ietf-sipcore-sip-authn-00.txt		draft-ietf-sipcore-sip-authn-01.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: November 20, 2017 V. Pascual		Expires: March 30, 2018 V. Pascual
	Oracle		webrtchacks
	May 19, 2017		September 26, 2017
	Third-Party Authentication for Session Initiation Protocol (SIP)		Third-Party Authentication for Session Initiation Protocol (SIP)
	draft-ietf-sipcore-sip-authn-00		draft-ietf-sipcore-sip-authn-01
	Abstract		Abstract
	This document defines an authentication mechanism for SIP, that is		This document defines an authentication mechanism for SIP, that is
	based on the OAuth 2.0 and OpenID Connect Core 1.0 specifications, to		based on the OAuth 2.0 and OpenID Connect Core 1.0 specifications, to
	enable the delegation of the user authentication to a dedicated		enable the delegation of the user authentication to a dedicated
	third-party IdP entity that is separate from the SIP network elements		third-party IdP entity that is separate from the SIP network elements
	that provide the SIP service.		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 http://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 November 20, 2017.		This Internet-Draft will expire on March 30, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	(http://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
	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 6, line 24 ¶		skipping to change at page 6, line 24 ¶
	The following figure provides a high level view of flow of messages		The following figure provides a high level view of flow of messages
	for the user authentication using a Public UA that has a rich UI that		for the user authentication using a Public UA that has a rich UI that
	would prompt the user for his credentials:		would prompt the user for his credentials:
	User Proxy Authorization		User Proxy Authorization
	Agent Server		Agent Server
	---------------------------------------------------------------------		---------------------------------------------------------------------
	| | |		| | |
	| F1 REGISTER | |		| F1 REGISTER | |
	|------------------------------>| |		|------------------------------>| |
	| F2 302 | |		| F2 401 Unauthorized | |
	|<------------------------------| |		|<------------------------------| |
	| | |		| | |
	| | |		| | |
	The UA prompts the user to provide his/her credentials. |		The UA prompts the user to provide his/her credentials. |
	The UA then, as per OAuth 2.0 protocol, authenticates the user to |		The UA then, as per OAuth 2.0 protocol, authenticates the user to |
	the AuthZ server, and obtains an authorization code, which the UA |		the AuthZ server, and obtains an authorization code, which the UA |
	will later hand to the Proxy. |		will later hand to the Proxy. |
	|<------------------------------------------------------------->|		|<------------------------------------------------------------->|
	| | |		| | |
	| | |		| | |
	skipping to change at page 7, line 6 ¶		skipping to change at page 7, line 6 ¶
	| |<----------------------------->|		| |<----------------------------->|
	| | |		| | |
	| F4 200 OK | |		| F4 200 OK | |
	|<------------------------------| |		|<------------------------------| |
	| | |		| | |
	Both the proxy and the UA will then create a shared-key based on |		Both the proxy and the UA will then create a shared-key based on |
	the from-tag, to-tag, and call-id are taken from the 200 OK |		the from-tag, to-tag, and call-id are taken from the 200 OK |
	| | |		| | |
	The UA initially sends a REGISTER request (F1) without providing any		The UA initially sends a REGISTER request (F1) without providing any
	credentials. The proxy redirects the UA by responding with 302 (F2).		credentials. The proxy redirects the UA by responding with 401
			Unauthorized (F2).
	The UA will then contact the Authorization Server and obtain an		The UA will then contact the Authorization Server and obtain an
	authorization code to be used with the SIP proxy.		authorization code to be used with the SIP proxy.
	The UA then retries the request (F3) and includes the authorization		The UA then retries the request (F3) and includes the authorization
	code in the body of the request.		code in the body of the request.
	The proxy then contacts the Authorization Server and exchanges the		The proxy then contacts the Authorization Server and exchanges the
	authorization code for tokens. If the proxy is successful in		authorization code for tokens. If the proxy is successful in
	exchanging the authorization code with the tokens, the proxy then		exchanging the authorization code with the tokens, the proxy then
	replies with 200 OK to completed the registration process, and		replies with 200 OK to complete the registration process, and locally
	locally generates the shared-key with the UA for this user.		generates the shared-key with the UA for this user.
	When the UA receives the 200 OK, it will follow the same procedure		When the UA receives the 200 OK, it will follow the same procedure
	used by the proxy and calculate its shared-key locally.		used by the proxy and calculate its shared-key locally.
	2.1.1. Registration		2.1.1. Registration
	The UA initiates the process by sending a REGISTER request (F1) to		The UA initiates the process by sending a REGISTER request (F1) to
	the proxy. The proxy will redirect the UA to the Authorization		the proxy. The proxy will redirect the UA to the Authorization
	Server by responding with 302 (F2) that includes the address of the		Server by responding with 401 Unauthorized (F2) that includes the
	Authorization Server in the form of an HTTP URI.		address of the Authorization Server in the form of an HTTP URI in a
			Location header field, as defined in RFC7231, section 7.1.2.
			[[OPEN ISSUE]] The above text suggests defining a new Location header
			to carry the authorization server URL. Is that reasonable? other
			ideas?
	The UA will then contact the Authorization Server and obtain an		The UA will then contact the Authorization Server and obtain an
	authorization code to be used with the SIP proxy. The method used by		authorization code to be used with the SIP proxy. The method used by
	the UA to obtain the code is out of scope for this document.		the UA to obtain the code is out of scope for this document.
	Then, the UA will send a new REGISTER request (F3) and include the		The UA will then send a new REGISTER request (F3) and include the
	authorization code in the body of the request with the following		authorization code in the body of the request with the following
	parameters:		parameters:
	grant_type (REQUIRED)		grant_type (REQUIRED)
	Value MUST be set to "authorization_code".		Value MUST be set to "authorization_code".
	code (REQUIRED)		code (REQUIRED)
	The authorization code received from the authorization server.		The authorization code received from the authorization server.
	The proxy then contacts the Authorization Server and exchanges the		The proxy then contacts the Authorization Server and exchanges the
	authorization code for ID token, access token, and refresh token.		authorization code for access token, refresh token, and maybe ID
	The method used by the UA to obtain the tokens is out of scope for		token. The method used by the UA to obtain the tokens is out of
	this document.		scope for this document.
	If the proxy is successful in exchanging the authorization code with		If the proxy is successful in exchanging the authorization code with
	the tokens, the proxy then responds with 200 OK (F4) to the UA to		the tokens, the proxy then responds with 200 OK (F4) to the UA to
	complete the registration process.		complete the registration process.
	2.1.2. Shared-Key		2.1.2. Shared-Key
	After sending the 200 OK to the UA to complete the registration		After sending the 200 OK to the UA to complete the registration
	process, the proxy and the UA use the HMAC-SHA256(key, message) to		process, the proxy and the UA use the HMAC-SHA256(key, message) to
	calculates the shared-key associated with this user as follows:		calculates the shared-key associated with this user as follows:
	skipping to change at page 8, line 30 ¶		skipping to change at page 8, line 30 ¶
	key		key
	The authorization code obtained from the Authorization Server.		The authorization code obtained from the Authorization Server.
	message		message
	The concatenation of the 'from-tag', 'to-tag', and 'call-id' of		The concatenation of the 'from-tag', 'to-tag', and 'call-id' of
	the 200 OK that completes the registration process.		the 200 OK that completes the registration process.
	This shared-key will be used to allow the UA to re-register to the		This shared-key will be used to allow the UA to re-register to the
	proxy, in case of a connection lost to the proxy, without the need to		proxy, in case of a connection loss to the proxy, without the need to
	obtain a new code or prompt the user for his credentials.		obtain a new code or prompt the user for his credentials.
	2.1.3. Re-Registration Requests		2.1.3. Re-Registration Requests
	When the UA loses its connection to the proxy and it wants to send a		When the UA loses its connection to the proxy and it wants to send a
	new registration request to the proxy, the UA will send a new		new registration request to the proxy, the UA will send a new
	REGISTER request and include the proof-of-possession (pop) of the		REGISTER request and include the proof-of-possession (pop) of the
	shared-key in the body of the request:		shared-key in the body of the request:
	grant_type (REQUIRED)		grant_type (REQUIRED)
	skipping to change at page 9, line 12 ¶		skipping to change at page 9, line 12 ¶
	The pop calculated the first time the UA registered with the		The pop calculated the first time the UA registered with the
	proxy.		proxy.
	The pop is calculated using the shared-key as follows:		The pop is calculated using the shared-key as follows:
	pop = HMAC-SHA256(shared-key, digest-string)		pop = HMAC-SHA256(shared-key, digest-string)
	See rfc4474, section 9, for the SIP headers to hash to create digest-		See rfc4474, section 9, for the SIP headers to hash to create digest-
	string.		string.
	[[OPEN ISSUE]] Should this be not limited to re-registration, and		[[OPEN ISSUE]] Is there any issue with using digest-string as defined
	instead be used with all subsequent requests?		in RFC4474?
			[[OPEN ISSUE]] Should pop not be limited to re-registration, and
			instead be used with all subsequent requests? If the answer is yes,
			a new header should be defined to carry the pop instead of carrying
			it in the payload.
	2.1.4. Token Refresh		2.1.4. Token Refresh
	Before the tokens expire, the proxy makes a refresh request to the		Before the tokens expire, the proxy makes a refresh request to the
	Authorization Server to try to obtain new tokens. The method used by		Authorization Server to try to obtain new tokens. The method used by
	the UA to refresh the tokens is out of scope for this document.		the UA to refresh the tokens is out of scope for this document.
	If the proxy fails to refresh the tokens, then it MUST challenge the		If the proxy fails to refresh the tokens, then it MUST challenge the
	next request from the UA, and as a result the UA MUST go through the		next request from the UA, and as a result the UA MUST go through the
	authorization process again.		authorization process again.
	skipping to change at page 11, line 6 ¶		skipping to change at page 11, line 6 ¶
	grant_type (REQUIRED)		grant_type (REQUIRED)
	Value MUST be set to "authorization_code".		Value MUST be set to "authorization_code".
	code (REQUIRED)		code (REQUIRED)
	The code received from the authorization server through the		The code received from the authorization server through the
	browser.		browser.
	The proxy then contacts the Authorization Server and exchanges the		The proxy then contacts the Authorization Server and exchanges the
	authorization code for ID token, access token, and refresh token.		authorization code for access token, refresh token, and maybe an ID
	The method used by the UA to obtain the tokens is out of scope for		token. The method used by the UA to obtain the tokens is out of
	this document.		scope for this document.
	If the proxy is successful in exchanging the authorization code with		If the proxy is successful in exchanging the authorization code with
	the tokens, the proxy then responds with 200 OK (F2) to the UA to		the tokens, the proxy then responds with 200 OK (F2) to the UA to
	complete the registration process.		complete the registration process.
	2.2.2. Shared-Key		2.2.2. Shared-Key
	After sending the 200 OK to the UA to complete the registration		After sending the 200 OK to the UA to complete the registration
	process, the proxy and the UA use the HMAC-SHA256(key, message) to		process, the proxy and the UA use the HMAC-SHA256(key, message) to
	calculates the shared-key associated with this user as follows:		calculates the shared-key associated with this user as follows:
	skipping to change at page 11, line 30 ¶		skipping to change at page 11, line 30 ¶
	key		key
	The authorization code obtained from the Authorization Server.		The authorization code obtained from the Authorization Server.
	message		message
	The concatenation of the 'from-tag', 'to-tag', and 'call-id' of		The concatenation of the 'from-tag', 'to-tag', and 'call-id' of
	the 200 OK that completes the registration process.		the 200 OK that completes the registration process.
	This shared-key will be used to allow the UA to re-register to the		This shared-key will be used to allow the UA to re-register to the
	proxy, in case of a connection lost to the proxy, without the need to		proxy, in case of a connection loss to the proxy, without the need to
	obtain a new authorization code.		obtain a new authorization code.
	2.2.3. Token Refresh		2.2.3. Token Refresh
	Before the tokens expire, the proxy makes a refresh request to the		Before the tokens expire, the proxy makes a refresh request to the
	Authorization Server to try to obtain new tokens. The method used by		Authorization Server to try to obtain new tokens. The method used by
	the UA to refresh the tokens is out of scope for this document.		the UA to refresh the tokens is out of scope for this document.
	If the proxy fails to refresh the tokens, then it MUST challenge the		If the proxy fails to refresh the tokens, then it MUST challenge the
	next request from the UA, and as a result the UA MUST go through the		next request from the UA, and as a result the UA MUST go through the
	skipping to change at page 13, line 27 ¶		skipping to change at page 13, line 27 ¶
	User Proxy Authorization		User Proxy Authorization
	Agent Server		Agent Server
	---------------------------------------------------------------------		---------------------------------------------------------------------
	| | |		| | |
	The UA contacts the authorization server and authenticates the |		The UA contacts the authorization server and authenticates the |
	user, and as a result obtains an access and refresh tokens. |		user, and as a result obtains an access and refresh tokens. |
	| | |		| | |
	|<------------------------------------------------------------->|		|<------------------------------------------------------------->|
	| | |		| | |
	| | |		| | |
	| F1 REGISTER Authorization: Bearer access_token=<access-token> |		| F1 REGISTER Authorization: Bearer access_token=<access_token> |
	|------------------------------>| |		|------------------------------>| |
	| | |		| | |
	| | The proxy validates the token |		| | The proxy validates the token |
	| | Optional introspection step |		| | Optional introspection step |
	| |<----------------------------->|		| |<----------------------------->|
	| | |		| | |
	| F2 200 OK | |		| F2 200 OK | |
	|<------------------------------| |		|<------------------------------| |
	| | |		| | |
	skipping to change at page 14, line 31 ¶		skipping to change at page 14, line 31 ¶
	token. The UA MUST obtain a new access token before the access token		token. The UA MUST obtain a new access token before the access token
	expiry period to continue to get service from the system.		expiry period to continue to get service from the system.
	4. Authorization Header Syntax		4. Authorization Header Syntax
	This section describes the syntax of the authorization header with		This section describes the syntax of the authorization header with
	the Bearer scheme.		the Bearer scheme.
	Authorization = "Authorization" HCOLON "Bearer" LWS		Authorization = "Authorization" HCOLON "Bearer" LWS
	"access_token" EQUAL access_token		"access_token" EQUAL access_token
	access-token = quoted-string		access_token = quoted-string
	5. Security Considerations		5. Security Considerations
	<Security considerations text>		<Security considerations text>
	6. IANA Considerations		6. IANA Considerations
	<IANA considerations text>		<IANA considerations text>
	7. Acknowledgments		7. Acknowledgments
	skipping to change at page 15, line 47 ¶		skipping to change at page 15, line 47 ¶
	October 2015.		October 2015.
	Authors' Addresses		Authors' Addresses
	Rifaat Shekh-Yusef (editor)		Rifaat Shekh-Yusef (editor)
	Avaya		Avaya
	250 Sidney Street		250 Sidney Street
	Belleville, Ontario		Belleville, Ontario
	Canada		Canada
	Phone: +1-613-967-5267		Phone: +1-613-967-5176
	EMail: rifaat.ietf@gmail.com		EMail: rifaat.ietf@gmail.com
	Christer Holmberg		Christer Holmberg
	Ericsson		Ericsson
	Hirsalantie 11		Hirsalantie 11
	Jorvas 02420		Jorvas 02420
	Finland		Finland
	EMail: christer.holmberg@ericsson.com		EMail: christer.holmberg@ericsson.com
	Victor Pascual		Victor Pascual
	Oracle		webrtchacks
	Spain		Spain
	EMail: victor.pascual.avila@oracle.com		EMail: victor.pascual.avila@gmail.com
End of changes. 20 change blocks.
	28 lines changed or deleted		39 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/