EMU Working Group S. McCann Internet Draft Research in Motion Intended status: Standards Track M. Montemurro Expires: January 9, 2013 Research in Motion July 9, 2012 Session Policy Framework using EAP draft-mccann-session-policy-framework-using-eap-06.txt Abstract This document specifies a framework for implementing a session policy channel using EAP. It defines a standard mechanism by which a mobile device can conduct a session policy exchange with a policy network component, using EAP as a lower layer protocol, to obtain session policies. EAP Re-authentication Protocol is suggested as a mechanism to allow asynchronous use of SIP at upper layers. 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 January 9, 2013. Copyright Notice Copyright (c) 2012 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 McCann Expires January 9, 2013 [Page 1] Internet-Draft Session Policy Framework using EAP July 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction ..................................................... 3 2. Terminology ...................................................... 3 3. Session Policy ................................................... 4 3.1. SIP background ............................................... 4 3.2. 3GPP IMS ..................................................... 4 3.3. Management of Asynchronous Session Events .................... 6 4. Session policy channel ........................................... 6 4.1. Session Policy Documents ..................................... 7 4.1.1. Network Triggered Policy Change .......................... 8 5. Architecture Considerations ...................................... 8 5.1. Session Policy Exchange (SPE) ................................ 8 5.1.1. Session Policy Channel Initialization .................... 9 5.1.2. Session Establishment (Mobile Device Triggered) ......... 10 5.1.3. Session Establishment (Network Triggered) ............... 11 6. Encapsulation of SPEs ........................................... 12 6.1. Encapsulation within an TLV ................................. 12 6.2. Encapsulation within an AVP ................................. 13 6.2.1. Session Policy Exchange AVP ............................. 13 6.2.2. Session Policy Change Event AVP ......................... 14 7. Use with SIP .................................................... 15 8. Security Considerations ......................................... 15 9. IANA Considerations ............................................. 15 McCann Expires January 9, 2013 [Page 2] Internet-Draft Session Policy Framework using EAP July 2012 9.1. Registration of EAP Session Policy TLV ...................... 15 9.2. Registration of Diameter Session Policy AVP ................. 16 10. References ..................................................... 16 10.1. Normative References ....................................... 16 10.2. Informative References ..................................... 16 11. Specific Transport Mechanism ................................... 16 12. Acknowledgments ................................................ 17 13. Authors' Addresses ............................................. 17 1. Introduction The Session Initiation Protocol (SIP) [RFC 3261] is an application- layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions can include VoIP (Voice over IP) telephone calls, and multimedia conferences. Service providers may have policies that apply to the media types negotiated for SIP sessions and hence it is necessary for proxy servers to be able to influence the Session Description Protocol negotiation during SIP session establishment and modification. This document specifies an alternative policy channel mechanism, enabling a user agent (i.e. a mobile device) to send session policy requests to a policy network component (e.g. a policy server) using a lower layer protocol (e.g. EAP and PPP), to obtain session policies, primarily for bandwidth constrained networks. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119]. A mixture of both EAP and SIP terminology is used within this document, with the following equivalence: EAP client = SIP user agent (UA) = Mobile Device EAP peer = Home Network Server = AAAh Authenticator = Intermediate Component (IC) = Gateway In addition, this document uses the following terms: ERP - EAP re-authentication Protocol McCann Expires January 9, 2013 [Page 3] Internet-Draft Session Policy Framework using EAP July 2012 IMS - IP Multimedia Subsystem PCC - Policy Control and Charging PNC - Policy Network Component PNCh - Home PNC PNCv - Visited PNC SDP - Session Description Protocol SIP - Session Initiation Protocol SPE - Session Policy Exchange (i.e. session policy request and response) 3. Session Policy 3.1. SIP background Using SIP for the policy channel provides a good general purpose solution for the internet being independent of the underlying policy and network architecture and ensures that all SIP user agents (mobile devices) can interact with any PNC. However, for limited bandwidth access networks, such as cellular systems, the SIP Events framework [RFC 3265] is an inefficient realization of the policy channel. With limited bandwidth access networks the large SIP messages take a significant amount of time to be transported between the mobile device and a PNC. 3.2. 3GPP IMS 3GPP has defined IMS as a next generation network architecture for establishing IP multimedia sessions including services such as multimedia telephony. Although originally developed for cellular networks, other technologies such as fixed line DSL networks and DOCSIS cable networks together with wireless technologies such as WLAN and WIMAX can be used to access IMS networks and work is currently in progress to use IMS for SIP based enterprise access and interconnect. 3GPP has defined an architecture for Policy Control and Charging (PCC), realized by PNCs, that performs the necessary Authorization and Accounting functions for mobile device access to IMS bearer resources. Typical PNCs are policy servers, entities with "Policy Control and Charging Rules Function" or "Policy Control and Enforcement Functions", which based on inputs from various sources, determines which mobile devices are allowed bearer access based on the attributes and characteristics of the session (such as the number of streams, the media types, and the codecs). Within these architectures, IMS PNCs are usually co-located with the AAA, so network paths are already established. McCann Expires January 9, 2013 [Page 4] Internet-Draft Session Policy Framework using EAP July 2012 McCann Expires January 9, 2013 [Page 5] Internet-Draft Session Policy Framework using EAP July 2012 As the separate PNCs within the PCC communicate using the Diameter or RADIUS protocol it is quite appropriate that a mature authentication protocol be considered for session policy establishment, operating within a Diameter and RADIUS AAA server regime. EAP is a good candidate because it allows a mobile device to communicate with AAA infrastructure. Its advantages are: 1. IMS PNCs use Diameter or RADIUS and EAP already operates over these networks without requiring an upgrade. 2. EAP is already implemented or will be implemented in many mobile terminals since EAP is specified for use by mobile terminals for authentication when using WLAN access. 3. EAP is access independent and compatible for use with all the access networks and policy control architectures of the current IMS stakeholders. 4. EAP is a lightweight protocol that is efficient for transport over bandwidth constrained access networks with minimal round trip delay and power consumption. 3.3. Management of Asynchronous Session Events Although EAP does show some advantages, it is primarily designed to be an authentication mechanism, which establishes a security association (SA), prior to any application session being considered. In this respect EAP exchanges are expected to occur once a wireless connection has been made, as opposed to every time a SIP session wishes to commence. However, using the EAP Re-authentication Protocol [RFC5296], it is possible to re-establish an EAP method independent tunnel, with a similar security association to that of the initial EAP exchange. It supports EAP re-authentication for a mobile device (i.e. the EAP peer) that has valid, unexpired key material from a previously performed EAP authentication In this manner, ERP can be utilized every time the mobile device wishes to initialize a SIP session. 4. Session policy channel An EAP based session policy channel is an alternative mechanism for implementing the policy channel defined in [I-D.ietf-sip-session- policy-framework] that builds upon the capabilities that exist in IMS McCann Expires January 9, 2013 [Page 6] Internet-Draft Session Policy Framework using EAP July 2012 networks while being more suited for use by SIP mobile devices in these bandwidth constrained networks. domain 1 +-----------+ .------| proxy |----... +--------+ / +-----------+ | |---' +-----------+ | | | PNC | | mobile |============| | | device | +-----------+ | |**** +-----------+ +--------+ * | policy | *******|enforcement|****... +-----------+ --- EAP Signaling === Session Policy Channel *** Media Figure 1 - Session Policy Architecture Figure 1 illustrates a system in which SPEs are sent by encapsulating the messages within EAP. In the process of authenticating the mobile device, a lower layer communication path (equivalent to a session policy channel) is created between the mobile device and the PNC. The mobile device sends the session policy request to a PNC using a generic message (section 6.1. ) encapsulated within an EAP TLV message [I-D.draft-cam-winget-eap-tlv]. The session policy response sends the resulting session policy documents from the PNC back to the mobile device. Although only one PNC is shown in Figure 1, multiple PNCs could be present in the system. 4.1. Session Policy Documents Session policy documents are typically the info offer, info answer , policy offer and policy answer, which define policy as stated in [I- D.ietf-sip-session-policy-framework]. These documents are carried within the SPE messages as shown in section 6. McCann Expires January 9, 2013 [Page 7] Internet-Draft Session Policy Framework using EAP July 2012 The mobile device gains access to the PNC to obtain the session policy documents based on a URI (Uniform Resource Indicator) provided in the SPE message header. 4.1.1. Network Triggered Policy Change For session-dependent policies, if the session policies change during a session (because of a change in the available radio resources, for example due to congestion or change of access network type), the PNC sends a modified session policy document (Figure 4) to the mobile device to inform it that the policies have changed so that the mobile device can re-start a new SPE, which re-negotiates the session policy. 5. Architecture Considerations The SPEs are access network agnostic. The SPE passes through an IC (e.g. gateway, access point, network access server) between the mobile device and the PNC. The mobile device connects to an IC via one or more of several different wired (e.g. DSL networks and DOCSIS) or wireless (e.g. WLAN and WiMAX) access network technologies. Essentially a lower layer protocol (e.g. a wired or wireless protocol together with EAP) is used for transporting the session policy request between the mobile device and the IC, and then another lower layer protocol (e.g. RADIUS or Diameter together with EAP) transports the session policy request between the IC and the PNC. Since these architectures typically rely on Diameter or RADIUS based PNCs, the mobile device can transmit SPEs to the PCN, regardless of which access networks the mobile device uses to finally connect to the network. 5.1. Session Policy Exchange (SPE) From a single PNC, together with the appropriate AAA servers (such as other PNCs), the SPEs can traverse many other network components and cross domains. This potentially enables a PNC at the edge of the network (subject to service agreements) to communicate with other PNCs in other domains in order to supply a composite policy document reflecting the policies from multiple domains that the SIP signaling request traverses. The mobile device can contact many PNCs via a single SPE with its home PNC (PNCh). The PNCh contacts other visited PNCs (PNCv) and returns their policy documents back to the PNCh where they are McCann Expires January 9, 2013 [Page 8] Internet-Draft Session Policy Framework using EAP July 2012 aggregated before returning that aggregated policy information to the mobile device. Thus the mobile device can potentially obtain a single policy document that reflects the session policies of all the impacted domains in a single SPE instead of having to contact multiple PNCs individually. As the mobile device transmits a session policy request to the PNC using a tunneled EAP protocol (e.g. using EAP-FAST or EAP-TTLS), the SPE is secure within an authenticated outer tunnel. 5.1.1. Session Policy Channel Initialization The following message flow illustrates how a mobile device initiates the session policy channel. Mobile Device IC AAAv(PNCv) AAAh(PNCh) | | | | |(1) EAP Method Exchange (tunnel initialization) | |<----------------->|<------------------------------------->| | | | | |(2) [SIP registration with PNCh] | | |<--------------------------------------------------------->| | | | | Figure 2 - EAP Tunnel Initialization Message Details: (1) EAP Method Exchange (tunnel initialization) An EAP exchange is performed between the mobile device and the PNC with the authentication messages being forwarded to the home network AAA server. It is assumed that the PNCh is co-located with the AAAh. A suitable EAP method is used to establish a tunnel (e.g. EAP-FAST), from which the relevant ERP keys are derived for subsequent use [RFC5296]. (2) [SIP registration with PNCh] Although not a part of the layer 2 exchange, it is worth showing that SIP registration between the mobile device and the PNCh occurs at this point. Subsequent SIP level flows are not shown. McCann Expires January 9, 2013 [Page 9] Internet-Draft Session Policy Framework using EAP July 2012 5.1.2. Session Establishment (Mobile Device Triggered) The following message flow illustrates how a mobile device initiates a session policy using a re-established EAP tunnel. This is a result of a mobile device triggered event. Mobile Device IC AAAv(PNCv) AAAh(PNCh) | | | | |(3) EAP-Initiate/Re-auth | | |---------------------------------------------------------->| | | | | |(4) EAP tunnel(Policy Request) | | |<--------------------------------------------------------->| | | | | | | | (5)Policy-h |--- | | | | | | | | |<-- | | (6)AAA (Policy Request) | | | |<------------------| | | | | | | (7)AAA (Policy Response) | | | |------------------>| | | | | |(8) EAP tunnel(Policy Response) | | |<----------------------------------------------------------| | | | | Figure 3 - Mobile Device Triggered Session Policy Request Message Details: (3) EAP-Initiate/Re-auth The ERP exchange is performed between the mobile device and the home AAA (PNCh). (4) EAP tunnel(Policy Request) The session policy request is transported within the EAP tunnel (using EAP TLV - 6.1) to the PNCh. (5) Policy-h At the home AAA server, the home network policy is determined for subsequent SIP sessions. (6) AAA (Policy Request) McCann Expires January 9, 2013 [Page 10] Internet-Draft Session Policy Framework using EAP July 2012 The home AAA server, requests policy information from all visited networks PNCs, through which the SIP session will traverse, utilizing an AAA Policy Request message (typically using RADIUS or Diameter.) (7) AAA (Policy Response) Each visited PNC will return its network policy back to the home network, where the session policy document is aggregated. (8) EAP tunnel(Policy Response) The session policy document is encapsulated within the EAP TLV, before being returned to the mobile device. 5.1.3. Session Establishment (Network Triggered) The following message flow illustrates how a network initiates a session policy re-establishment. This is a result of a network triggered event. Mobile Device IC AAAv(PNCv) AAAh(PNCh) | | | | | | (9)AAA(Policy Change) | | | |------------------>| | | | | (11) EAP Initiate/Re-auth-Start (10)AAA(Policy Change Event)| |<------------------|<--------------------------------------| | | | |(3) EAP re-establish Tunnel(Channel Bindings) | |<--------------------------------------------------------->| | | | | |(4) EAP tunnel(Policy Request) | | |---------------------------------------------------------->| | | | | |(8) EAP tunnel(Policy Response) | | |<----------------------------------------------------------| | | | | Figure 4 - Network Triggered Session Policy Request Message Details: (9) AAA (Policy Change) McCann Expires January 9, 2013 [Page 11] Internet-Draft Session Policy Framework using EAP July 2012 A visited PNC changes the session policy (most likely whilst the mobile device session is on-going) and indicates to the PNCh that a policy change has occurred. (10) AAA (Policy Change Event) The PNCh sends a policy change event message to the IC (most likely within RADIUS or Diameter) (11) EAP Initiate/Re-auth-Start The IC requests the mobile device to execute the ERP. The rest of the message flow continues, as described above in section 5.1.2. 6. Encapsulation of SPEs The SPE comprises identification, routing and session policy documents, which allows the policy information to be generated (typically within the session policy documents themselves), as the SPEs traverse the network. The SPE is encapsulated within an EAP type-length-value (TLV) structure between the mobile device and the PCNh and within a RADIUS/Diameter AVP message for the onward network traversal between the PCNh and PCNv(s). 6.1. Encapsulation within an TLV [I-D.draft-cam-winget-eap-tlv] explains how type-length-value (TLV) structures, may be used to transport the SPE from the mobile device to a PNC within a secure tunnel. The SPE TLV is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Policy Exchange (SPE)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags M McCann Expires January 9, 2013 [Page 12] Internet-Draft Session Policy Framework using EAP July 2012 0 - Optional TLV R Reserved, set to zero (0) TLV Type Length >=0 Session Policy Exchange This is the Session Policy Exchange (SPE) as defined in section 5.1. The following is an example of such a message from the network to the mobile device: EAP Code: 2 (Response) Type: SessionPolicy Length: Variable Value: [Session Policy Request] 6.2. Encapsulation within an AVP The attribute-value-pair (AVP) structure, may be used to transport the 2 new required AAA messages as defined in section 5.1.2 6.2.1. Session Policy Exchange AVP The structure to transport the SPE from the PNCh to various PNCv(s) is defined as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M P r r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Policy Exchange (SPE)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code McCann Expires January 9, 2013 [Page 13] Internet-Draft Session Policy Framework using EAP July 2012 Flags V 0 - Not a vendor specific AVP M 0 - Optional AVP P 0 - End to end encryption is not required AVP Length >=0 Session Policy Exchange (SPE) This is the Session Policy Exchange as defined in section 5.1 6.2.2. Session Policy Change Event AVP The structure to transport the session change event from the PNCh to the IC is defined as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M P r r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Policy Change Event... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code Flags V 0 - Not a vendor specific AVP M 0 - Optional AVP P 0 - End to end encryption is not required McCann Expires January 9, 2013 [Page 14] Internet-Draft Session Policy Framework using EAP July 2012 AVP Length >=0 Session Policy Change Event This is a message which indicates to the IC, that the session policy within the network has changed. It triggers the IC to send an EAP-Initiate to the mobile device, requesting that a further SPE be re-started. 7. Use with SIP The EAP mechanisms described above can be used by the mobile device for obtaining both session-independent policies and session-specific policies, as defined in [I-D.ietf-sip-session-policy-framework]. The above discussion focuses on obtaining session-specific polices, but the mechanisms can also be used by the mobile device prior to session establishment to obtain session-independent policies. In addition to media policies, the mechanisms defined herein can be used to inform the mobile device to use a different IP address in the SDP Offer or Answer, to navigate firewalls or NATs, or to route media via a transcoder or other media relay as defined in [I-D.ietf-sip- session-policy-framework]. 8. Security Considerations Session policies can significantly change the behavior of a mobile device and can be used by an attacker to compromise such a device. For example, session policies can be used to prevent a mobile device from successfully establishing a session (e.g., by setting the available bandwidth to zero). Such a policy can be submitted to the mobile device during a session, which causes the mobile device to terminate the session. For transmissions over the air, [I-D. draft-cam-winget-eap-tlv] assures that the SPE (encapsulated within an EAP TLV) is transmitted within an authenticated tunnel using a suitable EAP method (e.g. EAP- FAST or EAP-TTLS) 9. IANA Considerations 9.1. Registration of EAP Session Policy TLV Name of Header Field: TLV Type Short form: none McCann Expires January 9, 2013 [Page 15] Internet-Draft Session Policy Framework using EAP July 2012 Normative description: Section 6.1 of this document 9.2. Registration of Diameter Session Policy AVP Name of Header Field: AVP Code Short form: none Normative description: Section 6.2 of this document 10. References 10.1. Normative References [I-D.ietf-sip-session-policy-framework] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for Session Initiation Protocol (SIP) Session Policies", draft-ietf-sip-session-policy-framework-10 (work in progress), Feburary 2011. [I-D.draft-cam-winget-eap-tlv] Cam-Winget, N.,Zhou, H., McCann, S., "EAP Type-Length-Value Container", draft-cam-winget-eap-tlv-02 (work in progress) , January 2011 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B. et al, "Extensible Authentication Protocol (EAP)", June 2004 [RFC5296] Narayanan, V., "EAP Extensions for EAP Re-authentication Protocol (ERP)", August 2008 10.2. Informative References [RFC3261] Rosenberg, J. et al, "SIP: Session Initiation Protocol", June 2002 [RFC3265] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", June 2002 11. Specific Transport Mechanism The following specific transport mechanisms could be considered for transporting EAP session policy information: McCann Expires January 9, 2013 [Page 16] Internet-Draft Session Policy Framework using EAP July 2012 . IP-CAN (IP (Internet Protocol) Connectivity Access Network) via IKEv2 (Internet Key Exchange version 2) as per RFC 5269. . PPP (Point-to-Point Protocol) as per RFC 2284. . wired IEEE 802 LANs (IEEE-802.1X). . IEEE 802.11 wireless LANs (IEEE-802.11). Using any of these transport protocols, EAP messages are sent at a lower protocol layer than the SIP messages themselves, which are typically sent at the application layer. 12. Acknowledgments The authors would like to acknowledge Andrew Allen and Nancy Cam- Winget for their contributions to this document. This document was prepared using 2-Word-v2.0.template.dot. 13. Authors' Addresses Stephen McCann Research in Motion 200 Bath Road Slough Berkshire, SL1 3XE, UK Email: smccann@rim.com Mike Montemurro Research in Motion Mississauga Ontario, Canada Email: mmontemurro@rim.com McCann Expires January 9, 2013 [Page 17]