EMU Working Group S. McCann Internet Draft Research in Motion Intended status: Proposed Standard M. Montemurro Expires: April 19, 2010 Research in Motion October 19, 2009 Session Policy Framework using EAP draft-mccann-session-policy-framework-using-eap-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 19, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 channel exchange with a network McCann Expires April 19, 2010 [Page 1] Internet-Draft EAP Session Policy October 2009 component and obtain session policies using a XML session policy structure, encapsulated within an EAP TLV message. EAP Re-authentication Protocol is suggested as a mechanism to allow asynchronous use of SIP at upper layers. Table of Contents 1. Introduction.......................................................3 1.1. Requirements Notation..........................................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......................5 4. Session policy channel.............................................5 4.1. Session Policy Documents.......................................7 4.1.1. Network Triggered Policy Change............................7 5. Architecture Considerations........................................7 5.1. Session Policy Exchange (SPE)..................................7 5.1.1. Session Policy Channel Initialization......................8 5.1.2. Session Establishment (Mobile Device Triggered)............8 5.1.3. Session Establishment (Network Triggered).................10 6. Encapsulation of SPEs.............................................11 6.1. Encapsulation within an TLV...................................11 6.2. Encapsulation within a Diameter AVP...........................12 6.2.1. Session Policy Exchange AVP...............................12 6.2.2. Session Policy Change Event AVP...........................13 7. AAA URIs..........................................................14 8. Use with SIP......................................................14 9. Security Considerations...........................................15 10. IANA Considerations..............................................15 10.1. Registration of EAP Session Policy TLV.......................15 10.2. Registration of Diameter Session Policy AVP..................15 11. References.......................................................16 11.1. Normative References.........................................16 11.2. Informative References.......................................16 12. Specific Transport Mechanism.....................................17 13. Acknowledgments..................................................17 14. Authors' Addresses...............................................17 McCann Expires April 19, 2010 [Page 2] Internet-Draft EAP Session Policy October 2009 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 (SDP) negotiation during SIP session establishment and modification. This document specifies an alternative policy channel mechanism, utilizing EAP to transport the policy channel protocol between the mobile device and an INC, to obtain session policies, primarily for bandwidth constrained networks. 1.1. Requirements Notation 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 RFC-2119. 2. Terminology 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 Initial Network Component (INC) = Authenticator = PDG (Packet Data Gateway) In addition, this document uses the following terms: ERP - EAP re-authentication Protocol IMS - IP Multimedia Subsystem PCC - Policy Control and Charging PCRF - Policy Control and Charging Rules Function SDP - Session Description Protocol SIP - Session Initiation Protocol SPE - Session Policy Exchange McCann Expires April 19, 2010 [Page 3] Internet-Draft EAP Session Policy October 2009 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 PCCs. 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 the network. 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. IMS was originally developed for 3GPP GSM and UMTS cellular networks but has also been adopted by 3GPP2, TISPAN, and Cablelabs as the next generation network for CDMA cellular networks, fixed line DSL networks and DOCSIS cable networks. In addition other wireless technologies such as IEEE 802.11 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) that performs the necessary Authorization and Accounting functions for mobile device access to IMS bearer resources. The PCC architecture includes a Policy Server, the PCRF (Policy Control and Charging Rules function) 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). As the separate entities 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 1. IMS PCCs use Diameter or RADIUS and EAP already operates over these networks without requiring an upgrade. McCann Expires April 19, 2010 [Page 4] Internet-Draft EAP Session Policy October 2009 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 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 networks while being more suited for use by SIP mobile devices in these bandwidth constrained networks. McCann Expires April 19, 2010 [Page 5] Internet-Draft EAP Session Policy October 2009 domain 1 +-----------+ .------| proxy |----... +--------+ / +-----------+ | |---' +-----------+ | | | PCC | | mobile |============| | | device | +-----------+ | |**** +-----------+ +--------+ * | policy | *******|enforcement|****... +-----------+ --- EAP Signaling === Session Policy Channel *** Media Figure 1 - Session Policy Architecture Figure 1 illustrates a system in which session offer/answer (policy) exchanges (SPE) can be sent by encapsulating the messages within EAP and a suitable AAA protocol (see below). A mobile device connects to an initial network component - INC (e.g. a gateway, an access point, a network access server, or another component with substantially equivalent capabilities). In the process of authenticating the mobile device, a lower layer communication path (session policy channel) is created between the mobile device and the PCC, via the INC. The mobile device sends the SPE containing the session policy offer information and possibly the intended SDP answer information to the INC using a session policy generic message (section 6.16.1. ) encapsulated within an EAP TLV message. Although only one PCC is shown in Figure 1, multiple PCCs could be present. The INC forwards the SPEs to the PCC encapsulated within a Diameter AVP (or some other lower layer protocol with similar capabilities.) In response the SPEs deliver the resulting session policy documents from the PCC back to the mobile device. McCann Expires April 19, 2010 [Page 6] Internet-Draft EAP Session Policy October 2009 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] and [I-D.ietf-sipping-media- policy-dataset]. The mobile device gains access to the PCC to obtain the session policy documents based on a URI (Uniform Resource Indicator) provided in the SPE 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 PCC 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 then re-start a new SPE, which re-negotiates the session policy. 5. Architecture Considerations The SPEs are access network agnostic. The mobile device connects to the INC via one or more of several different wireless or wired communication technologies. Since these architectures typically rely on Diameter-based or RADIUS-based PCCs, the mobile device can submit SPEs to the INC, regardless of which access networks the mobile device uses to finally connect to the network. 5.1. Session Policy Exchange (SPE) The mobile device sends a SPE to the INC using a tunneled EAP protocol (e.g. using EAP-FAST or EAP-TTLS), so that the exchange is secure within an authenticated outer tunnel. From this INC, together with the appropriate AAA servers (such as PCCs using RADIUS and Diameter), the SPEs can traverse many other network components and cross domains. This potentially enables a PCC at the edge of the network (subject to service agreements) to communicate with other PCCs in other domains in order to supply a composite policy document reflecting the policies from multiple domains that the SIP signaling request traverses. Thus the mobile device can potentially obtain a single policy document that reflects the session policies of all the impacted domains in a SPE instead of having to contact multiple PCCs. McCann Expires April 19, 2010 [Page 7] Internet-Draft EAP Session Policy October 2009 5.1.1. Session Policy Channel Initialization The following message flow illustrates how a mobile device initiates the session policy channel. This call flow example and those below are informative and not normative. Implementers should consult the main text of this document for exact protocol details. Mobile Device INC AAAv(PCCv) AAAh(PCCh) | | | | |(1) EAP Method Exchange (tunnel initialization) | |<----------------->|<------------------------------------->| | | | | |(2) [SIP registration with PCCh] | | |<--------------------------------------------------------->| | | | | Figure 2 - EAP Tunnel Initialization Message Details: (1) EAP Method Exchange (tunnel initialization) An EAP exchange is performed between the mobile device and the local INC (Packet Data Gateway) with the authentication messages being forwarded to the home network AAA server. 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 PCCh] Although not a part of the layer 2 exchange, it is worth showing that SIP registration between the mobile device and the PCCh (home PCC) occurs at this point. Subsequent SIP level flows are not shown. 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. McCann Expires April 19, 2010 [Page 8] Internet-Draft EAP Session Policy October 2009 Mobile Device INC AAAv(PCCv) AAAh(PCCh) | | | | |(3) EAP-Initiate/Re-auth-Start | | |<----------------->|<------------------------------------->| | | | | |(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-Start An ERP exchange is performed between the mobile device and the INC (Packet Data Gateway) with the authentication messages being forwarded to the home AAA server. (4) EAP tunnel(Policy Request) The policy request message is then transported within the EAP tunnel (using the TLV - 6.1 - with an inner EAP method) to the INC, and then forwarded (using Diameter) to the PCCh. (5) Policy-h At the home AAA server, the home network policy is determined for subsequent SIP sessions. (6) AAA (Policy Request) McCann Expires April 19, 2010 [Page 9] Internet-Draft EAP Session Policy October 2009 The home AAA server, then requests policy information from all visited networks PCCs, through which the SIP session will traverse, utilizing a AAA Policy Request message. (7) AAA (Policy Response) Each visited PCC will then return its network policy back to the home network, where the session policy document is compiled. (8) EAP tunnel(Policy Response) The session policy document is returned to the INC and is then 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 INC AAAv(PCCv) AAAh(PCCh) | | | | | | (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 April 19, 2010 [Page 10] Internet-Draft EAP Session Policy October 2009 A visited PCC changes the session policy (most likely whilst the mobile device session is on-going) and indicates to the home nework server that a policy change has occurred. (10) AAA (Policy Change Event) The home network server, sends an Event message to the INC (most likely within Diameter) (11) EAP Initiate/Re-auth-Start The INC then 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 structure of the SPE is defined as XML, based on the session policy XML Schema in {ref}. In summary 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. For over the air between the mobile device and the INC, the SPE is encapsulated within an EAP TLV messages and then within a RADIUS/Diameter AVP message for the onward network traversal. 6.1. Encapsulation within an TLV The type-length-value (TLV) structure, may be used to transport the SPE from the mobile device to an INC. The use of a tunneled EAP method will provide the required level of security protection. The EAP 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)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ McCann Expires April 19, 2010 [Page 11] Internet-Draft EAP Session Policy October 2009 Flags M 0 - Optional TLV R Reserved, set to zero (0) TLV Type (The "Type" may also be used to route the EAP content) 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 Exchange] 6.2. Encapsulation within a Diameter 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 from the INC (e.g. Packet Data Gateway) to the home network server and vice- versa. 6.2.1. Session Policy Exchange AVP The structure to transport the SPE from the INC (e.g. INC) to the home network server 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)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ McCann Expires April 19, 2010 [Page 12] Internet-Draft EAP Session Policy October 2009 AVP Code 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 home network server to the INC (e.g. INC) to the home network server 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 McCann Expires April 19, 2010 [Page 13] Internet-Draft EAP Session Policy October 2009 M 0 - Optional AVP P 0 - End to end encryption is not required AVP Length >=0 Session Policy Change Event This is a message which indicates to the INC, that the session policy within the network has changed. It triggers the INC to send an EAP-Initiate to the mobile device, request that a further SPE be re- started. (Note: Work in DIME [I-D.ietf-dime-erp] may already support this message type.) 7. AAA URIs For 3GPP PCC, or similar AAA infrastructure, AAA URIs are provided in the Policy-Contact header. As per RFC 3588 the following are examples of valid Diameter or RADIUS host identities: aaa://host.example.com aaa://host.example.com:6666 and additionally a secure version can also be used: aaas://host.example.com These are also valid identities for the 3GPP PCC architecture (based on Diameter) as it supports inter-domain communication between PCCs. 8. 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 McCann Expires April 19, 2010 [Page 14] Internet-Draft EAP Session Policy October 2009 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]. 9. Security Considerations Session policies can significantly change the behavior of a user agent and can be used by an attacker to compromise a user agent. 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. It's assumed that the EAP TLV frame is transmitted within an authenticated tunnel using a suitable EAP method (e.g. EAP-FAST or EAP-TTLS) If the EAP method (such as EAP-SIM and EAP-AKA) used for authentication is compliant with the EAP Keying Framework (RFC 5247), a MIC can be used to protect the session policy request/response against forgery and replay attacks. Alternatively, the session policy request/response could be protected with a shared key. 10. IANA Considerations 10.1. Registration of EAP Session Policy TLV Name of Header Field: TLV Type Short form: none Normative description: Section 6.1 of this document 10.2. Registration of Diameter Session Policy AVP Name of Header Field: AVP Code Short form: none Normative description: Section 6.2 of this document McCann Expires April 19, 2010 [Page 15] Internet-Draft EAP Session Policy October 2009 11. References 11.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-05 (work in progress), November 2008. [I-D.ietf-sipping-config-framework] Channabasappa, S., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-15 (work in progress), February 2008. [I-D.ietf-sipping-media-policy-dataset] Hilt, V., "A User Agent Profile Data Set for Media Policy", March 2009 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5296] Narayanan, V., "EAP Extensions for EAP Re-authentication Protocol (ERP)", August 2008 11.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 [RFC3588] Calhoun, P. et al, "Diameter Base Protocol", September 2003 [RFC5247] Aboba, B. et al, "Extensible Authentication Protocol (EAP) Key Management Framework", August 2008 [I-D.ietf-dime-erp] Bournelle, J. et al, "Diameter support for EAP Re- authentication Protocol (ERP)", draft-ietf-dime-erp-02 (work in progress), October 2009 McCann Expires April 19, 2010 [Page 16] Internet-Draft EAP Session Policy October 2009 12. Specific Transport Mechanism More specifically, one or more EAP frames might be transported over an IP-CAN (IP (Internet Protocol) Connectivity Access Network) via IKEv2 (Internet Key Exchange version 2) over IP per RFC 5108 between the mobile device and the INC. Alternatively, other transport protocols could be used, such as transporting EAP over PPP (Point-to- Point Protocol) as per RFC 2284, wired IEEE 802 LANs (IEEE-802.1X), IEEE 802.11 wireless LANs (IEEE-802.11), UDP (L2TP [RFC2661] and IKEv2 [IKEv2]), and TCP (PIC). In any of these transport protocols, messages are sent at a lower protocol layer than the SIP messages themselves, which are typically sent at the application layer. 13. 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. 14. 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 April 19, 2010 [Page 17]