Network Working Group D. Wing Internet-Draft Cisco Systems Expires: August 4, 2006 January 31, 2006 Media Session Authorization draft-wing-session-auth-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 August 4, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract In many VoIP networks today, firewalls and session border controllers are used at the edge of an administrative domain to allow authorized UDP media flows to enter or leave the network. This document introduces a new mechanism to authorize a UDP media flow. This mechanism works with encrypted hop-by-hop signaling, end-to-end authenticated signaling, and multihomed networks. The media authorization is performed using an Interactive Connectivity Establishment-capable endpoint and a calling signaling device that authorizes a firewall to permit a flow. Wing Expires August 4, 2006 [Page 1] Internet-Draft Media Session Authorization January 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Push versus Pull Model . . . . . . . . . . . . . . . . . . 6 2. Session Authorization Mechanism . . . . . . . . . . . . . . . 6 3. Session Deauthorization Mechanism . . . . . . . . . . . . . . 10 4. Control Protocol Requirements . . . . . . . . . . . . . . . . 10 5. Minimal Implementation . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informational References . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Wing Expires August 4, 2006 [Page 2] Internet-Draft Media Session Authorization January 2006 1. Introduction Interactive Connectivity Establishment (ICE, [1]) describes a mechanism for traversing NATs. ICE has both peers exchange tokens (STUN Usernames) in order to prevent inadvertent session establishment with a device sharing the same IP address and UDP port as the intended session peer. The mechanism introduced in this document utilizes this normal ICE behavior in order to allow a call processing device (such as a SIP proxy) and a firewall to authorize each UDP media session. Essentially, the call processing device watches the tokens that are exchanged in call signaling, and the same tokens are exchanged in the media path then the media session is authorized. The mechanism does not rely on ICE's NAT traversal technique but takes advantage of the token (STUN Username) exchanged in signaling. The media session authorization described in this document also works on a multihomed network with asymmetric routing through different firewalls. In the following figure the top-most path (through firewall-1) is used for traffic from phone-b to phone-a, and the bottom-most path (through firewall-2) is used for traffic from phone-a to phone-b. +---[firewall-1]<--------+ | | V | [phone-a]--[router] [router]--[phone-b] | ^ | | +--->[firewall-2]--------+ Figure 1: Asymmetric Routing Although SIP is described in this document, any protocol utilizing an offer/answer model ([4] or similar) could utilize the technique described in this document. An example of another such protocol is Jingle [9]. Wing Expires August 4, 2006 [Page 3] Internet-Draft Media Session Authorization January 2006 Multiple disparate applications can authorize a UDP media session, with each application communicating with a common policy server. +---------+ +--------------------+ |SIP Proxy| |XMPP (Jabber) Server| +-----+---+ +-----+--------------+ \ / \ / +-+-----------+-+ | Policy Server | +-+----+------+-+ / | \ / | \ +--+-+ +--+-+ ++----+ |FW-1| |FW-2| ... |FW-nn| +----+ +--+-+ +-----+ Figure 2: Multiple applications authorizing media sessions 1.1. Motivation Two techniques commonly provide ingress/egress security today -- firewall application layer gateways (ALG) and Session Border Controllers (SBC) [5]. In order to perform its security function, the ALG must be able to examine the SIP signaling, whereas an SBC is actively involved with modifying the SIP signaling (specifically the SDP, and often SIP headers as well). However the use of hop-by-hop signaling encryption (such as with TLS) breaks firewall ALGs, and the use of end-to-end signaling encryption (such as S/MIME) or end-to-end integrity protection (such as SIP Identity [3]) breaks SBCs. Additionally both a firewall and an SBC constrain the media path, causing packets to not take the best path. A firewall requires the signaling and media flow through the firewall (which is achieved through network design) and an SBC causes media to flow through the SBC (by modifying SDP in SIP signaling). Two other techniques are less common. An on-path technique to provide ingress/egress security is NSIS NSLP [6]. MIDCOM [7] is an off-path firewall and NAT control protocol which requires topology awareness. Media session authorization can be implemented by one network without needing to be implemented by a remote network. The remote network need only implement ICE -- no extensions to ICE are necessary. This makes deployment of this mechanism easy. Wing Expires August 4, 2006 [Page 4] Internet-Draft Media Session Authorization January 2006 The tradeoffs of media session authorization are summarized in the following table. | FW | | NSIS | | Media Works With | ALG | SBC | NSLP | MIDCOM | Sess Auth -----------------------+------+------+------+--------+---------- TLS signaling | No | Yes | Yes | Yes | Yes S/MIME signaling | No | No | No | No | No/6 existing NATs | No/1 | Yes | No/1 | No/1 | Yes existing firewalls | No/1 | Yes | No/1 | No/1 | No/1 SIP Identity | Yes | No/2 | Yes | Yes | Yes multihomed networks | No | No/3 | Yes | Yes/8 | Yes existing endpoints | Yes | Yes | No/4 | Yes | No/5 UDP media | Yes | Yes | Yes | Yes | Yes TCP media | Yes | Yes | Yes | Yes | No/7 Topology unaware | Yes | Yes | Yes | No | Yes best-path routing | No | No | Yes | Yes | Yes Figure 3: Comparison of Techniques Notes: 1. To be Yes, the Firewall (or NAT) would need to be upgraded to support each traversal type (SIP ALG, MIDCOM, NSIS NSLP). NATs do not provide policy control and work without modification with both media session authorization and with SBCs. SBCs work with existing firewalls by configuring the firewall with a pinhole for the SBC's media address(es) and using the SBC to provide policy control normally attributed to the firewall. 2. To be Yes, the SBC would need to rewrites the From: and creates a new sip-identity signature; this is only possible with E.164 numbers or if the SBC is in the same administrative domain as the From: domain. 3. While it is possible for SBCs to form their own multihomed overlay network, it isn't the same as IP multihoming. 4. Local endpoint must implement NSIS NSLP. If remote endpoint doesn't support NSIS NSLP, NSLP's RESERVE-EXTERNAL-ADDRESS mode is required. 5. To be Yes, both local and remote endpoints must support ICE. 6. S/MIME prevents the local SIP proxies from viewing the endpoint's tokens. To be Yes, the firewall or policy server must be told the endpoint's tokens. 7. Authorizing TCP-based media sessions is under study. 8. Multihomed networks can be supported with sufficient awareness of network topology and routing. Wing Expires August 4, 2006 [Page 5] Internet-Draft Media Session Authorization January 2006 1.2. Push versus Pull Model When separate devices are used for firewalling (policy enforcement) and policy decisions, a 'push' or 'pull' model can be used to communicate between the devices. In the push model, the policy decision device informs the firewall of an authorized flow. In the pull model, the firewall asks the policy decision device if a flow is authorized. The strength of the policy push model is it avoids session authorization delays. The weakness is that it requires topology awareness (need to know which firewalls to inform) or requires informing all firewalls about every authorized flow. The strength of the policy pull model is it allows multihomed networks and doesn't require topology awareness. The weakness is that strict policy enforcement, where authorized flows are permitted and unauthorized flows are denied, incurs some authorization delay. This document describes a pull model. 2. Session Authorization Mechanism The figure below shows a simplified ICE message flow which highlights the characteristics of standard ICE that are useful to build the flow authorization described by this document. As it relates to media session authorization, the key aspect of ICE are the unique, per-call identifiers (transport address id) generated by the calling party and the unique, per-call identifier generated by the called party. These tokens are exchanged in call signaling, and are then exchanged again in the media path in STUN Request messages. In the figure below, Alice and Bob perform normal ICE procedures. Alice generates an offer [4] containing her unique, per-call token ("A:a" in the figure). This token is the 'candidate id' and 'component id' described in ICE. This token is sent to the other party, Bob. Upon receipt of this offer, Bob generates his own token ('candidate id' and 'component id'). These are concatinated with Alice's token, resulting in "A:a:B:b". Bob sends a STUN Request message directly to Alice's IP address. Bob also sends an answer, in call signaling, containing his token ('candidate id' and 'component id'). Alice receives the STUN Request. By parsing the message she determines it contains her token. She response with a STUN Response message. When Alice receives Bob's answer, she builds her own STUN Request by concatenating her token to Bob's token (resulting in Wing Expires August 4, 2006 [Page 6] Internet-Draft Media Session Authorization January 2006 "B:b:A:a") and sends a STUN Request message to Bob. Bob replies with a STUN Response. In this way, Alice and Bob have verified they have connectivity over that specific path. In the figure below, SIP messages are represented with a dash ("-") and ICE messages (STUN Request, STUN Response) are represented with an equal sign ("="): SIP Proxy or Alice XMPP Server Bob | | | |offer, token=A:a | | |------------------>| | | |offer, token=A:a | | |------------------>| |STUN Request, token=A:a:B:b | |<======================================| |STUN Response | | |======================================>| | |answer, token=B:b | | |<------------------| |answer, token=B:b | | |<------------------| | |STUN Request, token=B:b:A:a | |======================================>| |STUN Response | | |<======================================| Figure 4: ICE Call Flow, with Tokens Highlighted By inserting a firewall on Alice's network, and providing communication between Alice's SIP proxy and the firewall, the firewall can allow media traffic that has been correctly signaled via SIP. The figure below shows the communications that occur between the firewall, the SIP proxy, and the policy server. The firewall is configured to deny new incoming UDP sessions or outgoing UDP sessions unless those sessions start with a STUN Request packet. When a new session contains a STUN Request packet, the STUN Request packet is forwarded to the policy element for authorization. Wing Expires August 4, 2006 [Page 7] Internet-Draft Media Session Authorization January 2006 The following figure shows the network diagram used for Figure 6. +---------+ +-----------+SIP Proxy+-----------------+ | +---+-----+ | | | | (SIP)| +-----+-------+ |(SIP) | |Policy Server| | | +-----+-------+ | | | | +-----+ +---+----+ +-+-+ |Alice|========|firewall|================|Bob| +-----+ (ICE) +--------+ (ICE) +---+ Figure 5: Network Diagram The call flow shown in Figure 6, below, is similar to the call flow shown above ( Figure 4) except the addition of Alice's Policy Device and Alice's firewall. As can be seen in the figure below, the STUN Request message is authorized by Alice's firewall. Specifically, when a STUN Request message arrives at the firewall the message is passed to the policy decision device which determines if the flow should be authorized. The policy decision device authorizes a flow if the ICE token (STUN Username), IP address, and UDP port match a call that was previously signaled by Alice's SIP proxy or by some other network element that can authorize a new media flow. Both STUN Request and STUN Reply messages arriving from 'outside' the network or from 'inside' the network can receive this same authorization, which means that the only UDP packets permitted to cross the firewall will be STUN Request or STUN Response packets that are explicitly authorized by the policy decision device. The policy decision device, as part of allowing the STUN Request or STUN Response packet to transit the firewall, would also inform the firewall that a pinhole should be opened to allow the subsequent flow of media packets over that same 5-tuple (IP source, IP destination, protocol=UDP, port source, port destination). Wing Expires August 4, 2006 [Page 8] Internet-Draft Media Session Authorization January 2006 In this figure, dash ("-") indicates SIP messages, equal ("=") represents STUN messages. The dot (".") indicates communications between SIP proxy, policy decision device, and firewall. In this diagram, the first four devices all belong to Alice's network (Alice, Proxy, Policy Decision Device, and firewall). Alice's Alice's Policy Alice's Alice SIP Proxy Device Firewall Bob | | | | | |(1) offer, token=A:a | | | |------------>| | | | | |(2) new session, token=A:a | | | |............>| | | | |(3) OK | | | | |<............| | | | |(4) offer, token=A:a | | | |---------------------------------------->| | | | |(5) STUN Request, | | | | token=A:a:B:b | | | X<============| | | |(6) token A:a:B:b ok? | | | |<............| | | | |(7) Yes | | | | |............>| | |(8) STUN Request, token=A:a:B:b | | |<========================================| | |(9) STUN Response | | | |======================================================>| | |(10) answer, token=B:b | | | |<----------------------------------------| | |(11) new session, token=B:b| | | |............>| | | | |(12) OK | | | | |<............| | | |(13) answer, token=B:b | | | |<------------| | | | |(14) STUN Request, token=B:b:A:a | | |========================================>X | | | |(15) token B:b:A:a ok? | | | |<............| | | | |(16) Yes | | | | |............>| | | | | |(17) STUN Request, | | | | token=B:b:A:a | | | |============>| |(18) STUN Response | | | |<======================================================| Wing Expires August 4, 2006 [Page 9] Internet-Draft Media Session Authorization January 2006 Figure 6: Media Session Authorization Flow, Single-Homed Network 3. Session Deauthorization Mechanism Typically a SIP session is terminated when the SIP proxy receives notification that the session has ended (SIP BYE messages) or the SIP proxy times out the SIP session [2]. When the session has ended the SIP proxy informs the policy decision device. Because the firewalls asked for authorization to permit those flows earlier, the policy decision device knows which firewall(s) the media passed through. The policy decision device tells those firewalls that the media flow is no longer authorized. The firewalls would then revert to their default behavior for that flow, which is usually to block the flow. There are cases, however, where the policy decision device or the SIP proxy lose state (for example device failure or network partitioning) but the media is still flowing. To handle this situation, the firewall periodically requests re-authorization for each active flow and the SIP proxy periodically informs the policy decision device of ongoing flows. In this way, even after loss of state in the SIP proxy or loss of state in the policy server, the policy server can determine a media session is still active unbeknownst to the SIP proxy and inform the firewall that the flow is no longer authorized. As ICE already requires periodic transmission of keepalive packets to keep NAT bindings open, the firewall can expect to always see either media packets or periodic keepalive packets. If the firewall doesn't see any packets for 90 seconds (3 times the duration of the ICE- recommended keepalive interval), the firewall can decide the flow has ceased and inform the policy decision device. The policy decision device may then inform the firewall and the SIP proxy that the flow has ceased. In this way, an endpoint that has been partitioned from the network or crashed can be noticed even before SIP session timers might have noticed the endpoint has gone away. 4. Control Protocol Requirements There are two control protocols required to realize Media Session Authorization -- one between the firewalls and the policy decision device, and another between the policy decision device and the SIP proxies. To allow arbitrary combinations of the SIP proxy, policy decision device, and firewall, it would be helpful to select the same protocol for the proxy/policy and policy/firewall communication. Requirements of the protocol between the firewall and the policy decision device include: Wing Expires August 4, 2006 [Page 10] Internet-Draft Media Session Authorization January 2006 1. The firewall must send a message to the policy decision device when a STUN Request or STUN Response packet is seen. 2. In order to avoid maintaining state in the firewall the entire STUN Request or STUN Response packet should be sent to the policy decision device. 3. The firewall must be able to inform the policy decision device that a flow has ceased. 4. The policy decision device must be able to tell the firewall that a flow is authorized. 5. The policy decision device must be able to tell the firewall that a flow is no longer authorized. 6. If firewalls protecting a multihomed network are supported on this network, the policy decision device must also be able to inform all firewalls of a valid STUN transaction-id. A secure reliable multicast protocol, such as [8], might be useful for this communication. Requirements of the protocol between the policy decision device and SIP proxy include: 1. The SIP proxy must be able to asynchronously inform the policy decision device of an impending authorized flow. 2. The SIP proxy must be able to asynchronously inform the policy decision device that a previously-authorized flow is still ongoing and still authorized 3. The policy decision device must be able to inform the SIP proxy that a flow has ceased. Applicability of protocols will be discussed in subsequent versions of this document. 5. Minimal Implementation In order to allow a firewall and SIP proxy to provide media session authorization, both endpoints need only implement a subset of ICE. Specifically, the endpoint need only include a single "a=candidate" line which specifies the same IP address and UDP port as the media ("m=") line. This single a=candidate line contains the token (transport-id) which is necessary to provide the media session authorization. Thus, endpoints which have no interest in ICE's NAT traversal capabilities or media relay (TURN) capabilities can still benefit from media session authorization. 6. Security Considerations An attacker might flood a firewall device with bogus STUN Request or Wing Expires August 4, 2006 [Page 11] Internet-Draft Media Session Authorization January 2006 bogus STUN Response packets. STUN Request packets are authorized by forwarding the packet to a policy server, which authorizes the pinhole by examining the destination IP address, port, and STUN Username. STUN Response packets are authorized if its associated STUN Request packet (with the same STUN transaction-id and same IP address and port) was authorized. An attacker could overwhelm the authorization mechanism in a multihomed or single-homed network by sending bogus STUN Request packets or in a multi-homed network by sending bogus STUN Response packets. In order to protect against such an attack of STUN Request packets, the STUN Username in the STUN Request should be coordinated with the firewall in such a way the firewall can ascertain the Username is legitimate. This requires coordinating the STUN Username with the endpoint that originates the STUN messages. Mechanisms to accomplish this coordination are for further study. A legitimate STUN Response shares the same transaction-id and inverse 5-tuple as a previously-authorized STUN Request. On a single-homed network, the STUN Request packet traverses the same firewall as the STUN Response packet, making the firewall's authorization of the STUN Response easy. However, on a multi-homed network the firewall will not have seen the STUN Request packet and thus some other mechanism to accomplish this coordination amongst firewalls in a multi-homed network is required and is for further study. 7. IANA Considerations This document does not add new IANA registrations. 8. References 8.1. Normative References [1] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-06 (work in progress), October 2005. [2] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005. [3] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-06 (work in progress), October 2005. Wing Expires August 4, 2006 [Page 12] Internet-Draft Media Session Authorization January 2006 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. 8.2. Informational References [5] Camarillo, G., "SIP (Session Initiation Protocol)-Unfriendly Functions in Current Communication Architectures", draft-camarillo-sipping-sbc-funcs-02 (work in progress), October 2005. [6] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-08 (work in progress), October 2005. [7] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. [8] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003. [9] Ludwig, S., Saint-Andre, P., Beda, J., and J. Hildebrand, "JEP- 0166: Jingle Signalling", December 2005. http://www.jabber.org/jeps/jep-0166.html Wing Expires August 4, 2006 [Page 13] Internet-Draft Media Session Authorization January 2006 Author's Address Dan Wing Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA Email: dwing@cisco.com Wing Expires August 4, 2006 [Page 14] Internet-Draft Media Session Authorization January 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Wing Expires August 4, 2006 [Page 15]