Internet DRAFT - draft-wing-session-auth
draft-wing-session-auth
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]
