idnits 2.17.1 draft-holmberg-sipcore-auth-id-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 28, 2015) is 3249 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-yusef-sipcore-sip-oauth-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Intended status: Standards Track May 28, 2015 5 Expires: November 29, 2015 7 Authorization server identity 8 draft-holmberg-sipcore-auth-id-01.txt 10 Abstract 12 The 3rd-Generation Partnership Project (3GPP) has defined how the 13 WebRTC framework can be used to provide access to IMS services. 14 Users can use "web credentials" (e.g. a username and password) to 15 obtain an authorization token (e.g. an OAuth 2.0 access token), which 16 is included in the user registration request sent towards the IMS 17 network. 19 3GPP has specified a requirement, that the eP-CSCF shall be able to 20 include a string value, representing the identity of the WAF, in the 21 REGISTER request forwarded towards the S-CSCF. The S-CSCF can use 22 the identity for e.g. policy decisions. 24 This document defines a new Authorization header field parameter, 25 'authorization-entity', which the eP-CSCF can include in a REGISTER 26 request in order to convey the identity of the WAF towards the 27 S-CSCF. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 29, 2015. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 5. 'authorization-entity' header field parameter . . . . . . . . 4 68 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 5.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 4 71 5.2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . 4 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 75 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 10. Normative References . . . . . . . . . . . . . . . . . . . . 5 77 Appendix A. 3GPP Examples . . . . . . . . . . . . . . . . . . . 6 78 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 A.2. WIC registration using web credentials . . . . . . . . . 6 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 The 3rd-Generation Partnership Project (3GPP) has defined how the 85 WebRTC framework can be used to provide access to IMS services. 86 Users can use "web credentials" (e.g. a username and password) to 87 obtain an authorization token (e.g. an OAuth 2.0 access token), which 88 is included in the user registration request sent towards the IMS 89 network. 91 NOTE: The current assumption is that, when SIP [RFC5234] is used 92 between the WIC and the eP-CSCF, together with the OAuth 2.0 93 framework [RFC6749], the access token will be conveyed in the 94 REGISTER request using the mechanism defined in 95 [I-D.yusef-sipcore-sip-oauth]. 97 The WWSF (OAuth 2.0 Client role) authenticates the user (OAuth 2.0 98 Resource Owner role), and obtains the token from the WAF (OAuth 2.0 99 Authorization Server role). The WWSF then provides the token to user 100 (typically as part of a JavaScript application downloaded by the 101 user), which then includes the token in the registration request 102 (REGISTER request when SIP [RFC3261] is used) towards the IMS network 103 (OAuth 2.0 Resource Server role). 105 When the eP-CSCF receives the registration request, it contacts the 106 WAF and verifies the token. If the verification is successful, the 107 WAF provides IMS credentials to eP-CSCF, which the eP-CSCF can 108 include in the registration request sent towards the S-CSCF, in order 109 to register the user using legacy IMS registration mechanisms. 111 3GPP has specified a requirement, that the eP-CSCF shall be able to 112 include a string value, representing the identity of the WAF, in the 113 REGISTER request forwarded towards the S-CSCF. The S-CSCF can use 114 the identity for e.g. policy and routing decisions. 116 This document defines a new Authorization header field parameter, 117 'authorization-entity', which the eP-CSCF can include in a REGISTER 118 request in order to convey the identity of the WAF towards the 119 S-CSCF. 121 The 'authorization-entity' parameter is defined in order to fulfil 122 requirements from the 3rd-Generation Partnership Project (3GPP), but 123 it can also be used in other network environments. 125 2. Abbreviations 127 WIC (WebRTC IMS Client): An application (typically a JavaScript 128 application executed in a browser) using the WebRTC 1.0 extensions 129 used to access IMS. 131 WAF (WebRTC Authorisation Function): Provides and validates access 132 tokens. In the OAuth 2.00 architecture the WAF represents the 133 Authorization Server. 135 WWSF (WebRTC Web Server Function): obtains access tokens on behalf of 136 a user, and provides the WIC application code to the user. In the 137 OAuth 2.0 architecture the WWSF represents the Client. 139 CSCF: Call Session Control Function: IMS SIP proxy. Different types 140 of CSCFs perform different functions in an IMS network. 142 eP-CSCF (P-CSCF enhanced for WebRTC): A SIP proxy which validates the 143 access token, and obtains IMS credentials associated with the access 144 token. In the OAuth 2.0 architecture the eP-CSCF represents verifies 145 the access token on behalf of the Resource Server. 147 S-CSCF (Serving CSCF): IMS SIP registrar. 149 3. Requirements 151 REQ-1: It MUST be possible for a SIP proxy to include a string value, 152 representing the identity of an authorization server, in a REGISTER 153 request sent towards a SIP registrar. 155 4. Conventions 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 5. 'authorization-entity' header field parameter 163 5.1. General 165 This section defines a new Authorization header field 'authorization- 166 entity' header field parameter. The header field parameter is used 167 in a REGISTER request to convey a string value which represents the 168 identity of an authorization server. The header field parameter is 169 included in the REGISTER request by the entity which verifies the 170 access token received from a SIP UA. 172 This document only describes the usage of the authorization-entity 173 header field parameter within a REGISTER request. Usage with other 174 SIP methods, or within REGISTER responses, is unspecified. 176 5.2. Syntax 178 5.2.1. General 180 This section defines the ABNF for the SIP Authorization 181 'authorization-entity' header field parameter. The ABNF defined in 182 this specification is conformant to RFC 5234 [RFC5234]. 184 5.2.2. ABNF 186 The ABNF [RFC5234] grammar for the 'authorization-entity' header 187 field parameter is: 189 dig-resp /= "authorization-entity" EQUAL quoted-string 190 ;; quoted-string defined in RFC 3261 192 6. Security Considerations 194 Security considerations come here. 196 7. IANA Considerations 198 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 199 document.] 201 This specification adds one new header field parameter to the IANA 202 registration in the "Header Field Parameters and Parameter Values" 203 registry, as specified in [RFC3969]. 205 Header Field: Authorization 206 Parameter Name: authorization-entity 207 Predefined Values: No 208 Reference: RFCXXXX 210 8. Acknowledgments 212 The author wishes to thank everyone in the 3GPP community that 213 provided input and comments on this document. 215 9. Change Log 217 [RFC EDITOR NOTE: Please remove this section when publishing] 219 draft-holmberg-sipcore-auth-id-xx 221 o 223 draft-holmberg-sipcore-auth-id-00 225 o Editorial changes/corrections. 227 10. Normative References 229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 230 Requirement Levels", BCP 14, RFC 2119, March 1997. 232 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 233 A., Peterson, J., Sparks, R., Handley, M., and E. 234 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 235 June 2002. 237 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 238 (IANA) Uniform Resource Identifier (URI) Parameter 239 Registry for the Session Initiation Protocol (SIP)", BCP 240 99, RFC 3969, December 2004. 242 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 243 Specifications: ABNF", STD 68, RFC 5234, January 2008. 245 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 246 6749, October 2012. 248 [I-D.yusef-sipcore-sip-oauth] 249 Shekh-Yusef, R. and V. Pascual, "The Session Initiation 250 Protocol (SIP) OAuth", draft-yusef-sipcore-sip-oauth-02 251 (work in progress), April 2015. 253 Appendix A. 3GPP Examples 255 A.1. General 257 This section contains example call flows based on 3GPP usage of the 258 authorization-entity header field parameter. 260 A.2. WIC registration using web credentials 262 The WWSF/WAF authenticates, obtains and provides an access token to, 263 the WIC. The WIC includes the access token in the REGISTER request 264 sent to the eP-CSCF. The eP-CSCF validates the access token with the 265 WAF, and obtains IMS credentials associated with the token. The eP- 266 CSCF includes the IMS credentials, and a string value representing 267 the identity of the WAF, in the REGISTER request before forwarding it 268 towards the S-CSCF. 270 Alice/WIC WWSF/WAF eP-CSCF S-CSCF 271 | | | | 272 | F1 | | | 273 |<-------------->| | | 274 | | | | 275 | REGISTER F2 | | 276 |-------------------------------->| | 277 | | | | 278 | | F3 | | 279 | |<-------------->| | 280 | | | REGISTER F4 | 281 | | |--------------->| 282 | | | | 283 | | | 200 (OK) F5 | 284 | | |<---------------| 285 | 200 (OK) F6 | | 286 |<--------------------------------| | 287 | | | | 289 F1 WIC <-> WWSF/WAF 290 The WWSF/WAF authenticates Alice, using "web credentials" 291 (e.g. username and password), and obtains an access 292 token. The access token and the WIC (typically a JavaScript 293 application) is provided to Alice. 295 F2 REGISTER WIC -> eP-CSCF 296 REGISTER sip:registrar.home1.net SIP/2.0 297 Authorization: Bearer access_token="O91G451HZ0V......" 299 F3 eP-CSCF <-> WWSF/WAF 300 The eP-CSCF validates the access token with the WAF, 301 and obtains IMS credentials associated with the user, 302 and a string value representing the identity of the WAF. 304 F4 REGISTER eP-CSCF -> S-CSCF 305 REGISTER sip:registrar.home1.net SIP/2.0 306 Authorization: Digest username="user1_private@home1.net", 307 realm="registrar.home1.net", 308 nonce="", 309 uri="sip:registrar.home1.net", 310 response="", 311 authorization-entity="webrtc_authserver1@thirdparty.net" 313 F5 200 OK S-CSCF -> eP-CSCF 314 200 OK 316 F6 200 OK eP-CSCF -> WIC 317 200 OK 319 Figure 1: The UE registers via P-CSCF 321 Author's Address 323 Christer Holmberg 324 Ericsson 325 Hirsalantie 11 326 Jorvas 02420 327 Finland 329 Email: christer.holmberg@ericsson.com