idnits 2.17.1 draft-wing-session-auth-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 556. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 563. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 569. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 31, 2006) is 6658 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-06 == Outdated reference: A later version (-05) exists of draft-camarillo-sipping-sbc-funcs-02 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-08 -- Obsolete informational reference (is this intentional?): RFC 3547 (ref. '8') (Obsoleted by RFC 6407) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Wing 3 Internet-Draft Cisco Systems 4 Expires: August 4, 2006 January 31, 2006 6 Media Session Authorization 7 draft-wing-session-auth-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 4, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 In many VoIP networks today, firewalls and session border controllers 41 are used at the edge of an administrative domain to allow authorized 42 UDP media flows to enter or leave the network. This document 43 introduces a new mechanism to authorize a UDP media flow. This 44 mechanism works with encrypted hop-by-hop signaling, end-to-end 45 authenticated signaling, and multihomed networks. The media 46 authorization is performed using an Interactive Connectivity 47 Establishment-capable endpoint and a calling signaling device that 48 authorizes a firewall to permit a flow. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.2. Push versus Pull Model . . . . . . . . . . . . . . . . . . 6 55 2. Session Authorization Mechanism . . . . . . . . . . . . . . . 6 56 3. Session Deauthorization Mechanism . . . . . . . . . . . . . . 10 57 4. Control Protocol Requirements . . . . . . . . . . . . . . . . 10 58 5. Minimal Implementation . . . . . . . . . . . . . . . . . . . . 11 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 63 8.2. Informational References . . . . . . . . . . . . . . . . . 13 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 65 Intellectual Property and Copyright Statements . . . . . . . . . . 15 67 1. Introduction 69 Interactive Connectivity Establishment (ICE, [1]) describes a 70 mechanism for traversing NATs. ICE has both peers exchange tokens 71 (STUN Usernames) in order to prevent inadvertent session 72 establishment with a device sharing the same IP address and UDP port 73 as the intended session peer. 75 The mechanism introduced in this document utilizes this normal ICE 76 behavior in order to allow a call processing device (such as a SIP 77 proxy) and a firewall to authorize each UDP media session. 78 Essentially, the call processing device watches the tokens that are 79 exchanged in call signaling, and the same tokens are exchanged in the 80 media path then the media session is authorized. The mechanism does 81 not rely on ICE's NAT traversal technique but takes advantage of the 82 token (STUN Username) exchanged in signaling. 84 The media session authorization described in this document also works 85 on a multihomed network with asymmetric routing through different 86 firewalls. In the following figure the top-most path (through 87 firewall-1) is used for traffic from phone-b to phone-a, and the 88 bottom-most path (through firewall-2) is used for traffic from 89 phone-a to phone-b. 91 +---[firewall-1]<--------+ 92 | | 93 V | 94 [phone-a]--[router] [router]--[phone-b] 95 | ^ 96 | | 97 +--->[firewall-2]--------+ 99 Figure 1: Asymmetric Routing 101 Although SIP is described in this document, any protocol utilizing an 102 offer/answer model ([4] or similar) could utilize the technique 103 described in this document. An example of another such protocol is 104 Jingle [9]. 106 Multiple disparate applications can authorize a UDP media session, 107 with each application communicating with a common policy server. 109 +---------+ +--------------------+ 110 |SIP Proxy| |XMPP (Jabber) Server| 111 +-----+---+ +-----+--------------+ 112 \ / 113 \ / 114 +-+-----------+-+ 115 | Policy Server | 116 +-+----+------+-+ 117 / | \ 118 / | \ 119 +--+-+ +--+-+ ++----+ 120 |FW-1| |FW-2| ... |FW-nn| 121 +----+ +--+-+ +-----+ 123 Figure 2: Multiple applications authorizing media sessions 125 1.1. Motivation 127 Two techniques commonly provide ingress/egress security today -- 128 firewall application layer gateways (ALG) and Session Border 129 Controllers (SBC) [5]. In order to perform its security function, 130 the ALG must be able to examine the SIP signaling, whereas an SBC is 131 actively involved with modifying the SIP signaling (specifically the 132 SDP, and often SIP headers as well). However the use of hop-by-hop 133 signaling encryption (such as with TLS) breaks firewall ALGs, and the 134 use of end-to-end signaling encryption (such as S/MIME) or end-to-end 135 integrity protection (such as SIP Identity [3]) breaks SBCs. 136 Additionally both a firewall and an SBC constrain the media path, 137 causing packets to not take the best path. A firewall requires the 138 signaling and media flow through the firewall (which is achieved 139 through network design) and an SBC causes media to flow through the 140 SBC (by modifying SDP in SIP signaling). 142 Two other techniques are less common. An on-path technique to 143 provide ingress/egress security is NSIS NSLP [6]. MIDCOM [7] is an 144 off-path firewall and NAT control protocol which requires topology 145 awareness. 147 Media session authorization can be implemented by one network without 148 needing to be implemented by a remote network. The remote network 149 need only implement ICE -- no extensions to ICE are necessary. This 150 makes deployment of this mechanism easy. 152 The tradeoffs of media session authorization are summarized in the 153 following table. 155 | FW | | NSIS | | Media 156 Works With | ALG | SBC | NSLP | MIDCOM | Sess Auth 157 -----------------------+------+------+------+--------+---------- 158 TLS signaling | No | Yes | Yes | Yes | Yes 159 S/MIME signaling | No | No | No | No | No/6 160 existing NATs | No/1 | Yes | No/1 | No/1 | Yes 161 existing firewalls | No/1 | Yes | No/1 | No/1 | No/1 162 SIP Identity | Yes | No/2 | Yes | Yes | Yes 163 multihomed networks | No | No/3 | Yes | Yes/8 | Yes 164 existing endpoints | Yes | Yes | No/4 | Yes | No/5 165 UDP media | Yes | Yes | Yes | Yes | Yes 166 TCP media | Yes | Yes | Yes | Yes | No/7 167 Topology unaware | Yes | Yes | Yes | No | Yes 168 best-path routing | No | No | Yes | Yes | Yes 170 Figure 3: Comparison of Techniques 172 Notes: 174 1. To be Yes, the Firewall (or NAT) would need to be upgraded to 175 support each traversal type (SIP ALG, MIDCOM, NSIS NSLP). 176 NATs do not provide policy control and work without 177 modification with both media session authorization and with 178 SBCs. SBCs work with existing firewalls by configuring the 179 firewall with a pinhole for the SBC's media address(es) and 180 using the SBC to provide policy control normally attributed to 181 the firewall. 182 2. To be Yes, the SBC would need to rewrites the From: and 183 creates a new sip-identity signature; this is only possible 184 with E.164 numbers or if the SBC is in the same administrative 185 domain as the From: domain. 186 3. While it is possible for SBCs to form their own multihomed 187 overlay network, it isn't the same as IP multihoming. 188 4. Local endpoint must implement NSIS NSLP. If remote endpoint 189 doesn't support NSIS NSLP, NSLP's RESERVE-EXTERNAL-ADDRESS 190 mode is required. 191 5. To be Yes, both local and remote endpoints must support ICE. 192 6. S/MIME prevents the local SIP proxies from viewing the 193 endpoint's tokens. To be Yes, the firewall or policy server 194 must be told the endpoint's tokens. 195 7. Authorizing TCP-based media sessions is under study. 196 8. Multihomed networks can be supported with sufficient awareness 197 of network topology and routing. 199 1.2. Push versus Pull Model 201 When separate devices are used for firewalling (policy enforcement) 202 and policy decisions, a 'push' or 'pull' model can be used to 203 communicate between the devices. In the push model, the policy 204 decision device informs the firewall of an authorized flow. In the 205 pull model, the firewall asks the policy decision device if a flow is 206 authorized. 208 The strength of the policy push model is it avoids session 209 authorization delays. The weakness is that it requires topology 210 awareness (need to know which firewalls to inform) or requires 211 informing all firewalls about every authorized flow. 213 The strength of the policy pull model is it allows multihomed 214 networks and doesn't require topology awareness. The weakness is 215 that strict policy enforcement, where authorized flows are permitted 216 and unauthorized flows are denied, incurs some authorization delay. 218 This document describes a pull model. 220 2. Session Authorization Mechanism 222 The figure below shows a simplified ICE message flow which highlights 223 the characteristics of standard ICE that are useful to build the flow 224 authorization described by this document. As it relates to media 225 session authorization, the key aspect of ICE are the unique, per-call 226 identifiers (transport address id) generated by the calling party and 227 the unique, per-call identifier generated by the called party. These 228 tokens are exchanged in call signaling, and are then exchanged again 229 in the media path in STUN Request messages. 231 In the figure below, Alice and Bob perform normal ICE procedures. 232 Alice generates an offer [4] containing her unique, per-call token 233 ("A:a" in the figure). This token is the 'candidate id' and 234 'component id' described in ICE. This token is sent to the other 235 party, Bob. Upon receipt of this offer, Bob generates his own token 236 ('candidate id' and 'component id'). These are concatinated with 237 Alice's token, resulting in "A:a:B:b". Bob sends a STUN Request 238 message directly to Alice's IP address. Bob also sends an answer, in 239 call signaling, containing his token ('candidate id' and 'component 240 id'). 242 Alice receives the STUN Request. By parsing the message she 243 determines it contains her token. She response with a STUN Response 244 message. When Alice receives Bob's answer, she builds her own STUN 245 Request by concatenating her token to Bob's token (resulting in 246 "B:b:A:a") and sends a STUN Request message to Bob. Bob replies with 247 a STUN Response. In this way, Alice and Bob have verified they have 248 connectivity over that specific path. 250 In the figure below, SIP messages are represented with a dash ("-") 251 and ICE messages (STUN Request, STUN Response) are represented with 252 an equal sign ("="): 254 SIP Proxy or 255 Alice XMPP Server Bob 256 | | | 257 |offer, token=A:a | | 258 |------------------>| | 259 | |offer, token=A:a | 260 | |------------------>| 261 |STUN Request, token=A:a:B:b | 262 |<======================================| 263 |STUN Response | | 264 |======================================>| 265 | |answer, token=B:b | 266 | |<------------------| 267 |answer, token=B:b | | 268 |<------------------| | 269 |STUN Request, token=B:b:A:a | 270 |======================================>| 271 |STUN Response | | 272 |<======================================| 274 Figure 4: ICE Call Flow, with Tokens Highlighted 276 By inserting a firewall on Alice's network, and providing 277 communication between Alice's SIP proxy and the firewall, the 278 firewall can allow media traffic that has been correctly signaled via 279 SIP. The figure below shows the communications that occur between 280 the firewall, the SIP proxy, and the policy server. The firewall is 281 configured to deny new incoming UDP sessions or outgoing UDP sessions 282 unless those sessions start with a STUN Request packet. When a new 283 session contains a STUN Request packet, the STUN Request packet is 284 forwarded to the policy element for authorization. 286 The following figure shows the network diagram used for Figure 6. 288 +---------+ 289 +-----------+SIP Proxy+-----------------+ 290 | +---+-----+ | 291 | | | 292 (SIP)| +-----+-------+ |(SIP) 293 | |Policy Server| | 294 | +-----+-------+ | 295 | | | 296 +-----+ +---+----+ +-+-+ 297 |Alice|========|firewall|================|Bob| 298 +-----+ (ICE) +--------+ (ICE) +---+ 300 Figure 5: Network Diagram 302 The call flow shown in Figure 6, below, is similar to the call flow 303 shown above ( Figure 4) except the addition of Alice's Policy Device 304 and Alice's firewall. As can be seen in the figure below, the STUN 305 Request message is authorized by Alice's firewall. Specifically, 306 when a STUN Request message arrives at the firewall the message is 307 passed to the policy decision device which determines if the flow 308 should be authorized. The policy decision device authorizes a flow 309 if the ICE token (STUN Username), IP address, and UDP port match a 310 call that was previously signaled by Alice's SIP proxy or by some 311 other network element that can authorize a new media flow. 313 Both STUN Request and STUN Reply messages arriving from 'outside' the 314 network or from 'inside' the network can receive this same 315 authorization, which means that the only UDP packets permitted to 316 cross the firewall will be STUN Request or STUN Response packets that 317 are explicitly authorized by the policy decision device. The policy 318 decision device, as part of allowing the STUN Request or STUN 319 Response packet to transit the firewall, would also inform the 320 firewall that a pinhole should be opened to allow the subsequent flow 321 of media packets over that same 5-tuple (IP source, IP destination, 322 protocol=UDP, port source, port destination). 324 In this figure, dash ("-") indicates SIP messages, equal ("=") 325 represents STUN messages. The dot (".") indicates communications 326 between SIP proxy, policy decision device, and firewall. In this 327 diagram, the first four devices all belong to Alice's network (Alice, 328 Proxy, Policy Decision Device, and firewall). 330 Alice's Alice's Policy Alice's 331 Alice SIP Proxy Device Firewall Bob 332 | | | | | 333 |(1) offer, token=A:a | | | 334 |------------>| | | | 335 | |(2) new session, token=A:a | | 336 | |............>| | | 337 | |(3) OK | | | 338 | |<............| | | 339 | |(4) offer, token=A:a | | 340 | |---------------------------------------->| 341 | | | |(5) STUN Request, 342 | | | | token=A:a:B:b 343 | | | X<============| 344 | | |(6) token A:a:B:b ok? | 345 | | |<............| | 346 | | |(7) Yes | | 347 | | |............>| | 348 |(8) STUN Request, token=A:a:B:b | | 349 |<========================================| | 350 |(9) STUN Response | | | 351 |======================================================>| 352 | |(10) answer, token=B:b | | 353 | |<----------------------------------------| 354 | |(11) new session, token=B:b| | 355 | |............>| | | 356 | |(12) OK | | | 357 | |<............| | | 358 |(13) answer, token=B:b | | | 359 |<------------| | | | 360 |(14) STUN Request, token=B:b:A:a | | 361 |========================================>X | 362 | | |(15) token B:b:A:a ok? | 363 | | |<............| | 364 | | |(16) Yes | | 365 | | |............>| | 366 | | | |(17) STUN Request, 367 | | | | token=B:b:A:a 368 | | | |============>| 369 |(18) STUN Response | | | 370 |<======================================================| 372 Figure 6: Media Session Authorization Flow, Single-Homed Network 374 3. Session Deauthorization Mechanism 376 Typically a SIP session is terminated when the SIP proxy receives 377 notification that the session has ended (SIP BYE messages) or the SIP 378 proxy times out the SIP session [2]. When the session has ended the 379 SIP proxy informs the policy decision device. Because the firewalls 380 asked for authorization to permit those flows earlier, the policy 381 decision device knows which firewall(s) the media passed through. 382 The policy decision device tells those firewalls that the media flow 383 is no longer authorized. The firewalls would then revert to their 384 default behavior for that flow, which is usually to block the flow. 386 There are cases, however, where the policy decision device or the SIP 387 proxy lose state (for example device failure or network partitioning) 388 but the media is still flowing. To handle this situation, the 389 firewall periodically requests re-authorization for each active flow 390 and the SIP proxy periodically informs the policy decision device of 391 ongoing flows. In this way, even after loss of state in the SIP 392 proxy or loss of state in the policy server, the policy server can 393 determine a media session is still active unbeknownst to the SIP 394 proxy and inform the firewall that the flow is no longer authorized. 396 As ICE already requires periodic transmission of keepalive packets to 397 keep NAT bindings open, the firewall can expect to always see either 398 media packets or periodic keepalive packets. If the firewall doesn't 399 see any packets for 90 seconds (3 times the duration of the ICE- 400 recommended keepalive interval), the firewall can decide the flow has 401 ceased and inform the policy decision device. The policy decision 402 device may then inform the firewall and the SIP proxy that the flow 403 has ceased. In this way, an endpoint that has been partitioned from 404 the network or crashed can be noticed even before SIP session timers 405 might have noticed the endpoint has gone away. 407 4. Control Protocol Requirements 409 There are two control protocols required to realize Media Session 410 Authorization -- one between the firewalls and the policy decision 411 device, and another between the policy decision device and the SIP 412 proxies. To allow arbitrary combinations of the SIP proxy, policy 413 decision device, and firewall, it would be helpful to select the same 414 protocol for the proxy/policy and policy/firewall communication. 416 Requirements of the protocol between the firewall and the policy 417 decision device include: 419 1. The firewall must send a message to the policy decision device 420 when a STUN Request or STUN Response packet is seen. 421 2. In order to avoid maintaining state in the firewall the entire 422 STUN Request or STUN Response packet should be sent to the policy 423 decision device. 424 3. The firewall must be able to inform the policy decision device 425 that a flow has ceased. 426 4. The policy decision device must be able to tell the firewall that 427 a flow is authorized. 428 5. The policy decision device must be able to tell the firewall that 429 a flow is no longer authorized. 430 6. If firewalls protecting a multihomed network are supported on 431 this network, the policy decision device must also be able to 432 inform all firewalls of a valid STUN transaction-id. A secure 433 reliable multicast protocol, such as [8], might be useful for 434 this communication. 436 Requirements of the protocol between the policy decision device and 437 SIP proxy include: 439 1. The SIP proxy must be able to asynchronously inform the policy 440 decision device of an impending authorized flow. 441 2. The SIP proxy must be able to asynchronously inform the policy 442 decision device that a previously-authorized flow is still 443 ongoing and still authorized 444 3. The policy decision device must be able to inform the SIP proxy 445 that a flow has ceased. 447 Applicability of protocols will be discussed in subsequent versions 448 of this document. 450 5. Minimal Implementation 452 In order to allow a firewall and SIP proxy to provide media session 453 authorization, both endpoints need only implement a subset of ICE. 454 Specifically, the endpoint need only include a single "a=candidate" 455 line which specifies the same IP address and UDP port as the media 456 ("m=") line. This single a=candidate line contains the token 457 (transport-id) which is necessary to provide the media session 458 authorization. Thus, endpoints which have no interest in ICE's NAT 459 traversal capabilities or media relay (TURN) capabilities can still 460 benefit from media session authorization. 462 6. Security Considerations 464 An attacker might flood a firewall device with bogus STUN Request or 465 bogus STUN Response packets. STUN Request packets are authorized by 466 forwarding the packet to a policy server, which authorizes the 467 pinhole by examining the destination IP address, port, and STUN 468 Username. STUN Response packets are authorized if its associated 469 STUN Request packet (with the same STUN transaction-id and same IP 470 address and port) was authorized. An attacker could overwhelm the 471 authorization mechanism in a multihomed or single-homed network by 472 sending bogus STUN Request packets or in a multi-homed network by 473 sending bogus STUN Response packets. 475 In order to protect against such an attack of STUN Request packets, 476 the STUN Username in the STUN Request should be coordinated with the 477 firewall in such a way the firewall can ascertain the Username is 478 legitimate. This requires coordinating the STUN Username with the 479 endpoint that originates the STUN messages. Mechanisms to accomplish 480 this coordination are for further study. 482 A legitimate STUN Response shares the same transaction-id and inverse 483 5-tuple as a previously-authorized STUN Request. On a single-homed 484 network, the STUN Request packet traverses the same firewall as the 485 STUN Response packet, making the firewall's authorization of the STUN 486 Response easy. However, on a multi-homed network the firewall will 487 not have seen the STUN Request packet and thus some other mechanism 488 to accomplish this coordination amongst firewalls in a multi-homed 489 network is required and is for further study. 491 7. IANA Considerations 493 This document does not add new IANA registrations. 495 8. References 497 8.1. Normative References 499 [1] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 500 Methodology for Network Address Translator (NAT) Traversal for 501 Offer/Answer Protocols", draft-ietf-mmusic-ice-06 (work in 502 progress), October 2005. 504 [2] Donovan, S. and J. Rosenberg, "Session Timers in the Session 505 Initiation Protocol (SIP)", RFC 4028, April 2005. 507 [3] Peterson, J. and C. Jennings, "Enhancements for Authenticated 508 Identity Management in the Session Initiation Protocol (SIP)", 509 draft-ietf-sip-identity-06 (work in progress), October 2005. 511 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 512 Session Description Protocol (SDP)", RFC 3264, June 2002. 514 8.2. Informational References 516 [5] Camarillo, G., "SIP (Session Initiation Protocol)-Unfriendly 517 Functions in Current Communication Architectures", 518 draft-camarillo-sipping-sbc-funcs-02 (work in progress), 519 October 2005. 521 [6] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 522 (NSLP)", draft-ietf-nsis-nslp-natfw-08 (work in progress), 523 October 2005. 525 [7] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. 526 Rayhan, "Middlebox communication architecture and framework", 527 RFC 3303, August 2002. 529 [8] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group 530 Domain of Interpretation", RFC 3547, July 2003. 532 [9] Ludwig, S., Saint-Andre, P., Beda, J., and J. Hildebrand, "JEP- 533 0166: Jingle Signalling", December 2005. 535 http://www.jabber.org/jeps/jep-0166.html 537 Author's Address 539 Dan Wing 540 Cisco Systems 541 170 West Tasman Drive 542 San Jose, CA 95134 543 USA 545 Email: dwing@cisco.com 547 Intellectual Property Statement 549 The IETF takes no position regarding the validity or scope of any 550 Intellectual Property Rights or other rights that might be claimed to 551 pertain to the implementation or use of the technology described in 552 this document or the extent to which any license under such rights 553 might or might not be available; nor does it represent that it has 554 made any independent effort to identify any such rights. Information 555 on the procedures with respect to rights in RFC documents can be 556 found in BCP 78 and BCP 79. 558 Copies of IPR disclosures made to the IETF Secretariat and any 559 assurances of licenses to be made available, or the result of an 560 attempt made to obtain a general license or permission for the use of 561 such proprietary rights by implementers or users of this 562 specification can be obtained from the IETF on-line IPR repository at 563 http://www.ietf.org/ipr. 565 The IETF invites any interested party to bring to its attention any 566 copyrights, patents or patent applications, or other proprietary 567 rights that may cover technology that may be required to implement 568 this standard. Please address the information to the IETF at 569 ietf-ipr@ietf.org. 571 Disclaimer of Validity 573 This document and the information contained herein are provided on an 574 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 575 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 576 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 577 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 578 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 579 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 581 Copyright Statement 583 Copyright (C) The Internet Society (2006). This document is subject 584 to the rights, licenses and restrictions contained in BCP 78, and 585 except as set forth therein, the authors retain all their rights. 587 Acknowledgment 589 Funding for the RFC Editor function is currently provided by the 590 Internet Society.