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/