| SIP Core | R. Shekh-Yusef, Ed. |
| Internet-Draft | Avaya |
| Updates: 3261 (if approved) | C. Holmberg |
| Intended status: Standards Track | Ericsson |
| Expires: August 9, 2018 | V. Pascual |
| webrtchacks | |
| February 5, 2018 |
Third-Party Authentication for Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-authn-02
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.
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 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 August 9, 2018.
Copyright (c) 2018 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 (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 material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
The SIP protocol [RFC3261] uses the framework used by the HTTP protocol for authenticating users, which is a simple challenge- response authentication mechanism that allows a server to challenge a client request and allows a client to provide authentication information in response to that challenge.
OAuth 2.0 [RFC6749] defines a token based authorization framework to allow clients to access resources on behalf of their user.
The OpenID Connect 1.0 [OPENID] specifications defines a simple identity layer on top of the OAuth 2.0 protocol, which enables clients to verify the identity of the user based on the authentication performed by a dedicated IdP entity, as well as to obtain basic profile information about the user.
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
ID token, as defined in the OpenID document, is a security token that contains claims about the authentication of an end-user by an authorization server.
[RFC6749] defines two types of clients, confidential and public, that apply to the SIP User Agents.
There are two types of user authentications in SIP:
The mechanism defined in this document addresses the proxy-to-user authentication only. For user-to-user authentication refer to the mechanism defined in [RFC474bis].
Authorization Code Flow is used by the SIP UA to authenticate to a third-party IdP entity and to obtain an authorization code that would be later used by the SIP Proxy to obtain tokens to allow the SIP UA to register and get service from the SIP network.
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 401 Unauthorized | | | Location: AuthZ Server | |<------------------------------| | | | | | | | 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. | |<------------------------------------------------------------->| | | | | | | | F3 REGISTER [authz code] | | |------------------------------>| | | | | | | The proxy will then use the | | | authz code to obtain tokens | | | from the authz server | | |<----------------------------->| | | | | 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 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 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 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.
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 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.
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.
The UA will then send a new REGISTER request (F3) and include the authorization code, using the "application/x-www-form-urlencoded" format, in the body of the request with the following parameters:
grant_type (REQUIRED)
code (REQUIRED)
The proxy then contacts the Authorization Server and exchanges the 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; otherwise, the proxy MUST reply with 401 Unauthorized.
The shared-key could be used to allow the UA to recover from a connection loss to the server without the need to prompt the user for credentials.
If the server supports the use of shared-key, it MUST indicate that by adding the new sip.shared-key parameter to the feature-caps header in the 200 OK response to the REGISTER request.
After sending the 200 OK to the UA to complete the registration process, assuming that both the server and the client support his feature, the proxy and the UA use the HMAC-SHA256(key, message) to calculates the shared-key associated with this user as follows:
key
message
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, using the "application/x-www-form-urlencoded" format:
grant_type (REQUIRED)
pop (REQUIRED)
The pop is calculated using the shared-key as follows:
See [RFC4474], section 9, for the SIP headers to hash to create digest-string.
If the server supports the pop mechanism, then the server must validate the pop provided by the client. If the validation is successful, the server MUST reply with a 200 OK to complete the registration process; otherwise, the server MUST reply with 401 Unauthorized.
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.
The following figure provides a high level view of flow of messages for the user authentication using a Public UA that has a limited UI that cannot prompt the user for his credentials.
This use case requires the user to use an out-of-band mechanism (e.g. a Browser or a One-Time-Password (OTP) application) to authenticate to the Authorization Server and obtain a short lived numeric authorization code that would be used by the phone to register with the SIP proxy.
User Proxy Authorization Agent Server --------------------------------------------------------------------- | | | The UA collects the numeric code from the user through the key-pad| | | | | | | | F1 REGISTER [code] | | |------------------------------>| | | | | | | The proxy will then use the | | | authz code to obtain tokens | | | from the authz server | | |<----------------------------->| | | | | F2 200 OK | | |<------------------------------| | | | |
The UA will send a REGISTER request (F1) and include the code in the body of the request, using the "application/x-www-form-urlencoded" format, with the following parameters:
grant_type (REQUIRED)
code (REQUIRED)
The proxy then contacts the Authorization Server and exchanges the 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; otherwise, the proxy MUST reply with 401 Unauthorized.
The shared-key could be used to allow the UA to recover from a connection loss to the server without the need to prompt the user for credentials.
If the server supports the use of shared-key, it MUST indicate that by adding the new sip.shared-key parameter to the feature-caps header in the 200 OK response to the REGISTER request.
After sending the 200 OK to the UA to complete the registration process, assuming that both the server and the client support his feature, the proxy and the UA use the HMAC-SHA256(key, message) to calculates the shared-key associated with this user as follows:
key
message
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.
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 a proof-of-possession (pop) of the shared-key in the body of the request, using the "application/x-www-form-urlencoded" format:
grant_type (REQUIRED)
pop (REQUIRED)
The pop is calculated using the shared-key as follows:
See [RFC4474], section 9, for the SIP headers to hash to create digest-string.
The resource owner password credentials flow is used by a Confidential UA with rich UI to authenticate to a third-party IdP entity and to directly obtain tokens to be able to register and get service from the SIP network.
The following figure provides a high level view of flow of messages for the OAuth Resource Owner Password Credentials flow:
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=<access_token> | |------------------------------>| | | | | | | The proxy validates the token | | | Optional introspection step | | |<----------------------------->| | | | | F2 200 OK | | |<------------------------------| | | | |
The UA first contacts the Authorization Server to authenticate the user and obtain tokens to be used to get access to the SIP network. The method used by the UA to obtain the tokens is out of scope for this document.
The UA starts the registration process with the SIP proxy by sending a REGISTER request (F1) with the access token it obtained previously.
The UA includes an Authorization header field with the Bearer scheme in the request to carry the access token obtained previously.
The proxy then validates the token, and MAY perform an introspection step to get more information about the token and its scope. The introspection step is out of scope for this document.
When the proxy is satisfied with the token, it then replies with the 200 OK to complete the registration process.
All subsequent requests from the UA MUST include a valid access token. The UA MUST obtain a new access token before the access token expiry period to continue to get service from the system.
Authorization = "Authorization" HCOLON "Bearer" LWS
"access_token" EQUAL access_token
access_token = quoted-string
This section describes the syntax of the authorization header with the Bearer scheme.
As this document uses the mechanism defined in the OAuth 2.0 [RFC6749], many of the security consideration in the OAuth 2.0 document apply to this document too.
The shared-key mechanism used with the Public UA allows a UA to re-register without the need to obtain a new access code. If this shared-key is leaked, an adversary will be able to register a UA and impersonate the attacked user.
To reduce the chances of the shared-key being leaked, the UA should not store the shared-key in a permanent storage, but keep it in memory only.
A server should limit the use of shared-key to clients that are able to provide an adequate level of protection for the shared-key. In some deployments, the server might decide not to support the use of shared-key at all.
This document defines the feature capability sip.shared-key in the "SIP Feature-Capability Indicator Registration Tree" registry defined in [RFC6809].
Name: sip.shared-key
Description: This feature-capability indicator, when included in a Feature-Caps header field of a REGISTER response, indicates that the server supports the use of shared-key mechanism.
Reference: [this document]
The authors would like to thank the following for their review and feedback:
Andrew Allen, Martin Dolly, Keith Drage, Paul Kyzivat, Jon Peterson, Michael Procter, Roy Radhika, Matt Ryan, Ivo Sedlacek, Roman Shpount, Robert Sparks, Asveren Tolga, and Dale Worley.
Special thanks to Jon Peterson for a long discussion on the ideas and concepts around the use of OpenID/OAuth as an authentication and authorization mechanisms in a SIP network.
| [MITKB] | , MIT., "IdP (Identity Provider)", MIT Knowledge Base, http://kb.mit.edu/confluence/x/XoK2, March 2011. |
| [OPENID] | Sakimura, N., Bradley, J., Jones, M., de Medeiros, B. and C. Mortimore, "OpenID Connect Core 1.0", February 2014. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. |
| [RFC3261] | Rosenberg, J., Schulzrinne, H., Camarillo, H., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. |
| [RFC4474] | Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", August 2006. |
| [RFC6749] | Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. |
| [RFC7231] | Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. |
| [RFC7662] | Richer, J., "OAuth 2.0 Token Introspection", RFC 7662, October 2015. |
| [RFC474bis] | Peterson, J., Jennings, C., Rescorla, E. and C. Wendt, "Authenticated Identity Management in SIP", https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/, February 2017. |