--- 1/draft-ietf-mmusic-file-transfer-mech-09.txt 2009-01-22 12:12:05.000000000 +0100 +++ 2/draft-ietf-mmusic-file-transfer-mech-10.txt 2009-01-22 12:12:05.000000000 +0100 @@ -1,50 +1,60 @@ MMUSIC Working Group M. Garcia-Martin Internet-Draft Ericsson Intended status: Standards Track M. Isomaki -Expires: May 7, 2009 Nokia +Expires: July 26, 2009 Nokia G. Camarillo S. Loreto Ericsson P. Kyzivat Cisco Systems - November 3, 2008 + January 22, 2009 A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer - draft-ietf-mmusic-file-transfer-mech-09.txt + draft-ietf-mmusic-file-transfer-mech-10.txt 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. + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on May 7, 2009. + This Internet-Draft will expire on July 26, 2009. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Abstract This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred. The offerer can either describe the files it wants to send, or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file. The transfer @@ -64,47 +74,46 @@ 6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 8 7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 13 8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 14 8.1. The 'file-transfer-id' attribute . . . . . . . . . . . . . 14 8.2. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 17 8.2.1. The Offerer is a File Sender . . . . . . . . . . . . . 17 8.2.2. The Offerer is a File Receiver . . . . . . . . . . . . 18 8.2.3. SDP Offer for Several Files . . . . . . . . . . . . . 19 8.3. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 19 8.3.1. The Answerer is a File Receiver . . . . . . . . . . . 19 - 8.3.2. The Answerer is a File Sender . . . . . . . . . . . . 20 + 8.3.2. The Answerer is a File Sender . . . . . . . . . . . . 21 8.4. Aborting an ongoing file transfer operation . . . . . . . 22 8.5. Indicating File Transfer Offer/Answer Capability . . . . . 25 8.6. Re-usage of Existing "m=" Lines in SDP . . . . . . . . . . 26 8.7. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 26 8.8. Considerations about the 'file-icon' attribute . . . . . . 28 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 28 9.2. Offerer requests a file from the Answerer and second file transfer . . . . . . . . . . . . . . . . . . . . . . 33 9.3. Example of a capability indication . . . . . . . . . . . . 40 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 11.1. Registration of new SDP attributes . . . . . . . . . . . . 42 - 11.1.1. Registration of the file-selector attribute . . . . . 42 + 11.1.1. Registration of the file-selector attribute . . . . . 43 11.1.2. Registration of the file-transfer-id attribute . . . . 43 11.1.3. Registration of the file-disposition attribute . . . . 43 11.1.4. Registration of the file-date attribute . . . . . . . 43 11.1.5. Registration of the file-icon attribute . . . . . . . 44 11.1.6. Registration of the file-range attribute . . . . . . . 44 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 - 13.2. Informational References . . . . . . . . . . . . . . . . . 45 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 45 + 13.2. Informational References . . . . . . . . . . . . . . . . . 46 Appendix A. Alternatives Considered . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 - Intellectual Property and Copyright Statements . . . . . . . . . . 49 1. Introduction The Session Description Protocol (SDP) Offer/Answer [RFC3264] provides a mechanism for two endpoints to arrive at a common view of a multimedia session between them. These sessions often contain real-time media streams such as voice and video, but are not limited to that. Basically, any media component type can be supported, as long as there is a specification how to negotiate it within the SDP offer/answer exchange. @@ -790,22 +799,22 @@ file. When the file sender receives the SDP answer, if the port number of the answer for a file request is non-zero, the file sender starts the transfer of the file according to the negotiated parameters in SDP. 8.2.2. The Offerer is a File Receiver In a pull operation, the file receiver creates the SDP offer and sends it to the file sender. The file receiver MUST include a 'file- - selector' attribute and SHOULD add, at least, one of the selector - defined for that attribute (i.e., 'name', 'type', 'size', or 'hash'). + selector' attribute and MUST include, at least, one of the selectors + defined for such attribute (i.e., 'name', 'type', 'size', or 'hash'). In many cases, if the hash of the file is known, that is enough to identify the file, therefore, the offerer can include only a 'hash' selector. However, specially in cases where the hash of the file is unknown, the file name, size, and type can provide a description of the file to be fetched. If the file receiver wishes to start a new file transfer it MUST add a 'file-transfer-id' attribute containing a new globally unique random value. The file receiver MAY also add a 'file-range' attribute indicating the start and stop offsets of the file. There is no need to for the file receiver to include further file attributes in the SDP offer, thus it is RECOMMENDED that SDP @@ -817,21 +826,24 @@ When the file receiver receives the SDP answer, if the port number of the answer for a file request is non-zero, then the file receiver should receive the file using the protocol indicated in the "m=" line. If the SDP answer contains a supported hashing algorithm in the 'hash' selectors of the 'file-selector' attribute, then the file receiver SHOULD compute the hash of the file after its reception and check it against the hash received in the answer. In case the computed hash does not match the one contained in the SDP answer, the file receiver SHOULD consider that the file transfer failed and - SHOULD inform the user. + SHOULD inform the user. Similarly, the file receiver SHOULD also + verify that the other selectors declared in the SDP match the file + properties, otherwise, the file receiver SHOULD consider that the + file transfer failed and SHOULD inform the user. 8.2.3. SDP Offer for Several Files An offerer that wishes to send or receive more than one file generates an "m=" line per file along with the file attributes described in this specification. This way, the answerer can reject individual files by setting the port number of their associated "m=" lines to zero, as per regular SDP [RFC4566] procedures. Similarly, the answerer can accept each individual file separately by setting the port number of their associated "m=" lines to non-zero value. @@ -864,48 +876,57 @@ the port number is different than zero, the file receiver inspects the 'file-transfer-id' attribute. If the value of the 'file- transfer-id' attribute has been previously used then the existing session remains without changes, perhaps the file transfer is still in progress, or perhaps it has concluded, but there are no change with respect the current status. In any case, independently of the port number, the SDP answerer creates a regular SDP answer and sends it to the offerer. If the port number is different than zero and the SDP offer contains - a new 'file-transfer-id' attribute, then this signals a request for a - new file transfer. The SDP answerer extracts the attributes and - parameters that describe the file and typically requests permission - from the user to accept or reject the reception of the file. If the - file transfer operation is accepted, the file receiver MUST create an - SDP answer according to the procedures specified in RFC 3264 - [RFC3264]. If the offer contains 'name', 'type', 'size' selectors in - the 'file-selector' attribute, the answerer MUST copy them into the - answer. The file receiver copies the value of the 'file-transfer-id' - attribute to the SDP answer. Then the file receiver MUST add a - session or media 'recvonly' attribute according to the procedures - specified in RFC 3264 [RFC3264]. The file receiver MUST NOT include - 'file-icon', 'file-disposition', or 'file-date' attributes in the SDP - answer. + a new 'file-transfer-id' attribute, then it is signaling a request + for a new file transfer. The SDP answerer extracts the attributes + and parameters that describe the file and typically requests + permission from the user to accept or reject the reception of the + file. If the file transfer operation is accepted, the file receiver + MUST create an SDP answer according to the procedures specified in + RFC 3264 [RFC3264]. If the offer contains 'name', 'type', 'size' + selectors in the 'file-selector' attribute, the answerer MUST copy + them into the answer. The file receiver copies the value of the + 'file-transfer-id' attribute to the SDP answer. Then the file + receiver MUST add a session or media 'recvonly' attribute according + to the procedures specified in RFC 3264 [RFC3264]. The file receiver + MUST NOT include 'file-icon', 'file-disposition', or 'file-date' + attributes in the SDP answer. The file receiver can use the hash to find out if a local file with the same hash is already available, in which case, this could imply the reception of a duplicated file. It is up to the answerer to determine whether the file transfer is accepted or not in case of a duplicated file. If the SDP offer contains a 'file-range' attribute and the file receiver accepts to receive the range of octets declared in there, the file receiver MUST include a 'file-range' attribute in the SDP answer with the same range of values. If the file receiver does not accept the reception of that range of octets, it SHOULD reject the transfer of the file. + When the file transfer operation is complete, the file receiver + computes the hash of the file and SHOULD verify that it matches the + hash declared in the SDP. If they do not match, the file receiver + SHOULD consider that the file transfer failed and SHOULD inform the + user. Similarly, the file receiver SHOULD also verify that the other + selectors declared in the SDP match the file properties, otherwise, + the file receiver SHOULD consider that the file transfer failed and + SHOULD inform the user. + 8.3.2. The Answerer is a File Sender In a pull operation the answerer is the file sender. In this case, the SDP answerer MUST first inspect the value of the 'file-transfer-id' attribute. If it has not been previously been used throughout the session, then acceptance of the file MUST provoke the transfer of the file over the negotiated protocol. However, if the value has been previously used by another file transfer operation within the session, then the file sender MUST NOT alert the user and MUST NOT start a new transfer of the file. No matter whether an @@ -1772,29 +1793,40 @@ The SDP attributes defined in this specification identify a file to be transferred between two endpoints. An endpoint can offer to send the file to the other endpoint or request to receive the file from the other endpoint. In the former case, an attacker modifying those SDP attributes could cheat the receiver making it think that the file to be transferred was a different one. In the latter case, the attacker could make the sender send a different file than the one requested by the receiver. Consequently, it is RECOMMENDED that integrity protection be applied to the SDP session descriptions carrying the attributes specified in this specification. + Additionally, it is RECOMMENDED that senders verify the properties of + the file against the selectors that describe it. The descriptions of the files being transferred between endpoints may reveal information the endpoints may consider confidential. Therefore, it is RECOMMENDED that SDP session descriptions carrying the attributes specified in this specification are encrypted. TLS and S/MIME are the natural choices to provide offer/answer exchanges with integrity protection and confidentiality. + When an SDP offer contains the description of a file to be sent or + received, the SDP answerer MUST first authenticate the SDP offerer + and then it MUST authorize the file transfer operation, typically + according to a local policy. Typically these functions are + integrated in the high-level protocol that carries SDP (e.g., SIP), + and in the file transfer protocol (e.g., MSRP). If SIP [RFC3261] and + MSRP [RFC4975] are used, the standard mechanisms for user + authentication and authorization are sufficient. + It is possible that a malicious or misbehaving implementation tries to exhaust the resources of the remote endpoint, e.g., the internal memory or the file system, by sending very large files. To protect from this attack, an SDP answer SHOULD first verify the identity of the SDP offerer, and perhaps only accept file transfers from trusted sources. Mechanisms to verify the identity of the file sender depend on the high-level protocol that carries the SDP, for example, SIP [RFC3261] and MSRP [RFC4975]. It is also RECOMMENDED that implementations take measures to avoid @@ -1905,22 +1937,23 @@ Specification: RFC XXXX 12. Acknowledgements The authors would like to thank Mats Stille, Nancy Greene, Adamu Haruna, and Arto Leppisaari for discussing initial concepts described in this memo. Thanks to Pekka Kuure for reviewing initial versions this document and providing helpful comments. Joerg Ott, Jiwey Wang, Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis- Courmont, Colin Perkins, Sudhakar An, Peter Saint-Andre, Jonathan - Rosenberg, Eric Rescorla, Vikram Chhibber, and Ben Campbell discussed - and provided comments and improvements to this document. + Rosenberg, Eric Rescorla, Vikram Chhibber, Ben Campbell, and Richard + Barnes discussed and provided comments and improvements to this + document. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message @@ -2104,50 +2136,10 @@ Email: Salvatore.Loreto@ericsson.com Paul H. Kyzivat Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA Email: pkyzivat@cisco.com - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - 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. - - 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, THE IETF TRUST 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. - -Intellectual Property - - 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.