Internet DRAFT - draft-holmberg-sipcore-auth-id
draft-holmberg-sipcore-auth-id
Network Working Group C. Holmberg
Internet-Draft Ericsson
Intended status: Standards Track May 28, 2015
Expires: November 29, 2015
Authorization server identity
draft-holmberg-sipcore-auth-id-01.txt
Abstract
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
obtain 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 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.
Status of This Memo
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 http://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 November 29, 2015.
Holmberg Expires November 29, 2015 [Page 1]
Internet-Draft Authorization server identity May 2015
Copyright Notice
Copyright (c) 2015 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
(http://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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. 'authorization-entity' header field parameter . . . . . . . . 4
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 4
5.2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 5
10. Normative References . . . . . . . . . . . . . . . . . . . . 5
Appendix A. 3GPP Examples . . . . . . . . . . . . . . . . . . . 6
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
A.2. WIC registration using web credentials . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
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
obtain 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 [RFC5234] is used
between the WIC and the eP-CSCF, together with the OAuth 2.0
framework [RFC6749], the access token will be conveyed in the
Holmberg Expires November 29, 2015 [Page 2]
Internet-Draft Authorization server identity May 2015
REGISTER request using the mechanism defined in
[I-D.yusef-sipcore-sip-oauth].
The WWSF (OAuth 2.0 Client role) authenticates the user (OAuth 2.0
Resource Owner role), and obtains the token from the 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 [RFC3261] is used) towards the IMS network
(OAuth 2.0 Resource Server role).
When the eP-CSCF receives the registration request, it contacts the
WAF 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.
2. Abbreviations
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): obtains 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.
Holmberg Expires November 29, 2015 [Page 3]
Internet-Draft Authorization server identity May 2015
eP-CSCF (P-CSCF enhanced for WebRTC): A SIP proxy which validates the
access token, and obtains IMS credentials associated with the access
token. In the OAuth 2.0 architecture the eP-CSCF represents verifies
the access token on behalf of the Resource Server.
S-CSCF (Serving CSCF): IMS SIP registrar.
3. Requirements
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.
4. Conventions
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].
5. 'authorization-entity' header field parameter
5.1. General
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.
5.2. Syntax
5.2.1. General
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 [RFC5234].
5.2.2. ABNF
The ABNF [RFC5234] grammar for the 'authorization-entity' header
field parameter is:
Holmberg Expires November 29, 2015 [Page 4]
Internet-Draft Authorization server identity May 2015
dig-resp /= "authorization-entity" EQUAL quoted-string
;; quoted-string defined in RFC 3261
6. Security Considerations
Security considerations come here.
7. IANA Considerations
[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 [RFC3969].
Header Field: Authorization
Parameter Name: authorization-entity
Predefined Values: No
Reference: RFCXXXX
8. Acknowledgments
The author wishes to thank everyone in the 3GPP community that
provided input and comments on this document.
9. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing]
draft-holmberg-sipcore-auth-id-xx
o
draft-holmberg-sipcore-auth-id-00
o Editorial changes/corrections.
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Holmberg Expires November 29, 2015 [Page 5]
Internet-Draft Authorization server identity May 2015
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Uniform Resource Identifier (URI) Parameter
Registry for the Session Initiation Protocol (SIP)", BCP
99, RFC 3969, December 2004.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
6749, October 2012.
[I-D.yusef-sipcore-sip-oauth]
Shekh-Yusef, R. and V. Pascual, "The Session Initiation
Protocol (SIP) OAuth", draft-yusef-sipcore-sip-oauth-02
(work in progress), April 2015.
Appendix A. 3GPP Examples
A.1. General
This section contains example call flows based on 3GPP usage of the
authorization-entity header field parameter.
A.2. WIC registration using web credentials
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 obtains 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.
Alice/WIC WWSF/WAF eP-CSCF S-CSCF
| | | |
| F1 | | |
|<-------------->| | |
| | | |
| REGISTER F2 | |
|-------------------------------->| |
| | | |
| | F3 | |
Holmberg Expires November 29, 2015 [Page 6]
Internet-Draft Authorization server identity May 2015
| |<-------------->| |
| | | 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 obtains 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
Figure 1: The UE registers via P-CSCF
Holmberg Expires November 29, 2015 [Page 7]
Internet-Draft Authorization server identity May 2015
Author's Address
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Holmberg Expires November 29, 2015 [Page 8]
