draft-ietf-sipcore-sip-authn-01.txt   draft-ietf-sipcore-sip-authn-02.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: March 30, 2018 V. Pascual Expires: August 9, 2018 V. Pascual
webrtchacks webrtchacks
September 26, 2017 February 5, 2018
Third-Party Authentication for Session Initiation Protocol (SIP) Third-Party Authentication for Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-authn-01 draft-ietf-sipcore-sip-authn-02
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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 March 30, 2018. This Internet-Draft will expire on August 9, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. ID Token . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. ID Token . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. SIP User Agent Types . . . . . . . . . . . . . . . . . . 5 1.4. SIP User Agent Types . . . . . . . . . . . . . . . . . . 5
1.5. Authentication Types . . . . . . . . . . . . . . . . . . 5 1.5. Authentication Types . . . . . . . . . . . . . . . . . . 5
2. Authentication using the Authorization Code Flow . . . . . . 6 2. Authentication using the Authorization Code Flow . . . . . . 6
2.1. Public UA with Rich UI . . . . . . . . . . . . . . . . . 6 2.1. Public UA with Rich UI . . . . . . . . . . . . . . . . . 6
2.1.1. Registration . . . . . . . . . . . . . . . . . . . . 7 2.1.1. Initial Registration . . . . . . . . . . . . . . . . 7
2.1.2. Shared-Key . . . . . . . . . . . . . . . . . . . . . 8 2.1.2. Shared-Key . . . . . . . . . . . . . . . . . . . . . 8
2.1.3. Re-Registration Requests . . . . . . . . . . . . . . 8 2.1.3. Subsequent Registration . . . . . . . . . . . . . . . 8
2.1.4. Token Refresh . . . . . . . . . . . . . . . . . . . . 9 2.1.4. Token Refresh . . . . . . . . . . . . . . . . . . . . 9
2.2. Public UA with Limited UI . . . . . . . . . . . . . . . . 10 2.2. Public UA with Limited UI . . . . . . . . . . . . . . . . 10
2.2.1. Registration . . . . . . . . . . . . . . . . . . . . 10 2.2.1. Registration . . . . . . . . . . . . . . . . . . . . 10
2.2.2. Shared-Key . . . . . . . . . . . . . . . . . . . . . 11 2.2.2. Shared-Key . . . . . . . . . . . . . . . . . . . . . 11
2.2.3. Token Refresh . . . . . . . . . . . . . . . . . . . . 11 2.2.3. Token Refresh . . . . . . . . . . . . . . . . . . . . 11
2.2.4. Re-Registration Requests . . . . . . . . . . . . . . 12 2.2.4. Subsequent Registration . . . . . . . . . . . . . . . 12
3. Authentication using the Resource Owner Password Credentials 3. Authentication using the Resource Owner Password Credentials
flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Registration . . . . . . . . . . . . . . . . . . . . . . 13 3.2. Initial Registration . . . . . . . . . . . . . . . . . . 13
3.3. Subsequent Requests . . . . . . . . . . . . . . . . . . . 14 3.3. Subsequent Requests . . . . . . . . . . . . . . . . . . . 14
4. Authorization Header Syntax . . . . . . . . . . . . . . . . . 14 4. Authorization Header Syntax . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. Shared Key Feature-Capability Indicator . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. Normative References . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The SIP protocol [RFC3261] uses the framework used by the HTTP The SIP protocol [RFC3261] uses the framework used by the HTTP
protocol for authenticating users, which is a simple challenge- protocol for authenticating users, which is a simple challenge-
response authentication mechanism that allows a server to challenge a response authentication mechanism that allows a server to challenge a
client request and allows a client to provide authentication client request and allows a client to provide authentication
information in response to that challenge. information in response to that challenge.
OAuth 2.0 [RFC6749] defines a token based authorization framework to OAuth 2.0 [RFC6749] defines a token based authorization framework to
skipping to change at page 5, line 32 skipping to change at page 5, line 32
o Proxy-to-User: which allows a server that is providing a service o Proxy-to-User: which allows a server that is providing a service
to authenticate the identity of a user before providing the to authenticate the identity of a user before providing the
service. service.
o User-to-User: which allows a user receiving a request to o User-to-User: which allows a user receiving a request to
authenticate the identity of the remote user before processing the authenticate the identity of the remote user before processing the
request. request.
The mechanism defined in this document addresses the proxy-to-user The mechanism defined in this document addresses the proxy-to-user
authentication only. For user-to-user authentication refer to the authentication only. For user-to-user authentication refer to the
mechanism defined in [STIR]. mechanism defined in [RFC474bis].
2. Authentication using the Authorization Code Flow 2. Authentication using the Authorization Code Flow
Authorization Code Flow is used by the SIP UA to authenticate to a Authorization Code Flow is used by the SIP UA to authenticate to a
third-party IdP entity to obtain an authorization code that would be third-party IdP entity and to obtain an authorization code that would
later used by the SIP Proxy to obtain tokens to allow the SIP UA to be later used by the SIP Proxy to obtain tokens to allow the SIP UA
register and get service from the SIP network. to register and get service from the SIP network.
2.1. Public UA with Rich UI 2.1. Public UA with Rich UI
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 401 Unauthorized | | | F2 401 Unauthorized | |
| Location: AuthZ Server |
|<------------------------------| | |<------------------------------| |
| | | | | |
| | | | | |
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 6, line 47 skipping to change at page 6, line 48
| | | | | |
| | The proxy will then use the | | | The proxy will then use the |
| | authz code to obtain tokens | | | authz code to obtain tokens |
| | from the authz server | | | from the authz server |
| |<----------------------------->| | |<----------------------------->|
| | | | | |
| 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 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 401 credentials. The proxy redirects the UA by responding with 401
Unauthorized (F2). 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
skipping to change at page 7, line 24 skipping to change at page 7, line 24
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 complete the registration process, and locally replies with 200 OK to complete the registration process, and 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. Initial 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 401 Unauthorized (F2) that includes the Server by responding with 401 Unauthorized (F2) that includes the
address of the Authorization Server in the form of an HTTP URI in a 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. 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.
The UA will then 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, using the "application/x-www-form-urlencoded"
parameters: format, in the body of the request with the following 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 access token, refresh token, and maybe ID authorization code for access token, refresh token, and maybe ID
token. The method used by the UA to obtain the tokens is out of token. The method used by the UA to obtain the tokens is out of
scope for 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; otherwise, the proxy MUST reply
with 401 Unauthorized.
2.1.2. Shared-Key 2.1.2. Shared-Key
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 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, 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: calculates the shared-key associated with this user as follows:
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 2.1.3. Subsequent Registration
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 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, using the "application/x-www-
form-urlencoded" format:
grant_type (REQUIRED) grant_type (REQUIRED)
Value MUST be set to "proof_of_possession". Value MUST be set to "proof_of_possession".
pop (REQUIRED) pop (REQUIRED)
The pop calculated the first time the UA registered with the The pop calculated using the shared-key created the first time the
proxy. UA registered with the 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
string. digest-string.
[[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 If the server supports the pop mechanism, then the server must
instead be used with all subsequent requests? If the answer is yes, validate the pop provided by the client. If the validation is
a new header should be defined to carry the pop instead of carrying successful, the server MUST reply with a 200 OK to complete the
it in the payload. registration process; otherwise, the server MUST reply with 401
Unauthorized.
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.
2.2. Public UA with Limited UI 2.2. Public UA with Limited UI
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 limited UI for the user authentication using a Public UA that has a limited UI
that cannot prompt the user for his credentials. that cannot prompt the user for his credentials.
This use case requires the user to use his browser to authenticate to This use case requires the user to use an out-of-band mechanism (e.g.
the Authorization Server and obtain a short lived numeric 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 authorization code that would be used by the phone to register with
the SIP proxy. the SIP proxy.
User Proxy Authorization User Proxy Authorization
Agent Server Agent Server
--------------------------------------------------------------------- ---------------------------------------------------------------------
| | | | | |
The UA collects the numeric code from the user through the key-pad| The UA collects the numeric code from the user through the key-pad|
| | | | | |
| | | | | |
| F1 REGISTER [code] | | | F1 REGISTER [code] | |
|------------------------------>| | |------------------------------>| |
| | | | | |
| | The proxy will then use the | | | The proxy will then use the |
| | authz code to obtain an access| | | authz code to obtain tokens |
| | token and refresh token | | | from the authz server |
| |<----------------------------->| | |<----------------------------->|
| | | | | |
| F2 200 OK | | | F2 200 OK | |
|<------------------------------| | |<------------------------------| |
| | | | | |
2.2.1. Registration 2.2.1. Registration
The UA will send a REGISTER request (F1) and include the code in the The UA will send a REGISTER request (F1) and include the code in the
body of the request with the following parameters: body of the request, using the "application/x-www-form-urlencoded"
format, with the following 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 code received from the authorization server through the The code received from the authorization server through the out-
browser. of-bound mechanism.
The proxy then contacts the Authorization Server and exchanges the The proxy then contacts the Authorization Server and exchanges the
authorization code for access token, refresh token, and maybe an ID 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 token. The method used by the UA to obtain the tokens is out of
scope for 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; otherwise, the proxy MUST reply
with 401 Unauthorized.
2.2.2. Shared-Key 2.2.2. Shared-Key
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 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, 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: calculates the shared-key associated with this user as follows:
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
proxy, in case of a connection loss to the proxy, without the need to
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
authorization process again. authorization process again.
2.2.4. Re-Registration Requests 2.2.4. Subsequent Registration
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 a proof-of-possession (pop) of the
shared-key in the body of the request: shared-key in the body of the request, using the "application/x-www-
form-urlencoded" format:
grant_type (REQUIRED) grant_type (REQUIRED)
Value MUST be set to "proof_of_possession". Value MUST be set to "proof_of_possession".
pop (REQUIRED) pop (REQUIRED)
The pop calculated the first time the UA registered with the The pop calculated using the shared-key created the first time the
proxy. UA registered with the 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
string. digest-string.
[[OPEN ISSUE]] Should this be not limited to re-registration, and
instead be used with all subsequent requests?
3. Authentication using the Resource Owner Password Credentials flow 3. Authentication using the Resource Owner Password Credentials flow
The resource owner password credentials flow is used by a The resource owner password credentials flow is used by a
Confidential UA with rich UI to authenticate to a third-party IdP 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 entity and to directly obtain tokens to be able to register and get
service from the SIP network. service from the SIP network.
3.1. Overview 3.1. Overview
skipping to change at page 13, line 38 skipping to change at page 13, line 38
|------------------------------>| | |------------------------------>| |
| | | | | |
| | The proxy validates the token | | | The proxy validates the token |
| | Optional introspection step | | | Optional introspection step |
| |<----------------------------->| | |<----------------------------->|
| | | | | |
| F2 200 OK | | | F2 200 OK | |
|<------------------------------| | |<------------------------------| |
| | | | | |
3.2. Registration 3.2. Initial Registration
The UA first contacts the Authorization Server to authenticate the The UA first contacts the Authorization Server to authenticate the
user and obtain tokens to be used to get access to the SIP network. 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 The method used by the UA to obtain the tokens is out of scope for
this document. this document.
The UA starts the registration process with the SIP proxy by sending The UA starts the registration process with the SIP proxy by sending
a REGISTER request (F1) with the access token it obtained previously. a REGISTER request (F1) with the access token it obtained previously.
The UA includes an Authorization header field with the Bearer scheme The UA includes an Authorization header field with the Bearer scheme
skipping to change at page 15, line 7 skipping to change at page 14, line 32
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> 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.
6. IANA Considerations 6. IANA Considerations
<IANA considerations text> 6.1. Shared Key Feature-Capability Indicator
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]
7. Acknowledgments 7. Acknowledgments
<Acknowledgments text> The authors would like to thank the following for their review and
feedback:
8. Normative References 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.
8. References
8.1. Normative References
[MITKB] "IdP (Identity Provider)", MIT Knowledge [MITKB] "IdP (Identity Provider)", MIT Knowledge
Base, http://kb.mit.edu/confluence/x/XoK2, March 2011. Base, http://kb.mit.edu/confluence/x/XoK2, March 2011.
[OPENID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and [OPENID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0", February 2014. C. Mortimore, "OpenID Connect Core 1.0", February 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, H., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, H., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. 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", [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, October 2012. 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, [RFC7662] Richer, J., "OAuth 2.0 Token Introspection", RFC 7662,
October 2015. October 2015.
Authors' Addresses 8.2. Informative References
[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.
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-5176 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
webrtchacks webrtchacks
 End of changes. 50 change blocks. 
74 lines changed or deleted 140 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/