--- 1/draft-ietf-sipcore-sip-authn-00.txt 2017-09-26 06:13:19.699284885 -0700 +++ 2/draft-ietf-sipcore-sip-authn-01.txt 2017-09-26 06:13:19.727285548 -0700 @@ -1,55 +1,55 @@ SIP Core R. Shekh-Yusef, Ed. Internet-Draft Avaya Updates: 3261 (if approved) C. Holmberg Intended status: Standards Track Ericsson -Expires: November 20, 2017 V. Pascual - Oracle - May 19, 2017 +Expires: March 30, 2018 V. Pascual + webrtchacks + September 26, 2017 Third-Party Authentication for Session Initiation Protocol (SIP) - draft-ietf-sipcore-sip-authn-00 + draft-ietf-sipcore-sip-authn-01 Abstract This document defines an authentication mechanism for SIP, that is based on the OAuth 2.0 and OpenID Connect Core 1.0 specifications, to enable the delegation of the user authentication to a dedicated third-party IdP entity that is separate from the SIP network elements that provide the SIP service. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this @@ -219,21 +219,21 @@ 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 would prompt the user for his credentials: User Proxy Authorization Agent Server --------------------------------------------------------------------- | | | | F1 REGISTER | | |------------------------------>| | - | F2 302 | | + | F2 401 Unauthorized | | |<------------------------------| | | | | | | | The UA prompts the user to provide his/her credentials. | The UA then, as per OAuth 2.0 protocol, authenticates the user to | the AuthZ server, and obtains an authorization code, which the UA | will later hand to the Proxy. | |<------------------------------------------------------------->| | | | | | | @@ -246,64 +246,70 @@ | |<----------------------------->| | | | | F4 200 OK | | |<------------------------------| | | | | 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 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 authorization code to be used with the SIP proxy. The UA then retries the request (F3) and includes the authorization code in the body of the request. The proxy then contacts the Authorization Server and exchanges the authorization code for tokens. If the proxy is successful in exchanging the authorization code with the tokens, the proxy then - replies with 200 OK to completed the registration process, and - locally generates the shared-key with the UA for this user. + replies with 200 OK to complete the registration process, and locally + generates the shared-key with the UA for this user. When the UA receives the 200 OK, it will follow the same procedure used by the proxy and calculate its shared-key locally. 2.1.1. Registration The UA initiates the process by sending a REGISTER request (F1) to the proxy. The proxy will redirect the UA to the Authorization - Server by responding with 302 (F2) that includes the address of the - Authorization Server in the form of an HTTP URI. + Server by responding with 401 Unauthorized (F2) that includes the + 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 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. - 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 parameters: grant_type (REQUIRED) Value MUST be set to "authorization_code". code (REQUIRED) The authorization code received from the authorization server. The proxy then contacts the Authorization Server and exchanges the - authorization code for ID token, access token, and refresh token. - The method used by the UA to obtain the tokens is out of scope for - this document. + authorization code for access token, refresh token, and maybe ID + token. The method used by the UA to obtain the tokens is out of + scope for this document. 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 complete the registration process. 2.1.2. Shared-Key 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 calculates the shared-key associated with this user as follows: @@ -311,21 +317,21 @@ key The authorization code obtained from the Authorization Server. message The concatenation of the 'from-tag', 'to-tag', and 'call-id' of the 200 OK that completes the registration process. 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. 2.1.3. Re-Registration Requests 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 REGISTER request and include the proof-of-possession (pop) of the shared-key in the body of the request: grant_type (REQUIRED) @@ -337,22 +343,27 @@ The pop calculated the first time the UA registered with the proxy. The pop is calculated using the shared-key as follows: pop = HMAC-SHA256(shared-key, digest-string) See rfc4474, section 9, for the SIP headers to hash to create digest- string. - [[OPEN ISSUE]] Should this be not limited to re-registration, and - instead be used with all subsequent requests? + [[OPEN ISSUE]] Is there any issue with using digest-string as defined + 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 Before the tokens expire, the proxy makes a refresh request to the 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. 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 authorization process again. @@ -395,23 +406,23 @@ grant_type (REQUIRED) Value MUST be set to "authorization_code". code (REQUIRED) The code received from the authorization server through the browser. The proxy then contacts the Authorization Server and exchanges the - authorization code for ID token, access token, and refresh token. - The method used by the UA to obtain the tokens is out of scope for - this document. + authorization code for access token, refresh token, and maybe an ID + token. The method used by the UA to obtain the tokens is out of + scope for this document. 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 complete the registration process. 2.2.2. Shared-Key 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 calculates the shared-key associated with this user as follows: @@ -419,21 +430,21 @@ key The authorization code obtained from the Authorization Server. message The concatenation of the 'from-tag', 'to-tag', and 'call-id' of the 200 OK that completes the registration process. 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. 2.2.3. Token Refresh Before the tokens expire, the proxy makes a refresh request to the 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. 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 @@ -480,21 +491,21 @@ User Proxy Authorization Agent Server --------------------------------------------------------------------- | | | The UA contacts the authorization server and authenticates the | user, and as a result obtains an access and refresh tokens. | | | | |<------------------------------------------------------------->| | | | | | | - | F1 REGISTER Authorization: Bearer access_token= | + | F1 REGISTER Authorization: Bearer access_token= | |------------------------------>| | | | | | | The proxy validates the token | | | Optional introspection step | | |<----------------------------->| | | | | F2 200 OK | | |<------------------------------| | | | | @@ -524,21 +535,21 @@ token. The UA MUST obtain a new access token before the access token expiry period to continue to get service from the system. 4. Authorization Header Syntax This section describes the syntax of the authorization header with the Bearer scheme. Authorization = "Authorization" HCOLON "Bearer" LWS "access_token" EQUAL access_token - access-token = quoted-string + access_token = quoted-string 5. Security Considerations 6. IANA Considerations 7. Acknowledgments @@ -568,25 +579,25 @@ October 2015. Authors' Addresses Rifaat Shekh-Yusef (editor) Avaya 250 Sidney Street Belleville, Ontario Canada - Phone: +1-613-967-5267 + Phone: +1-613-967-5176 EMail: rifaat.ietf@gmail.com Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: christer.holmberg@ericsson.com Victor Pascual - Oracle + webrtchacks Spain - EMail: victor.pascual.avila@oracle.com + EMail: victor.pascual.avila@gmail.com