X.5 TURN credential provisioning and authentication (informative)
33.2033G Security3GPPAccess security for IP-based servicesTS
X.5.1 Introduction
TURN RFC 8656 [78] specifies that TURN servers and clients MUST implement "Long-Term Credential Mechanism" as specified in clause 10.2 of RFC 8489 [77]. In this mechanism, the client and server share a pre-provisioned username and password that remains in the system till the user is using the system.The TURN server uses these credentials to authenticate the client by performing digest challenge/response.
In IMS_WebRTC, the browser plays the role of a TURN client. The WIC (i.e. the Javascript code) controls the execution of the browser via the W3C defined RTCPeerConnection API. Through this API, the WIC provides TURN credentials to the browser. These credentials should therefore be made available to the WIC.
There are two known gaps that need to be addressed before TURN can be used in IMS_WebRTC:
1) At present, the provisioning of TURN long-term credentials in the WIC is un-defined.
2) Moreover, as indicated in RFC 7376 [68], ensuring secrecy of these credentials in a web-based application such as the WIC is difficult. Once these credentials are exposed to a Javascript script, it could lead to various security issues such as leak of the credentials, privacy leakage etc.
A solution is needed to dynamically configure the TURN credentials in the WIC while ensuring that security gaps identified by RFC 7376 [68] are addressed.
Two solutions are presented in this annex for TURN credential provisioning and authentication:a) eP-CSCF based dynamic provisioning of credentials in the WIC and TURN server
b) TURN client authentication based OAuth 2.0 access tokens.
Both solutions are optional for implementation.
X.5.2 Solution 1: TURN credential provisioning and authentication using eP-CSCF
X.5.2.1 Overview
This solution reuses the TURN long-term credential method defined in RFC 8656 [78] , but the credential is dynamically provisioned by eP-CSCF via the signalling channel. When WIC registers to IMS, WIC requests the IMS networks to provision a credential for TURN authentication using a 3GPP extension header. If the request is authenticated and authorized, eP-CSCF generates a TURN credential, including user id, password, expiration, etc, and sends the credential to WIC in the response message. Since the signaling messages between WIC and eP-CSCF are protected by the secure protocols, e.g. secure Websocket, the TURN credential is securely transferred to WIC. The WIC retrieves the credential and uses it in subsequent TURN allocation requests. The WIC may request TURN credential for every registration, or use the credential until it expires. WIC can also use other signaling messages such as OPTION to request a new credential at anytime before re-registration.
This method requires some enhancement of WIC and eP-CSCF. WIC needs to be enhanced to use the 3GPP extension header to request TURN credential from eP-CSCF via signaling messages. The eP-CSCF needs to be enhanced to process TURN credential request and generate TURN user name and password using a preshared key with the TURN server. The TURN server also needs to be enhanced to re-generate TURN password from username in TURN request and the preshared key with P-CSCF.
This solution provides a way to provision TURN credential in large scale with minor change to existing functions. It addresses the security issues in RFC 8489 [76] by dynamically generating TURN user name and password. This solution is optional to support. When to use this solution depends on WebRTC deployment scenario and operator’s policy. For example, if a deployment does not have WAF, or if the WAF or TURN server does not support TURN access token, the eP-CSCF based approach may be used for TURN credential provision and authentication since the alternative solution requires the use of WAF and support of TURN access token by TURN server, WAF.
X.5.2.2 Procedures
The procedure of TURN credential provision via eP-CSCF is shown in figure X.5.2.2.1. To use this solution, a shared secret key Km should be configured between eP-CSCF and TURN server using out of band method not defined in this solution.
1) WIC establishes secure websocket with eP-CSCF
2) WIC sends REGISTER request to eP-CSCF with 3GPP extended header (3gpp-ext-turn-cred) for TURN credential request.
3) eP-CSCF authenticate and authorized the request then
1) Generate a random user ID Tid and credential expiration time Texp based on its policy, Tid and Texp should be encoded as string type.
2) Generate TURN password using Km, Tpwd = HASH (Km , Tid : Texp )
4) eP-CSCF sends REGISTER response with generated TURN credential using the 3gpp extended header. The valud of the header = (Tid : Texp : Tpwd), which is the concatenation of Tid, Texp, Tpwd separated by semi-colon sign.
5) IC extracts the TURN credential from the TURN credential header. The WIC uses (Tid : Texp) as TURN USERNAME and uses Kpwd to compute the MESSAGE-INTEGRITY value of TURN Allocate request as defined in IETF RFC 58656 [78].
6) TURN server re-generates TURN password using the USERNAME attribute in request and the preshared key with eP-CSCF
7) TURN server validates that the credential has not expired and verifies the integrity of the TURN request using the password generated in step 6.
8) TURN server sends Allocate response with allocated relay address to WIC
The procedure above uses REGISTER as example to explain how to request TURN credential from eP-CSCF by signaling messages. WIC may use other signaling messages, such as OPTIONAL, to request TURN credential.
Figure X.5.2.2-1: TURN Credential provisioned by eP-CSCF
X.5.3 Solution 2: TURN credential provisioning and authentication using OAuth Access token
X.5.3.1 Overview
IETF RFC 7635[70] proposes a new mechanism for TURN client authentication authorization mechanism different from the current long-term credential solution. In this mechanism, third party authorization using OAuth 2.0 is used by the TURN server to authorize the TURN client instead of the regular username/password mechanism.
Using OAuth 2.0, the TURN client obtains an ephemeral self-contained access token and the associated secret session key from the authorization server. The authorization server acts as a trusted third party that binds the secret session key to the generated access token. The token is presented to the TURN server instead of username/password credentials. The server performs two checks to authorize the TURN client – it validates the authenticity of the received self-contained token, and in addition, also verifies that the TURN client is in possession of the secret key. It provides required services only after both the checks succeed. The secret key is used to integrity protect the connection between TURN client and TURN server.
The salient security features of this solution are the following:
a. Using ephemeral access token and session key with short lifetimes (in secs) ensure that access to TURN server can be controlled even if one or both of them are compromised in WIC. The session key has lifetime that corresponds to the lifetime of the access token.
b. The proof-of-possession security mechanism defined in IETF RFC 7800 [75] is used by the TURN server to authenticate the TURN client. A secret session key is bound to the access token by the Authorization server. This key is used to integrity-protect TURN messages between the TURN client and the server. The server confirms the authenticity of the TURN client by verifying the message integrity of the received message against the message integrity populated by the client.
c. Real usernames are not used in TURN messages. This ensures that there is no privacy leakage by any snooping adversary.
This solution has impacts on the following IMS WebRTC functional entities:
– WAF: WAF has to support extensions as defined by IETF RFC 7635[70]. WAF generates a self-contained access token and other required parameters (TURN session key and key id) in compliance with IETF RFC 7635[70]. The WAF and the TURN server share a long-term secret K. This key is used by the WAF to generate additional keys for encrypting the access token and ensuring message integrity of the message. Additional details on this can be found in IETF RFC 7635[70]. The provisioning of the long-term secret key in WAF and TURN server is out of scope of this solution.
– WebRTC IMS Client (WIC): The WIC performs the HTTPS request to WAF to obtain the access token, TURN session key and the key id. The WAF responds with the required parameters. The WIC configures these parameters in the TURN client through the W3C RTCPeerConnection API.
This solution also assumes that the TURN client and the TURN server are compliant with the extensions defined in IETF RFC 7635[70].
X.5.3.2 Procedures
The procedure provided in this clause is non-normative text due to 3GPP’s decision not to standardize the interfaces between the WIC and the WWSF (W1) and between the WWSF and the WAF (W4). These reference points may therefore be realized in a way different from the one described in this clause.
Figure X.5.3.2-1 illustrates a TURN authentication flow in IMS WebRTC based on OAuth 2.0 access token. As an example flow, OAuth Client credentials grant is used in this procedure to obtain an access token.
Following is the mapping of various roles:
a) The Browser, executing ICE Agent on behalf of the WIC, is the TURN client.
b) The WWSF is the OAuth client that interacts with the OAuth server to authenticate, and obtain access token.
c) The WAF is the OAuth authorization server that authenticates WWSF, the OAuth client, and issues access token and other required TURN parameters.
d) The TURN server is the OAuth resource server that receives and validates the access token from the TURN client.
Figure X.5.3.2-1 TURN authentication based on OAuth 2.0 access token
The details of the signalling flows are as follows:
Pre-requisite :
a. WWSF registers with the WAF [72]
WWSF, as the OAuth client, registers with the WAF associated with the TURN server. The WAF assigns a unique client id and client password to the registered WIC.
b. WIC registers with the IMS
The WIC performs IMS registration before the user is allowed to use IMS services. The user accesses a URI to initiate an HTTPS connection to the WWSF. The WIC is downloaded and initialized by the browser. The WIC performs one of the IMS WebRTC registration procedures to register with the IMS network.
Both these steps are completed in advance of the following steps.
1. User clicks on a button to make a WebRTC call
The user clicks on a button to make a WebRTC call.
2. WIC requests Access token
The WIC requests access token from the WWSF.
3. User authentication and authorization
The WWSF authenticates the user and obtains user authorization to allow WIC to setup a call.
NOTE 1: This step is optional. WWSF could skip this step if it has authenticated and obtained user’s authorization during IMS registration in scenarios 2 and 3, and IMS registration is still considered active.
4. WWSF requests access token from WAF
WWSF starts the OAuth Client credentials flow [72]. It issues HTTP GET to request access token from WAF. WWSF includes client_id and client_password in this request. The complete set of required parameters to be included in this GET request is defined in IETF RFC 7635[70].
5. WAF validates WWSF and issues access token
WAF authenticates WWSF and generates access token, session key and key id (kid) according to IETF RFC 7635[70]. Access token is structured according to the format in IETF RFC 7635[70].
The access token, session key and key identifier (kid) is returned back to WWSF.
6. WIC obtains access token from WWSF
WWSF forwards the access token, session key and the key identifier (kid) to WIC.
7. WIC initiates a WebRTC connection setup
The WIC initiates a WebRTC connection using W3C’s RTCPeerConnection API. TURN Server URI, key id (as username), session key (as credential) and access token are passed as arguments to this API.
8. Obtain “relayed transport address” on the TURN server
NOTE 2: This step is executed by WebRTC stack in the browser.
The WebRTC stack in the browser executes TURN protocol using enhancements for third party authorization as defined in IETF RFC 7635[70]. A relayed transport address is allocated in the TURN server.
All communication between the WIC and TURN server is now integrity protected.
NOTE 3: It is recommended that this solution be only used in IMS registrations scenarios 2 and 3. In both the scenarios, the user authentication is delegated by the IMS network to either the WWSF or the WAF. Once the user is authenticated, WAF provides WIC with an access token. The WIC then presents this token to the IMS network during IMS registration. This is very similar to the procedure described in this section for TURN client authentication based on OAuth access token. It is therefore possible to use the same WAF for generating access token for TURN authentication.
NOTE 4: IMS Registration scenario 3 provides a mechanism by which an anonymous user skips authenticating with the WWSF but is able to access IMS services like any other authenticated user. Similar mechanism is supported by this solution when "client credentials" based flow is used for TURN authentication. In the client credentials flow, WWSF is the OAuth client and requests access token on behalf of the user. WWSF authentication is performed by WAF, whereas the user authentication is performed by the WWSF. Therefore when anonymous user requests an access token, WWSF skips user authentication for the user. In the backend it will authenticate with the WAF and obtain an access token. The access token is then presented back to the user.
Annex Y (informative):
Change history
|
Change history |
|||||||||
|---|---|---|---|---|---|---|---|---|---|
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Cat |
Subject/Comment |
Old |
New |
WI |
|
2002-03 |
SP-15 |
SP-020116 |
– |
Approved at TSG SA #15 and placed under change control |
2.0.0 |
5.0.0 |
|||
|
2002-03 |
SP-15 |
SP-020174 |
001 |
F |
Correction of references to obsolete SIP RFC 2543bis IETF internet draft |
5.0.0 |
5.1.0 |
||
|
2002-03 |
SP-15 |
SP-020175 |
002 |
F |
Removal of reference to non Operator IMS provision |
5.0.0 |
5.1.0 |
||
|
2002-06 |
SP-16 |
SP-020346 |
003 |
F |
ISIM related parameters |
5.1.0 |
5.2.0 |
||
|
2002-06 |
SP-16 |
SP-020347 |
004 |
F |
Reference of HTTP Digest AKA in TS 33.203 |
5.1.0 |
5.2.0 |
||
|
2002-06 |
SP-16 |
SP-020348 |
005 |
D |
Clean-up of section 6.1.1 |
5.1.0 |
5.2.0 |
||
|
2002-06 |
SP-16 |
SP-020349 |
006 |
F |
Integrity protection indicator |
5.1.0 |
5.2.0 |
||
|
2002-06 |
SP-16 |
SP-020350 |
007 |
F |
UE and P‑CSCF Behaviour on an Incomplete Authentication |
5.1.0 |
5.2.0 |
||
|
2002-06 |
SP-16 |
SP-020351 |
008 |
C |
Requested Changes for SIP integrity |
5.1.0 |
5.2.0 |
||
|
2002-06 |
SP-16 |
SP-020352 |
009 |
F |
Clean-up of 7.3 |
5.1.0 |
5.2.0 |
||
|
2002-06 |
SP-16 |
SP-020386 |
010 |
1 |
C |
Security association handling in IMS when the UE changes IP address |
5.1.0 |
5.2.0 |
|
|
2002-06 |
SP-16 |
SP-020354 |
011 |
D |
Remove Annexes that describes Extended HTTP Digest solution |
5.1.0 |
5.2.0 |
||
|
2002-09 |
SP-17 |
SP-020583 |
012 |
F |
SA handling when the UE changes IP address |
5.2.0 |
5.3.0 |
||
|
2002-09 |
SP-17 |
SP-020583 |
013 |
F |
Removal of some editor notes in TS 33.203 |
5.2.0 |
5.3.0 |
||
|
2002-09 |
SP-17 |
SP-020583 |
014 |
F |
Correction to S‑CSCF behaviour on Network Authentication Failure |
5.2.0 |
5.3.0 |
||
|
2002-09 |
SP-17 |
SP-020583 |
015 |
F |
Correcting the network behaviour in response to an incorrect AUT-S |
5.2.0 |
5.3.0 |
||
|
2002-09 |
SP-17 |
SP-020583 |
016 |
F |
Mitigating reflection attacks in IMS |
5.2.0 |
5.3.0 |
||
|
2002-09 |
SP-17 |
SP-020583 |
017 |
F |
Protect port number to be assigned by UE in re-registration |
5.2.0 |
5.3.0 |
||
|
2002-09 |
SP-17 |
SP-020583 |
018 |
F |
One SA for both TCP and UDP sockets |
5.2.0 |
5.3.0 |
||
|
2002-09 |
SP-17 |
SP-020583 |
019 |
F |
Correction of authentication vector distribution procedure |
5.2.0 |
5.3.0 |
||
|
2002-09 |
SP-17 |
SP-020583 |
020 |
F |
The definition of the key to be used for HMAC-SHA1-96 within ESP |
5.2.0 |
5.3.0 |
||
|
2002-09 |
SP-17 |
SP-020583 |
021 |
F |
Draft-ietf-sip-sec-agree syntax for manually keyed IPsec |
5.2.0 |
5.3.0 |
||
|
2002-09 |
SP-17 |
SP-020583 |
022 |
F |
Update of User Authentication Failure |
5.2.0 |
5.3.0 |
||
|
2002-09 |
SP-17 |
SP-020583 |
023 |
F |
Update of SA handling procedures |
5.2.0 |
5.3.0 |
||
|
2002-12 |
SP-18 |
SP-020710 |
024 |
F |
Correction of IP address acquisition in P‑CSCF |
5.3.0 |
5.4.0 |
||
|
2002-12 |
SP-18 |
SP-020711 |
025 |
F |
Sending error response when P‑CSCF receives unacceptable proposal |
5.3.0 |
5.4.0 |
||
|
2002-12 |
SP-18 |
SP-020712 |
026 |
F |
The use of SAs in user authentication failures |
5.3.0 |
5.4.0 |
||
|
2002-12 |
SP-18 |
SP-020713 |
027 |
F |
Clean up one Editor’s note in 33.203 |
5.3.0 |
5.4.0 |
||
|
2002-12 |
SP-18 |
SP-020714 |
028 |
F |
Re-use and re-transmission of RAND and AUTN |
5.3.0 |
5.4.0 |
||
|
2002-12 |
SP-18 |
SP-020715 |
029 |
F |
Update of SIP Security Agreement Syntax in Appendix H |
5.3.0 |
5.4.0 |
||
|
2002-12 |
SP-18 |
SP-020716 |
030 |
F |
Registration and SA lifetimes |
5.3.0 |
5.4.0 |
||
|
2002-12 |
SP-18 |
SP-020717 |
031 |
F |
Open issues in SA handling |
5.3.0 |
5.4.0 |
||
|
2002-12 |
SP-18 |
SP-020760 |
033 |
F |
TCP and UDP share the same SA |
5.3.0 |
5.4.0 |
||
|
2002-12 |
SP-18 |
SP-020761 |
034 |
F |
Indication in the UE that the SA is no longer active in P‑CSCF |
5.3.0 |
5.4.0 |
||
|
2003-03 |
SP-19 |
SP-030100 |
035 |
F |
Clarification of the use of ISIM and USIM for IMS access |
5.4.0 |
5.5.0 |
||
|
2003-03 |
SP-19 |
SP-030101 |
036 |
F |
Malicious UE bypassing the P‑CSCF |
5.4.0 |
5.5.0 |
||
|
2003-03 |
SP-19 |
SP-030102 |
037 |
F |
Ensuring the deletion of unwanted SAs |
5.4.0 |
5.5.0 |
||
|
2003-03 |
SP-19 |
SP-030103 |
038 |
F |
Add protected port into Via header |
5.4.0 |
5.5.0 |
||
|
2003-03 |
SP-19 |
SP-030111 |
039 |
F |
Correction of the Port 2 definition for SA establishment |
5.4.0 |
5.5.0 |
||
|
2003-06 |
SP-20 |
SP-030222 |
040 |
F |
Annex H: Alignment of Authentication algorithm handling with RFC3329 |
5.5.0 |
5.6.0 |
||
|
2003-06 |
SP-20 |
SP-030223 |
041 |
F |
Clarification on USIM-based access to IMS |
5.5.0 |
5.6.0 |
||
|
2003-09 |
SP-21 |
SP-030484 |
043 |
F |
Modification of the security association lifetime management |
5.6.0 |
5.7.0 |
||
|
2003-09 |
SP-21 |
SP-030485 |
044 |
F |
Annex H in 33.203 |
5.6.0 |
5.7.0 |
||
|
2003-09 |
SP-21 |
SP-030486 |
045 |
F |
Security association handling, behaviour of SIP over TCP and re-authentication |
5.6.0 |
5.7.0 |
||
|
2003-09 |
SP-21 |
SP-030483 |
042 |
B |
Introducing Cipher key Expansion for IMS |
5.6.0 |
6.0.0 |
||
|
2003-09 |
SP-21 |
SP-030487 |
046 |
B |
Introducing Confidentiality Protection for IMS |
5.6.0 |
6.0.0 |
||
|
2003-12 |
SP-22 |
SP-030596 |
048 |
1 |
A |
Correcting the text on sending an authentication response |
6.0.0 |
6.1.0 |
|
|
2003-12 |
SP-22 |
SP-030597 |
050 |
– |
A |
SA procedures |
6.0.0 |
6.1.0 |
|
|
2003-12 |
SP-22 |
SP-030598 |
052 |
– |
A |
SA parameters and management |
6.0.0 |
6.1.0 |
|
|
2003-12 |
SP-22 |
SP-030599 |
054 |
– |
A |
Reject or discard of messages |
6.0.0 |
6.1.0 |
|
|
2003-12 |
SP-22 |
SP-030600 |
056 |
– |
A |
Correcting the SA handling procedures |
6.0.0 |
6.1.0 |
|
|
2003-12 |
SP-22 |
SP-030601 |
057 |
– |
F |
Terminology alignment |
6.0.0 |
6.1.0 |
|
|
2003-12 |
SP-22 |
SP-030603 |
059 |
– |
D |
Removing anti-replay requirement from Confidentiality clause |
6.0.0 |
6.1.0 |
|
|
2003-12 |
SP-22 |
SP-030604 |
061 |
– |
A |
Ensuring the correct RAND is used in synchronization failures |
6.0.0 |
6.1.0 |
|
|
2003-12 |
SP-22 |
SP-030605 |
063 |
– |
A |
Network behaviour when a new REGISTER is challenged during an on going authentication |
6.0.0 |
6.1.0 |
|
|
2004-03 |
SP-23 |
SP-040153 |
064 |
– |
B |
Addition of AES transform |
6.1.0 |
6.2.0 |
|
|
2004-03 |
SP-23 |
SP-040154 |
065 |
– |
B |
Deploying TLS (sips:) for interoperation between IMS and non-IMS network |
6.1.0 |
6.2.0 |
|
|
2004-06 |
SP-24 |
SP-040372 |
066 |
– |
F |
Correction on IMS confidentiality protection |
6.2.0 |
6.3.0 |
|
|
2004-06 |
SP-24 |
SP-040373 |
067 |
– |
F |
SIP Privacy mechanism when IMS interworking with non-IMS (foreign) network |
6.2.0 |
6.3.0 |
|
|
2004-09 |
SP-25 |
SP-040618 |
069 |
– |
A |
Deletion of old authentication vectors in S-CSCF after re-synchronization |
6.3.0 |
6.4.0 |
|
|
2004-09 |
SP-25 |
SP-040618 |
071 |
– |
F |
SIP Privacy mechanism when IMS interworking with non-IMS (foreign) network |
6.3.0 |
6.4.0 |
|
|
2004-09 |
SP-25 |
SP-040618 |
072 |
– |
F |
IMS Service Profile is independent from Implicit Registration Set |
6.3.0 |
6.4.0 |
|
|
2004-12 |
SP-26 |
SP-040854 |
075 |
1 |
D |
Editorial corrections |
6.4.0 |
6.5.0 |
|
|
2005-03 |
SP-27 |
SP-050137 |
077 |
3 |
F |
Addition of reference to early IMS security TR |
6.5.0 |
6.6.0 |
|
|
2005-06 |
SP-28 |
SP-050261 |
080 |
1 |
F |
Description of 2xx Auth_Ok message |
6.6.0 |
6.7.0 |
IMS-ASEC |
|
2005-09 |
SP-29 |
SP-050543 |
0082 |
– |
A |
Corrections on Network hiding |
6.7.0 |
6.8.0 |
IMS-SEC |
|
2005-09 |
SP-29 |
SP-050544 |
0084 |
– |
A |
Clarification of the authentication failure procedures |
6.7.0 |
6.8.0 |
IMS-SEC |
|
2005-09 |
SP-29 |
SP-050545 |
0086 |
1 |
A |
Correction of handling of IMPUs by the P-CSCF |
6.7.0 |
6.8.0 |
IMS-SEC |
|
2005-09 |
SP-29 |
SP-050562 |
0087 |
– |
F |
Correction of an Inconsistency Between Annex H and RFC3329 |
6.7.0 |
6.8.0 |
TEI6 |
|
2005-12 |
SP-30 |
SP-050764 |
0088 |
– |
F |
Correction of text on negotiation of confidentiality algorithms |
6.8.0 |
6.9.0 |
IMS2 |
|
2005-12 |
SP-30 |
SP-050844 |
0089 |
3 |
B |
Extension of scope to encompass TISPAN NGN by addition of normative annex |
6.8.0 |
7.0.0 |
FBI |
|
2006-03 |
SP-31 |
SP-060060 |
0090 |
– |
F |
Change of terminology to use UE instead of mobile |
7.0.0 |
7.1.0 |
FBI |
|
2006-03 |
SP-31 |
SP-060060 |
0091 |
– |
B |
Enabling NAT traversal for signaling messages in the IMS access security framework |
7.0.0 |
7.1.0 |
FBI-ISE |
|
2006-06 |
SP-32 |
SP-060383 |
0092 |
– |
F |
Correction to the description of network hiding |
7.1.0 |
7.1.0 |
FBI |
|
2006-09 |
SP-33 |
SP-060495 |
0094 |
– |
A |
Correction of SIP Privacy reference errors |
7.2.0 |
7.3.0 |
TEI6 |
|
2006-09 |
SP-33 |
SP-060503 |
0095 |
– |
D |
Removal of editor’s note |
7.2.0 |
7.3.0 |
IMS-SE |
|
2006-09 |
SP-33 |
SP-060489 |
0098 |
– |
A |
Check for duplicate (IP address, port) pairs also in re-registrations |
7.2.0 |
7.3.0 |
IMS-SE |
|
2006-09 |
SP-33 |
SP-060503 |
0099 |
– |
F |
Removing Confidentiality indication from SM8 |
7.2.0 |
7.3.0 |
IMS |
|
2006-12 |
SP-34 |
SP-060805 |
0100 |
2 |
C |
Clarification to pseudo randomisation of port numbers |
7.3.0 |
7.4.0 |
FBI-PCBL |
|
2006-12 |
SP-34 |
SP-060809 |
0101 |
1 |
F |
Clarification on the usage of NDS/AF |
7.3.0 |
7.4.0 |
NDSAFTLS |
|
2007-03 |
SP-35 |
SP-070152 |
0104 |
2 |
C |
Handling of unprotected messages in IMS emergency case |
7.4.0 |
7.5.0 |
FBI-ISE (IMS-SE) |
|
2007-06 |
SP-36 |
SP-070329 |
0106 |
1 |
D |
Correction of several description mistakes |
7.5.0 |
7.6.0 |
IMS |
|
2007-09 |
SP-37 |
SP-070595 |
0107 |
2 |
A |
Authentication failure handling in IMS |
7.6.0 |
7.7.0 |
IMS-SE |
|
2007-09 |
SP-37 |
SP-070595 |
0105 |
5 |
B |
Update to procedures to allow SIP Digest and TLS in IMS |
7.7.0 |
8.0.0 |
FBI-PCBL-Security |
|
2007-10 |
– |
– |
– |
– |
– |
Correction of implementation of CR0105 rev 5 |
8.0.0 |
8.0.1 |
– |
|
2007-12 |
SP-38 |
SP-070786 |
0114 |
1 |
A |
Correction of Handling unprotected error messages |
8.0.1 |
8.1.0 |
TEI8 |
|
2007-12 |
SP-38 |
SP-070786 |
0115 |
1 |
C |
Addition to use of TLS for Authentication of Non-REGISTERs |
8.0.1 |
8.1.0 |
PktCbl-Sec |
|
2007-12 |
SP-38 |
SP-070786 |
0110 |
2 |
C |
Enhancements to Digest Procedures for Authentication of Non-REGISTERs |
8.0.1 |
8.1.0 |
FBI-PCBL-Security |
|
2007-12 |
SP-38 |
SP-070927 |
0117 |
2 |
C |
Informative Annex on use of authentication methods for non-registration messages |
8.0.1 |
8.1.0 |
PktCbl-Sec |
|
2008-03 |
SP-39 |
SP-080138 |
0123 |
1 |
C |
Stage 2 text on place for nonce generation |
8.1.0 |
8.2.0 |
PktCbl-Sec |
|
2008-03 |
SP-39 |
SP-080138 |
0124 |
2 |
B |
Support for dynamic SIP Digest password change |
8.1.0 |
8.2.0 |
PktCbl-Sec |
|
2008-03 |
SP-39 |
SP-080139 |
0122 |
1 |
A |
Correction of integrity protection indicator |
8.1.0 |
8.2.0 |
TEI8 |
|
2008-03 |
SP-39 |
SP-080170 |
0125 |
2 |
B |
Inclusion of NASS-IMS-bundled authentication scheme in Common IMS |
8.1.0 |
8.2.0 |
IMS-Sec |
|
2008-03 |
SP-39 |
SP-080170 |
0127 |
1 |
B |
Co-existence of authentication schemes: how can IMS network entities enforce that Digest is not used over 3GPP access? |
8.1.0 |
8.2.0 |
IMS-Sec |
|
2008-03 |
SP-39 |
SP-080211 |
0129 |
3 |
B |
Co-existence of authentication schemes – Resolution of editor’s notes |
8.1.0 |
8.2.0 |
IMS-Sec |
|
2008-06 |
SP-40 |
SP-080264 |
0128 |
1 |
C |
Authentication of non-registration messages in IMS: relation of SIP Digest proxy authentication and IP address check |
8.2.0 |
8.3.0 |
PktCbl-Sec |
|
2008-06 |
SP-40 |
SP-080264 |
0138 |
1 |
C |
Storage of old passwords in the S-CSCF to avoid password change synchronisation problems |
8.2.0 |
8.3.0 |
PktCbl-Sec |
|
2008-06 |
SP-40 |
SP-080268 |
0126 |
3 |
B |
Introduction of support for 3GPP2 IMS Access Security |
8.2.0 |
8.3.0 |
IMS-Sec |
|
2008-06 |
SP-40 |
SP-080265 |
0137 |
– |
F |
Clarification of usage of NULL encryption and TLS |
8.2.0 |
8.3.0 |
PktCbl-Sec |
|
2008-09 |
SP-41 |
SP-080544 |
0145 |
1 |
C |
Resolution of Editor’s note on 3GPP2 NDS requirement |
8.3.0 |
8.4.0 |
IMS-Sec |
|
2008-09 |
SP-41 |
SP-080544 |
0144 |
– |
F |
Removal of Editor’s note in Annex P.4.2 |
8.3.0 |
8.4.0 |
IMS-Sec |
|
2008-09 |
SP-41 |
SP-080544 |
0141 |
1 |
F |
Updates to stage 2 description of NASS-IMS bundled authentication |
8.3.0 |
8.4.0 |
IMS-Sec |
|
2008-09 |
SP-41 |
SP-080544 |
0140 |
1 |
F |
Correction of description of HSS tasks |
8.3.0 |
8.4.0 |
IMS-Sec |
|
2008-09 |
SP-41 |
SP-080485 |
0143 |
– |
B |
New normative Annex on GPRS-IMS-Bundled Authentication (GIBA) |
8.3.0 |
8.4.0 |
IMS-Sec |
|
2008-09 |
SP-41 |
SP-080485 |
0142 |
– |
F |
Changes to TS 33.203 due to a new normative Annex on GIBA |
8.3.0 |
8.4.0 |
IMS-Sec |
|
2008-12 |
SP-42 |
SP-080742 |
148 |
1 |
F |
Usage of SIP digest and NBA values between the S-CSCF and the HSS |
8.4.0 |
8.5.0 |
IMS-Sec |
|
2008-12 |
SP-42 |
SP-080742 |
149 |
2 |
F |
Consistent handling of the integrity-protected flag and Inclusion of authentication procedures related to ICS |
8.4.0 |
8.5.0 |
IMS-Sec |
|
2008-12 |
SP-42 |
SP-080888 |
151 |
4 |
F |
Correcting the IMC text |
8.4.0 |
8.5.0 |
IMS-Sec |
|
2008-12 |
SP-42 |
SP-080742 |
152 |
– |
F |
Editorial corrections in Annex P3 and P.4.2 |
8.4.0 |
8.5.0 |
IMS-Sec |
|
2008-12 |
SP-42 |
SP-080742 |
153 |
– |
F |
Removal of SIP Digest Authentication Vector Editor’s Note |
8.4.0 |
8.5.0 |
IMS-Sec |
|
2008-12 |
SP-42 |
SP-080742 |
154 |
– |
F |
Usage of AVs for authentication of Register and Non-Register messages |
8.4.0 |
8.5.0 |
IMS-Sec |
|
2008-12 |
SP-42 |
SP-080742 |
155 |
– |
F |
ISIM terminology |
8.4.0 |
8.5.0 |
IMS-Sec |
|
2009-03- |
SP-43 |
SP-090142 |
156 |
– |
B |
Solution for NAT traversal in GPRS-IMS-Bundled Authentication |
8.5.0 |
9.0.0 |
TEI9 |
|
2009-12 |
SP-44 |
SP-090271 |
158 |
– |
A |
Correction of wrong message name in annex N (Rel-8) |
9.0.0 |
9.1.0 |
IMS-Sec |
|
2009-12 |
SP-44 |
SP-090271 |
161 |
1 |
A |
Removing Editor’s note from Annex T |
9.0.0 |
9.1.0 |
IMS-Sec |
|
2009-09 |
SP-45 |
SP-090521 |
163 |
1 |
A |
Removal of editor’s note on Proxy-Authentication Info header |
9.1.0 |
9.2.0 |
IMS-Sec |
|
2009-09 |
SP-45 |
SP-090521 |
165 |
1 |
A |
Aligning NBA and GIBA procedures with stage 3 |
9.1.0 |
9.2.0 |
TEI8 |
|
2009-09 |
SP-45 |
SP-090521 |
166 |
1 |
A |
Removal of TLS profile editor’s note. |
9.1.0 |
9.2.0 |
TEI8 |
|
2009-09 |
SP-46 |
SP-090816 |
0170 |
– |
A |
Removing editor’s notes in Annex P |
9.2.0 |
9.3.0 |
IMS-Sec |
|
2009-09 |
SP-46 |
SP-090816 |
0169 |
– |
A |
Removal of editor’s note on draft-ieft-sip-outbound |
9.2.0 |
9.3.0 |
IMS-Sec |
|
2009-09 |
SP-46 |
SP-090866 |
0171 |
– |
F |
Correction of erroneous interface name |
9.2.0 |
9.3.0 |
IMS-Sec |
|
2009-09 |
SP-46 |
SP-090858 |
0174 |
1 |
F |
X.509 certificate profile alignment |
9.2.0 |
9.3.0 |
TEI9 |
|
2010-06 |
SP-48 |
SP-100251 |
0178 |
– |
F |
X.509 Certificate profile aligment |
9.3.0 |
9.4.0 |
TEI9 |
|
2010-06 |
SP-48 |
SP-100378 |
0177 |
– |
F |
SIP Digest without Authorization header in first REGISTER message |
9.4.0 |
10.0.0 |
TEI9 |
|
2010-06 |
SP-48 |
SP-100368 |
0179 |
– |
F |
X.509 Certificate profile aligment |
9.4.0 |
10.0.0 |
TEI10 |
|
2010-10 |
SP-49 |
SP-100478 |
184 |
1 |
A |
Correction of SIP digest credential wording in N.2.5 |
10.0.0 |
10.1.0 |
TEI9 |
|
2010-10 |
SP-49 |
SP-100474 |
185 |
2 |
C |
IPsec alignment |
10.0.0 |
10.1.0 |
TEI10 |
|
2010-10 |
SP-49 |
SP-100482 |
186 |
1 |
C |
Introduction of reference to TS 33.310 for TLS profile into TS 33.203 |
10.0.0 |
10.1.0 |
TEI10 |
|
2010-12 |
SP-50 |
SP-100714 |
187 |
1 |
F |
Clarification of GIBA restrictions |
10.1.0 |
10.2.0 |
TEI10 |
|
2010-12 |
SP-50 |
SP-100725 |
188 |
1 |
C |
IPsec alignment |
10.2.0 |
11.0.0 |
TEI11 |
|
2012-03 |
SP-55 |
SP-120039 |
189 |
– |
D |
Editorial correction of scope in Annex S on 3GPP2 access |
11.0.0 |
11.1.0 |
SEC11 |
|
2012-06 |
SP-56 |
SP-120338 |
190 |
1 |
C |
Update for use with EPS |
11.2.0 |
12.0.0 |
SEC12 |
|
2012-06 |
SP-56 |
SP-120338 |
191 |
1 |
F |
Editorial Corrections and cleaning |
11.2.0 |
12.0.0 |
SEC12 |
|
2012-09 |
SP-57 |
SP-120602 |
192 |
3 |
C |
TLS enhancements for IMS signaling security |
12.0.0 |
12.1.0 |
SEC12 |
|
2013-06 |
SP-60 |
SP-130254 |
198 |
– |
B |
Specification of Tunnelling of UE Services over Restrictive Access Networks – IMS |
12.1.0 |
12.2.0 |
TURAN |
|
2013-09 |
SP-61 |
SP-130404 |
199 |
1 |
B |
Firewall traversal for IMS services based on ICE |
12.2.0 |
12.3.0 |
TURAN |
|
SP-130402 |
200 |
– |
D |
Clarification regarding NAT and GIBA |
SEC12 |
||||
|
SP-130404 |
201 |
1 |
F |
Correction of Specification of Tunnelling of UE Services over Restrictive Access Networks – IMS case |
TURAN |
||||
|
SP-130404 |
202 |
– |
D |
Missing caption and hanging paragraph |
TURAN |
||||
|
2012-12 |
SP-62 |
SP-130665 |
204 |
1 |
F |
Incorrect reference for keep-alive mechanism |
12.3.0 |
12.4.0 |
TURAN |
|
2014-03 |
SP-63 |
SP-140022 |
205 |
2 |
F |
The mechanism for the IMS client to determine when TURN over TCP/TLS can be used |
12.4.0 |
12.5.0 |
TURAN |
|
2014-06 |
SP-64 |
SP-140312 |
208 |
1 |
B |
Description of scenario 2 in new Annex on WebRTC |
12.5.0 |
12.6.0 |
IMS_WebRTC |
|
209 |
1 |
B |
Description of scenario 3 in new Annex on WebRTC |
||||||
|
211 |
1 |
B |
Skeleton for new Annex on WebRTC |
||||||
|
212 |
2 |
B |
WebRTC IMS Client registration using SIP Digest |
||||||
|
213 |
1 |
B |
New Annex on WebRTC with re-use of IMS AKA scheme for WIC authentication |
||||||
|
2014-09 |
SP-65 |
SP-140593 |
216 |
1 |
F |
Correction to 33.203 of TLS cipher suites profile for IMS access security |
12.6.0 |
12.7.0 |
TEI12 |
|
217 |
1 |
F |
Correction to 33.203 of TLS profile regarding renegotiation |
||||||
|
218 |
1 |
F |
Correction and clarification of SPI information in Security-client header (R12) |
||||||
|
SP-140588 |
221 |
1 |
F |
Verification of WIC may not require CORS |
IMS_WebRTC |
||||
|
222 |
– |
D |
Editorial correction relating to WebRTC registration scenarios |
||||||
|
223 |
– |
F |
Terminology in WebRTC |
||||||
|
224 |
1 |
F |
WIC authentication with IMS AKA |
||||||
|
225 |
1 |
F |
Effects on key theft when using IMS-AKA |
||||||
|
2014-12 |
SP-66 |
SP-140825 |
227 |
– |
F |
Addition in Annex P of IMS AKA over TLS for WebRTC |
12.7.0 |
12.8.0 |
IMS_WebRTC |
|
228 |
1 |
F |
TLS details for WebRTC with IMS AKA |
||||||
|
229 |
– |
F |
Clarification of term authorization entity |
||||||
|
230 |
1 |
F |
Restructuring of TS 33.203 to clarify how eP-CSCF obtains authorization information |
||||||
|
231 |
1 |
F |
Correction of reference |
||||||
|
2015-09 |
SP-69 |
SP-150477 |
240 |
1 |
F |
Adding TLS Reference in TS 33.203 Annex W |
12.8.0 |
12.9.0 |
TURAN-SA3, TEI12 |
|
SP-150486 |
241 |
1 |
F |
Trans mode of NAT traversal in TS 33.203v12.8.0 |
SEC12 |
||||
|
SP-150474 |
235 |
2 |
B |
Overview of solutions for TURN credential provisioning and Authentication |
12.9.0 |
13.0.0 |
eWebRTCi |
||
|
236 |
2 |
B |
Solution for WebRTC TURN credential provisioning and authentication with eP-CSCF |
||||||
|
238 |
– |
B |
Solution for TURN credential provisioning and Authentication using OAuth 2.0 Access tokens |
||||||
|
239 |
– |
B |
Supporting Class of Users (WebRTC scenario 4) |
||||||
|
2015-12 |
SP-70 |
SP-150731 |
244 |
2 |
F |
Updating IMS security profiles in TS 33.203 |
13.0.0 |
13.1.0 |
SEC13 |
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2017-03 |
SA#75 |
Promotion to Release 14 without technical change |
14.0.0 |
||||
|
2017-06 |
SA#76 |
SP-170426 |
0246 |
– |
A |
Setting the salt value in UE and P-CSCF when using AES-GCM/AES-GMAC in IPSec ESP in IMS access security |
14.1.0 |
|
2017-09 |
SA#77 |
SP-170637 |
0247 |
1 |
D |
Modify the text format of section X5.2 |
15.0.0 |
|
2018-03 |
SA#79 |
SP-180047 |
0249 |
– |
F |
Clarification for TCP connection reuse |
15.1.0 |
|
2020-07 |
SA#88E |
SP-200410 |
0252 |
– |
A |
draft-ietf-tram-turn-third-party-authz has been published as RFC7635 |
15.2.0 |
|
2020-07 |
– |
– |
– |
– |
– |
Update to Rel-16 version (MCC) |
16.0.0 |
|
2020-09 |
SA#89e |
SP-200714 |
0256 |
– |
A |
Update of the OAuth Proof-of-Possession security architecture reference |
16.1.0 |
|
2021-12 |
SA#94e |
SP-211379 |
0261 |
2 |
B |
Recommendation of SHA256 in SIP digest |
17.0.0 |
|
2021-12 |
SA#94e |
SP-211379 |
0262 |
1 |
B |
Security updates for algorithms and protocols in 33.203 |
17.0.0 |
|
2022-03 |
SA#95e |
SP-220229 |
0263 |
– |
F |
Adding Reference to RFC 7235 in TS 33.203 |
17.1.0 |