Ericsson

Hirsalantie 11 Jorvas 02420 Finland christer.holmberg@ericsson.com

RAI The 3rd-Generation Partnership Project (3GPP) has defined how the WebRTC framework can be used to provide access to IMS services. Users can use "web credentials" (e.g. a username and password) to retrieve an authorization token (e.g. an OAuth 2.0 access token), which is included in the user registration request sent towards the IMS network. 3GPP has specified a requirement, that the eP-CSCF shall be able to include a string value, representing the identity of the WAF, in the REGISTER request forwarded towards the S-CSCF. The S-CSCF can use the identity for e.g. policy and routing decisions. This document defines a new Authorization header field parameter, 'authorization-entity', which the eP-CSCF can include in a REGISTER request in order to convey the identity of the WAF towards the S-CSCF.

The 3rd-Generation Partnership Project (3GPP) has defined how the WebRTC framework can be used to provide access to IMS services. Users can use "web credentials" (e.g. a username and password) to retrieve an authorization token (e.g. an OAuth 2.0 access token), which is included in the user registration request sent towards the IMS network. NOTE: The current assumption is that, when SIP is used between the WIC and the eP-CSCF, together with the OAuth 2.0 framework , the access token will be conveyed in the REGISTER request using the mechanism defined in . The WWSF (OAuth 2.0 Client role) authenticates the user (OAuth 2.0 Resource Owner role), and obtains the token from the WAF WAF (OAuth 2.0 Authorization Server role). The WWSF then provides the token to user (typically as part of a JavaScript application downloaded by the user), which then includes the token in the registration request (REGISTER request when SIP is used) towards the IMS network (OAuth 2.0 Resource Server role). When the eP-CSCF receives the registration request, it contacts the WAS and verifies the token. If the verification is successful, the WAF provides IMS credentials to eP-CSCF, which the eP-CSCF can include in the registration request sent towards the S-CSCF, in order to register the user using legacy IMS registration mechanisms. 3GPP has specified a requirement, that the eP-CSCF shall be able to include a string value, representing the identity of the WAF, in the REGISTER request forwarded towards the S-CSCF. The S-CSCF can use the identity for e.g. policy and routing decisions. This document defines a new Authorization header field parameter, 'authorization-entity', which the eP-CSCF can include in a REGISTER request in order to convey the identity of the WAF towards the S-CSCF. The 'authorization-entity' parameter is defined in order to fulfil requirements from the 3rd-Generation Partnership Project (3GPP), but it can also be used in other network environments.

WIC (WebRTC IMS Client): An application (typically a JavaScript application executed in a browser) using the WebRTC 1.0 extensions used to access IMS. WAF (WebRTC Authorisation Function): Provides and validates access tokens. In the OAuth 2.00 architecture the WAF represents the Authorization Server. WWSF (WebRTC Web Server Function): Retrieves access tokens on behalf of a user, and provides the WIC application code to the user. In the OAuth 2.0 architecture the WWSF represents the Client. CSCF: Call Session Control Function: IMS SIP proxy. Different types of CSCFs perform different functions in an IMS network. eP-CSCF (P-CSCF enhanced for WebRTC): A SIP proxy which validates the access token, and retrieves IMS credentials associated with the access token. S-CSCF (Serving CSCF): IMS SIP registrar.

REQ-1: It MUST be possible for a SIP proxy to include a string value, representing the identity of an authorization server, in a REGISTER request sent towards a SIP registrar.

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 .

This section defines a new Authorization header field 'authorization-entity' header field parameter. The header field parameter is used in a REGISTER request to convey a string value which represents the identity of an authorization server. The header field parameter is included in the REGISTER request by the entity which verifies the access token received from a SIP UA. This document only describes the usage of the authorization-entity header field parameter within a REGISTER request. Usage with other SIP methods, or within REGISTER responses, is unspecified.

This section defines the ABNF for the SIP Authorization 'authorization-entity' header field parameter. The ABNF defined in this specification is conformant to RFC 5234 .

The ABNF grammar for the 'authorization-entity' header field parameter is:

Security considerations come here.

[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] This specification adds one new header field parameter to the IANA registration in the "Header Field Parameters and Parameter Values" registry, as specified in .

The author wishes to thank everyone in the 3GPP community that provided input and comments on this document.

[RFC EDITOR NOTE: Please remove this section when publishing] draft-holmberg-sipcore-auth-id-XX Changes are described here.

Avaya

Quobis

This section contains example call flows based on 3GPP usage of the authorization-entity header field parameter.

The WWSF/WAF authenticates, obtains and provides an access token to, the WIC. The WIC includes the access token in the REGISTER request sent to the eP-CSCF. The eP-CSCF validates the access token with the WAF, and retrieves IMS credentials associated with the token. The eP-CSCF includes the IMS credentials, and a string value representing the identity of the WAF, in the REGISTER request before forwarding it towards the S-CSCF.

| | | | | | | | REGISTER F2 | | |-------------------------------->| | | | | | | | F3 | | | |<-------------->| | | | | REGISTER F4 | | | |--------------->| | | | | | | | 200 (OK) F5 | | | |<---------------| | 200 (OK) F6 | | |<--------------------------------| | | | | | F1 WIC <-> WWSF/WAF The WWSF/WAF authenticates Alice, using "web credentials" (e.g. username and password), and obtains an access token. The access token and the WIC (typically a JavaScript application) is provided to Alice. F2 REGISTER WIC -> eP-CSCF REGISTER sip:registrar.home1.net SIP/2.0 Authorization: Bearer access_token="O91G451HZ0V......" F3 eP-CSCF <-> WWSF/WAF The eP-CSCF validates the access token with the WAF, and retrieves IMS credentials associated with the user, and a string value representing the identity of the WAF. F4 REGISTER eP-CSCF -> S-CSCF REGISTER sip:registrar.home1.net SIP/2.0 Authorization: Digest username="user1_private@home1.net", realm="registrar.home1.net", nonce="", uri="sip:registrar.home1.net", response="", authorization-entity="webrtc_authserver1@thirdparty.net" F5 200 OK S-CSCF -> eP-CSCF 200 OK F6 200 OK eP-CSCF -> WIC 200 OK ]]>