INTERNET-DRAFT Joerg Ott/Uni Bremen TZI draft-ietf-avt-profile-savpf-00.txt Elisabetta Carrara/Ericsson 19 October 2003 Expires March 2004 Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract An RTP profile (SAVP) is defined for secure real-time communications, and another profile (AVPF) is specified to provide timely feedback from the receivers to a sender. This memo defines the combination of both profiles to enable secure RTP communications with feedback. Ott, Carrara Expires March 2004 [Page 1]
Internet Draft draft-ietf-avt-profile-savpf-00.txt 19 October 2003 Table of Contents 1 Introduction.................................................2 1.1 Definitions.............................................3 1.2 Terminology.............................................4 2 SAVPF Rules..................................................4 2.1 Packet Formats..........................................5 2.2 Extensions..............................................5 2.3 Implications from combining AVPF and SAVP...............5 3 SDP Definitions..............................................6 3.1 Profile Definition......................................6 3.2 Attribute Definitions...................................6 3.3 Profile Negotiation.....................................6 3.3.1 Offer/Answer-based Negotiation of Session Descriptions.7 3.3.2 RTSP-based Negotiation of Session Descriptions.........7 3.3.3 Announcing Session Descriptions........................7 3.3.4 Describing Alternative Session Profiles................8 3.4 Examples................................................9 4 Interworking of AVP, SAVP, AVPF, and SAVPF Entities.........11 5 Security Considerations.....................................11 6 IANA Considerations.........................................12 7 Acknowledgements............................................13 8 Authors' Addresses..........................................13 9 Bibliography................................................13 9.1 Normative references...................................14 9.2 Informative References.................................14 10 IPR Notice..................................................15 11 Full Copyright Statement....................................15 1 Introduction The Real-time Transport Protocol (RTP/RTCP) [1] and the associated profile for audiovisual communications with minimal control [2] define mechanisms for transmitting time-based media across an IP network. RTP provides means to preserve timing and detect packet losses, among other things, and RTP payload formats provide for proper framing of (continuous) media in a packet-based environment. RTCP enables receivers to provide feedback on reception quality and allows all members of an RTP session to learn about each other. The RTP specification provides only rudimentary support for encrypting RTP and RTCP packets. SRTP [4] defines an RTP profile Ott, Carrara Expires March 2004 [Page 2]
Internet Draft draft-ietf-avt-profile-savpf-00.txt 19 October 2003 ("SAVP") for secure RTP media sessions, defining methods for proper RTP and RTCP packet encryption, integrity and replay protection. The initial negotiation of SRTP and its security parameters needs to be done out of band, using e.g. the Session Description Protocol (SDP) [6] together with extensions for conveying keying material [7][8]. The RTP specification also provides limited support for timely feedback from receivers to senders, typically by means of reception statistics reporting in somewhat regular intervals depending on the group size, the average RTCP packet size, and the available RTCP bandwidth. The extended RTP profile for RTCP-based feedback ("AVPF") [3] allows receivers statistically to provide immediate feedback while maintaining the average RTCP data rate for all senders. As for SAVP, the use of AVPF and its parameters need to be negotiated out-of-band by means of SDP [6] and the extensions defined in [3]. Both SRTP and AVPF are RTP profiles and need to be negotiated. This implies that either one or the other may be used, but both profiles cannot be negotiated for the same RTP session (using one SDP session level description). However, using secure communications and timely feedback together is desirable. Therefore, this document specifies a new RTP profile ("SAVPF") that combines the features of SAVP and AVPF. As SAVP and AVPF are largely orthogonal, the combination of both is mostly straightforward. No sophisticated algorithms need to be specified in this document. Instead, reference is made to both existing profiles and only the implications of their combination and possible deviations from rules of the existing profiles are described as is the negotiation process. 1.1 Definitions The definitions of [1], [2], [3], and [4] apply. The following definitions are specifically used in this document: RTP session: An association among a set of participants communicating with RTP as defined in [1]. (SDP) media description: This term refers to the specification given in a single m= line in an SDP message. An SDP media description may define only one RTP session. Grouping of m= lines in SDP may cause several SDP session level descriptions to define (alternatives of) the same RTP session for the same media type. Ott, Carrara Expires March 2004 [Page 3]
Internet Draft draft-ietf-avt-profile-savpf-00.txt 19 October 2003 Media session: A media session refers to a collection of SDP media descriptions that are semantically grouped to represent alternatives of the same communications means. Out of such a group, one will be negotiated or chosen for a communication relationship and the corresponding RTP session will be instantiated. Or the media session will be rejected. In the simplest case, a media session is equivalent to an SDP media description and equivalent to an RTP session. 1.2 Terminology 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 [5]. 2 SAVPF Rules SAVP is defined as an intermediate layer between RTP (following the regular RTP profile AVP) and UDP. This yields a two layer hierarchy within the Real-time Transport Protocol. In SAVPF, the upper (AVP) layer is replaced by the extended RTP profile for feedback (AVPF). AVPF modifies timing rules for transmitting RTCP packets and adds extra RTCP packet formats specific to feedback. These functions are independent of whether or not RTCP packets are subsequently encrypted and/or integrity protected. The functioning of the AVPF layer remains unchanged in SAVPF. The AVPF profile derives from [1] the (optional) use of the encryption prefix for RTCP. The encryption prefix MUST NOT be used within the SAVPF profile (it is not used in SAVP, as it is only applicable to the encryption method specified in [1]). The SAVP part uses extra fields added to the end of RTP and RTCP packets and executes cryptographic transforms on (some of) the RTP/RTCP packet contents. This behavior remains unchanged in SAVPF. The average RTCP packet size calculation done by the AVPF layer for timing purposes MUST take into account the fields added by the SAVP layer. The SRTP part becomes only active whenever the RTP or RTCP was scheduled by the "higher" AVPF layer or received from the transport protocol, irrespective of its timing and contents. Ott, Carrara Expires March 2004 [Page 4]
Internet Draft draft-ietf-avt-profile-savpf-00.txt 19 October 2003 2.1 Packet Formats AVPF defines extra packet formats to provide feedback information. Those extra packet formats defined in [3] (and further ones defined elsewhere for use with AVPF) MAY be used with SAVPF. SAVP defines a modified packet format for SRTP and SRTCP packets that essentially consists of the RTP/RTCP packet formats plus some trailing protocol fields for security purposes. For SAVPF, all RTCP packets MUST be encapsulated as defined in section 3.4 of [4]. 2.2 Extensions Extensions to AVPF RTCP feedback packets defined elsewhere MAY be used with the SAVPF profile provided that those extensions are in conformance with the extension rules of [3]. Additional transforms defined for SAVP following the rules of section 6 of [4] MAY also be used with the SAVPF profile. The overhead per RTCP packet depends on the transforms chosen. New transforms added in the future MAY introduce yet unknown further per-packet overhead. 2.3 Implications from combining AVPF and SAVP The AVPF profile aims at -- statistically -- allowing receivers to provide timely feedback to senders. The frequency at which receivers are, on average, allowed to send feedback information depends on the RTCP bandwidth, the group size, and the average size of an RTCP packet. SRTCP adds extra fields (some of which are of variable size) at the end of each RTCP packet that are probably at least some 10 to 20 bytes in size (14 bytes as default). Note that transforms defined in the future MAY add greater overhead. With this, the average size of an RTCP packet will increase -- roughly estimated by some e.g. 10% to 30% -- and thus reduce the frequency at which (timely) feedback can be provided. Application designers need to be aware of this, and take precautions so that the RTCP bandwidth shares are maintained. This MUST be done by adjusting the RTCP variable "avg_rtcp_size" to include the size of the fields that will be added by SRTCP (index, E-bit, authentication tag, and when present, the MKI). This means, for example, that the definition of the avg_rtcp_size in Section 3.4 of [3] shall be Ott, Carrara Expires March 2004 [Page 5]
Internet Draft draft-ietf-avt-profile-savpf-00.txt 19 October 2003 calculated on the resulting SRTCP packet as described in Section 3.4 of [4]. 3 SDP Definitions 3.1 Profile Definition The AV profiles defined in [2], [3], and [4] are referred to as "AVP", "AVPF", and "SAVP", respectively, in the context of e.g. the Session Description Protocol (SDP) [3]. The combined profile specified in this document is referred to as "SAVPF". 3.2 Attribute Definitions SDP attributes for negotiating SAVP sessions are defined in [7] and [8]. Those attributes MAY also be used with SAVPF. The rules defined in [7] and [8] apply. SDP attributes for negotiating AVPF sessions are defined in [3]. Those attributes MAY also be used with SAVPF. The rules defined in [3] apply. 3.3 Profile Negotiation Session descriptions for RTP sessions may be conveyed using protocols dedicated for multimedia communications such as the SDP offer/answer model [10] used with SIP, RTSP [11], or SAP [12] but may also be distributed using email, NetNews, web pages, etc. The offer/answer model allows the resulting session parameters to be negotiated using the SDP attributes defined in [7] and [8]. In the following subsection, the negotiation process is described in terms of the offer/answer model. RTSP does not use the offer/answer model; however specific negotiation support is provided by [7] as discussed in subsection 3.3.2. 3.3.1 Offer/Answer-based Negotiation of Session Descriptions Negotiations are carried out on a per-media session basis. If negotiating one media session fails, others MAY still succeed. Different RTP profiles MAY be used in different media sessions. Ott, Carrara Expires March 2004 [Page 6]
Internet Draft draft-ietf-avt-profile-savpf-00.txt 19 October 2003 For negotiation an media description, the four profiles AVP, AVPF, SAVP, and SAVPF are mutually exclusive. Note, however, that SAVP and SAVPF entities MAY be mixed in a single RTP session (see section 4). Therefore, both MAY be offered as alternatives for the same media session (e.g. using the same transport parameters). An offerer that is capable of supporting multiple of these profiles for a certain media session SHOULD always offer all alternatives acceptable in a certain situation. At least, SAVP and SAVPF SHOULD be offered as this does not impact security. However, the offers SHOULD NOT include both a secure alternative (SAVP and SAVPF) and an insecure alternative (e.g. AVP and AVPF) in the same offer as this will most likely open up for bidding down attacks. If a media description in an offer uses SAVPF and the answerer does not support SAVPF, the media session MUST be rejected. If a media description in an offer does not use SAVPF but the answerer wants to use SAVPF, the answerer SHOULD reject the media session. Alternatively, depending on whether or not offer is otherwise acceptable, the answerer MAY accept the media description and provide a counter-offer with a media description indicating SAVPF in a subsequently initiated offer/answer exchange. 3.3.2 RTSP-based Negotiation of Session Descriptions RTSP [11] does not support the offer/answer model. However, RTSP supports negotiating media session parameters (including profile and address information) by means of the "Transport:" header. SDP- based key management as defined in [7] adds a parameter to support conveying keying material. Hence, the RTSP "Transport:" header MAY be used to pass keying information and negotiate the profile for the media session. The interoperability rules defined in section 3.3.1 SHALL apply. 3.3.3 Announcing Session Descriptions Protocols that do not allow to negotiate session descriptions interactively (e.g. SAP, descriptions posted on a web page or sent by mail) pose the responsibility for adequate access to the media sessions on the initiator of a session. The initiator SHOULD provide alternative session descriptions for multiple RTP profiles as far as acceptable to the application and the purpose of the session. If security is desired, SAVP may be offered as alternative to SAVPF -- but AVP or AVPF sessions SHOULD Ott, Carrara Expires March 2004 [Page 7]
Internet Draft draft-ietf-avt-profile-savpf-00.txt 19 October 2003 not be announced unless other security means not relying on SRTP are employed. The SDP attributes defined in [7] and [8] may also be used for the security parameter distribution of announced session descriptions. The security scheme description defined in [8] requires a secure communications channel to prevent third parties from eavesdropping on the keying parameters. Therefore, SAP encryption (as defined in [12]), S/MIME [13], HTTPS [14], or other suitable mechanisms SHOULD be used for distributing or accessing these session descriptions. 3.3.4 Describing Alternative Session Profiles SAVP and SAVPF entities MAY be mixed in the same RTP session (see also section 4) and so may AVP and AVPF entities. Other combinations -- i.e. between secure and insecure profiles -- in the same RTP session are not possible and SHALL NOT be used. If both insecure and secure profiles shall be offered, different RTP sessions MUST be used, expressed through different addresses and/or port numbers. A grouping mechanisms as defined in [9] SHOULD be used to indicate semantic equivalence between the individual sessions and ensure that any receiver only joins one of them. [JO: Note that there is an open issue currently discussed in MMUSIC regarding whether or not the same transport address may be used in two or more m= lines and, if so, whether or not an explicit grouping mechanism is required. The respective semantics also need to be documented.] For SAVP and SAVPF, the same RTP session MAY be used but it may be advisable to also use different ones in order to allow optimal support for feedback-enabled receivers. In case the same RTP session shall be used for both SAVP and SAVPF, two media sessions need to be defined in SDP. For the same RTP session both will use the same address and port numbers. Those two media sessions SHOULD be grouped by using the mechanism defined in [9] to indicate semantic equivalence between the individual sessions and ensure that any receiver only joins one of them. 3.4 Examples Ott, Carrara Expires March 2004 [Page 8]
Internet Draft draft-ietf-avt-profile-savpf-00.txt 19 October 2003 Example 1: The following session description indicates a secure session made up from audio and DTMF [18] for point-to-point communication in which the DTMF stream uses Generic ACKs. The key management protocol is indicated in MIKEY. This session description (the offer) could be contained in a SIP INVITE or 200 OK message to indicate that its sender is capable of and willing to receive feedback for the DTMF stream it transmits. The corresponding answer may be carried in a 200 OK or an ACK. The parameters for the security protocol are negotiated as described by the SDP extensions defined in [7]. v=0 o=alice 3203093520 3203093520 IN IP4 host.example.com s=Media with feedback t=0 0 c=IN IP4 host.example.com m=audio 49170 RTP/SAVPF 0 96 a=rtpmap:0 PCMU/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-16 a=rtcp-fb:96 ack a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... Example 2: This example shows the same feedback parameters as example 1 but uses the secure descriptions syntax [8]. Note that the key part of the a=crypto attribute is not protected against eavesdropping and thus the session description MUST be exchanged over a secure communication channel. v=0 o=alice 3203093520 3203093520 IN IP4 host.example.com s=Media with feedback t=0 0 c=IN IP4 host.example.com m=audio 49170 RTP/SAVPF 0 96 a=rtpmap:0 PCMU/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-16 a=rtcp-fb:96 ack a=crypto:AES_CM_128_HMAC_SHA1_32 inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1 :32 Example 3: The following session description indicates a multicast audio/video session (using PCMU for audio and either H.261 or H.263+) with the video source accepting Generic NACKs for both codecs and Reference Picture Selection for H.263. The parameters for the security protocol are negotiated as described by the SDP extensions defined in [7], used at the session level. Such a Ott, Carrara Expires March 2004 [Page 9]
Internet Draft draft-ietf-avt-profile-savpf-00.txt 19 October 2003 description may have been conveyed using the Session Announcement Protocol (SAP). v=0 o=alice 3203093520 3203093520 IN IP4 host.example.com s=Multicast video with feedback t=3203130148 3203137348 a=key-mgmt:mikey uiSDF9sdhs7494ghsd/dhsoKkdOokdo7eWsnDSJD... m=audio 49170 RTP/SAVP 0 c=IN IP4 224.2.1.183 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/SAVPF 98 99 c=IN IP4 224.2.1.184 a=rtpmap:98 H263-1998/90000 a=rtpmap:99 H261/90000 a=rtcp-fb:* nack a=rtcp-fb:98 nack rpsi Example 4: The following session description defines the same media session as example 3 but allows for mixed mode operation of SAVP and SAVPF RTP entities (see also next section). Note that both media descriptions use the same addresses; however, two m= lines are needed to convey information about both applicable RTP profiles. The parameters for the security protocol are negotiated as described by SDP extensions defined in [7], used at the session level. v=0 o=alice 3203093520 3203093520 IN IP4 host.example.com s=Multicast video with feedback t=3203130148 3203137348 a=key-mgmt:mikey uiSDF9sdhs7854ghsd/dhsoKkdOokdo7eWsnDSJD... m=audio 49170 RTP/SAVP 0 c=IN IP4 224.2.1.183 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/SAVP 98 99 c=IN IP4 224.2.1.184 a=rtpmap:98 H263-1998/90000 a=rtpmap:99 H261/90000 m=video 51372 RTP/SAVPF 98 99 c=IN IP4 224.2.1.184 a=rtpmap:98 H263-1998/90000 a=rtpmap:99 H261/90000 a=rtcp-fb:* nack a=rtcp-fb:98 nack rpsi Note that these two m= lines SHOULD be grouped by some appropriate mechanism to indicate that both are alternatives actually conveying Ott, Carrara Expires March 2004 [Page 10]
Internet Draft draft-ietf-avt-profile-savpf-00.txt 19 October 2003 the same contents. A sample mechanism by which this can be achieved is defined in [9]. 4 Interworking of AVP, SAVP, AVPF, and SAVPF Entities The SAVPF profile defined in this document is a combination of the SAVP profile [4] and the AVPF profile [3](which in turn is an extension of the RTP profile as defined in [2]). SAVP and SAVPF use SRTP [4] to achieve security. AVP and AVPF use plain RTP [1] and hence do not provide security (unless external security mechanisms are applied as discussed in section 9.1 of [1]). SRTP and RTP and not meant to interoperate, the respective protocol entities are not supposed to be part of the same RTP session. Hence, AVP and AVPF on one side and SAVP and SAVPF on the other MUST NOT be mixed. RTP entities using the SAVP and the SAVPF profiles MAY be mixed in a single RTP session. The interworking considerations defined in section 5 of [3] apply. 5 Security Considerations The SAVPF profile inherits its security properties from the SAVP profile; therefore it is subject to the security considerations discussed in [4]. The SAVP profile does not add, nor take away, any security services compared to SAVP. There is a desire to support security for media streams and, at the same time, for backward compatibility with non-SAVP(F) nodes. Application designers should be aware that security SHOULD NOT be traded for interoperability. If information is to be distributed to closed groups (i.e. confidentially protected), it is RECOMMENDED not to offer alternatives for a media session other than SAVP and SAVPF as described in sections 3.3 and 3.4, unless other security mechanisms will be used, e.g. the ones described in Section 9.1 of [1]. Similarly, if integrity protection is considered important, it is RECOMMENDED not to offer the alternatives other than SAVP and SAVPF (unless other mechanisms are known to be in place that can guarantee it, e.g. lower-layer mechanisms as described in Section 9 of [1]). Offering secure and insecure profiles simultaneously may open to bidding down attacks. Therefore, such a mix of profile offer SHOULD NOT be made. Ott, Carrara Expires March 2004 [Page 11]
Internet Draft draft-ietf-avt-profile-savpf-00.txt 19 October 2003 AVPF makes packets larger than AVP. This has to be taken into consideration with respect to the number of keystream bits that can be generated for a given encryption transform in SRTP, to avoid keystream re-use. For the pre-defined SRTP transforms, see [SRTP] for maximum values. Note that the rules for sharing master keys apply as described in [7] (e.g., Section 9.1). [Editors' note: The last paragraph needs expansion; parts of SRTP should explicitly be spelled out here.] Different media sessions may use a mix of different profiles, particularly including a secure profile and an insecure profile. However, mixing secure and insecure media sessions may reveal information to third parties and thus the decision to do so MUST be in line with a local security policy. For example, the local policy MUST specify whether it is acceptable to have e.g. the audio stream not secured and the related video secured. The security considerations in [3] are valid too. Note in particular, applying the SAVPF profile implies mandatory integrity protection on RTCP. While this solves the problem of false packets from members not belonging to the group, it does not solve the issues related to a malicious member acting improperly. 6 IANA Considerations The following contact information shall be used for all registrations included here: Contact: Joerg Ott mailto:jo@acm.org tel:+49-421-201-7028 The secure RTP feedback profile as a combination of Secure RTP and the feedback profile needs to be registered for the Session Description Protocol (specifically the type "proto"): "RTP/SAVPF". SDP Protocol ("proto"): Name: RTP/SAVPF Long form: Secure RTP Profile with RTCP-based Feedback Type of name: proto Type of attribute: Media level only Purpose: RFC XXXX Reference: RFC XXXX Ott, Carrara Expires March 2004 [Page 12]
Internet Draft draft-ietf-avt-profile-savpf-00.txt 19 October 2003 All the SDP attribute defined for RTP/SAVP and RTP/AVPF are valid for RTP/SAVPF, too. NOTE TO THE RFC EDITOR: Please replace all occurrences of RFC XXXX by the RFC number assigned to this document. 7 Acknowledgements This document is a product of the Audio-Visual Transport (AVT) Working Group of the IETF. 8 Authors' Addresses Joerg Ott {sip,mailto}:jo@tzi.org Uni Bremen TZI tel:+49-421-201-7028 MZH 5180 Bibliothekstr. 1 D-28359 Bremen Germany Elisabetta Carrara mailto:elisabetta.carrara@ericsson.com Ericsson Research tel:+46-8-50877040 SE-16480 Stockholm Sweden 9 Bibliography 9.1 Normative references [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP - A Transport Protocol for Real-time Applications," RFC 3550, July 2003. [2] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control," RFC 3551, March 2003. [3] J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)," Internet Draft draft-ietf-avt-rtcp-feedback-07.txt, Work in Progress, June 2003. [4] M. Baugher, D. McGrew, E. Carrara, M. Natslund, K. Norrman, "The Secure Real-time Transport Protocol", Internet Draft draft-ietf-avt-srtp-09.txt, Work in Progress, July 2003. Ott, Carrara Expires March 2004 [Page 13]
Internet Draft draft-ietf-avt-profile-savpf-00.txt 19 October 2003 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, March 1997. [6] M. Handley, V. Jacobson, and Colin Perkins, "SDP: Session Description Protocol", Internet Draft draft-ietf-mmusic-sdp- new-14.txt, September 2004. [7] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. Norrman, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)," Internet Draft draft-ietf-mmusic-kmgmt-ext-09.txt, Work in Progress, October 2003. [8] F. Andreassen, M. Baugher, and D. Wing, "SDP Security Descriptions for Media Streams," Internet Draft draft-ietf- mmusic-sdescriptions-01.txt, Work in Progress, June 2003. [9] G. Camarillo, J. Holler, G. Eriksson, H. Schulzrinne, "Grouping of media lines in SDP," RFC 3388, December 2002. [10] J. Rosenberg and H. Schulzrinne, "An offer/answer model with SDP," RFC 3264, June 2002. [11] H. Schulzrinne, A. Rao, and R. Lanphier, "Real Time Streaming Protocol (RTSP)," RFC 2326, April 1998. 9.2 Informative References [12] M. Handley, C. Perkins, and E. Whelan, "Session Announcement Protocol," RFC 2974, October 2000. [13] B. Ramsdell (ed.), " S/MIME Version 3 Message Specification," RFC 2633, June 1999. [14] E.Rescorla, "HTTP Over TLS," RFC 2818, May 2000. 10 IPR Notice The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and Ott, Carrara Expires March 2004 [Page 14]
Internet Draft draft-ietf-avt-profile-savpf-00.txt 19 October 2003 standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 11 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Ott, Carrara Expires March 2004 [Page 15]
