Network Working Group C. Harrison Internet-Draft Far Field Associates, LLC Expires: October 26, 2001 April 27, 2001 RTP Payload Format for Keying-Information Stream (KS) draft-harrison-avt-rtpkeys-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 October 26, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract [Note: This draft is preliminary and is believed to contain errors and omissions.] This memo describes an RTP payload format (KS) which transports cryptographic key information for encrypted media streams. The media streams themselves are transported independently, and may or may not be carried by RTP. The KS payload format makes particular provision for media carried by SRTP [4]. The payload carried over KS contains the information necessary for seamlessly applying new decryption keys during an active session, by means of byte-granularity pointers referencing into the protected stream. The KS payload is based on CMS [2] and is scalable to a wide variety of streaming media Harrison Expires October 26, 2001 [Page 1] Internet-Draft KS Keystream Payload Format April 2001 applications, from lightweight wireless terminals to broadband video- on-demand. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scenarios of Use . . . . . . . . . . . . . . . . . . . . . . . 4 3. KS Messages . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Packet Structure . . . . . . . . . . . . . . . . . . . . . . . 7 5. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 Harrison Expires October 26, 2001 [Page 2] Internet-Draft KS Keystream Payload Format April 2001 1. Introduction The RTP [1] protocol was developed for multimedia teleconference applications and provides a flexible framework for transporting multimedia content over the Internet. In the existing RTP model, there is some provision for cryptographic protection (confidentiality), but key management is assumed to be "out of band" and is not standardized. The absence of standardization has hindered interoperability. Furthermore, existing practice in other broadband media delivery environments calls for the ability to seamlessly change cryptographic keys during a session. This capability demands a closer real-time linkage between the keying information and the media stream than any IETF standard has provided. This document defines a payload format which may overcome the interoperability problems of existing single-key-per-session applications in a low- overhead way, as well as extending RTP capabilities to the more sophisticated key management practices required by high-value content providers. Harrison Expires October 26, 2001 [Page 3] Internet-Draft KS Keystream Payload Format April 2001 2. Scenarios of Use Wireless mobile voice: Low bandwidth, low compute power in terminal, high error rate. Runs with AMR or AMR-WB voice codec. Mostly unicast. Probably one key per session. Video/music on demand: High bandwidth. Some unicast, some multicast. Free-preview models. slow/rapid key updating schedule (up to ~ 1 keychange/sec). High latency tolerable. May use partial-stream encryption, even sub-packet granularity. Secure teleconference: High bandwidth. Multicast. Hop-on's need keys fairly quickly. Low key change rate. Low latency (interactive). Harrison Expires October 26, 2001 [Page 4] Internet-Draft KS Keystream Payload Format April 2001 3. KS Messages The KS payload is carried by a "control"-type RTP stream with a distinct Synchronizing Source (SSRC) identifier. Each packet of the KS stream is a KS message containing information about 1. The value of a particular cyrptographic key 2. The identity of the stream protected by this key (use SSRC+portnum for RTP/SRTP? Support other methods for non-RTP -- e.g. MPEG-n) 3. The point in this stream at which this key becomes effective (Use extended packet numbering system from SRTP [4]. Support alternative pointer method for vanilla RTP and non-RTP transports.) 4. The number of subsequent bytes to which this key applies 5. (OPTIONAL) An identifier supporting local storage and re-use of this key ("key carousel") This message complies with the Cryptographic Message Syntax CMS [2] and contains an object of type EnvelopedData. The value of the media-protecting key (item 1 above) MUST be contained in an item of RecipientInfo type, and may be hidden by a key-transfer, key- agreement, or key-encrypting-key method. The encryptedContentInfo field of the message SHALL contain the ContentType id-encryptedData and SHALL contain the ContentEncryptionAlgorithmIdentifier identifying the method used to encrypt the protected media stream. The encryptedContent field SHALL be empty. The remaining items in the list above are carried in the EnvelopedData item within a single "unprotectedAttrs" item. More work here... Need to define an OID for this attribute type. It will have substructure for stream ID, byte pointer, etc. Here's some pidgin ASN.1: -- a DetachedDataPointer attribute is included in the -- unprotectedAttrs field of the EnvelopedData message DetachedDataPointer ::= SEQUENCE { stream StreamIdentifier, pointer StreamDataPointer, effectivity DataZones, carousel-addr CarouselAddr OPTIONAL } Harrison Expires October 26, 2001 [Page 5] Internet-Draft KS Keystream Payload Format April 2001 StreamIdentifier ::= SEQUENCE { streamType StreamType, identifier ANY DEFINED BY streamType } RtpIdentifier ::= SEQUENCE { ssrc INTEGER, portnum INTEGER } StreamDataPointer ::= SEQUENCE { pointerType StreamDataPointerType, pointer ANY DEFINED BY pointerType } SrtpPointer ::= SEQUENCE { packetIndex INTEGER, byteOffset INTEGER } -- packetIndex is i = 65,536 * r + s, per SRTP DataZones ::= SET OF DataZone DataZone ::= SEQUENCE { bytesToProcess INTEGER, bytesToSkip [0] IMPLICIT INTEGER OPTIONAL } CarouselAddr ::= OCTET STRING -- This would be cross-ref'd by keyIdentifier in KEKRecipientInfo -- add this new "NULL-ish" algorithm id to use carousel'd keys; -- it would be used in KEKRecipientInfo with zero-length encryptedKey: id-alg-TheKeyIsTheData OBJECT IDENTIFIER The DetachedDataPointer attribute MAY be wrapped as EnvelopedData if the application wants to conceal these parameters. ... The entire KS EnvelopedData object described above MAY be encapsulated as SignedData in order to provide authentication of the KS message. Although the KS messages are fully-compliant CMS messages, a particular RTP Profile may define that only a limited number of the CMS features are used. Therefore an implementation complying with that RTP Profile MAY fail to comply with the requirements of a general CMS [2] implementation. This may be important, for example, when the processing power available on a particular platform is limited. Harrison Expires October 26, 2001 [Page 6] Internet-Draft KS Keystream Payload Format April 2001 4. Packet Structure The structure of an RTP packet in a KS stream is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC=0 |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | : KS message (per RFC2630) : | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Figure 1. KS Packet. Harrison Expires October 26, 2001 [Page 7] Internet-Draft KS Keystream Payload Format April 2001 5. SDP Parameters Parameters of a KS stream may be published to receiving applications by means of the Session Description Protocol (SDP) [3]. ...(incomplete) m=audio 1234 RTP/AVP 95 : dynamically assigned audio payload a=rtpmap:95 L16/48000/2 : stereo 48kHz : m=control 3456 RTP/AVP 99 : dynamically assigned payload type a=rtpmap:99 ks/1000 : KS with 1kHz ticks Harrison Expires October 26, 2001 [Page 8] Internet-Draft KS Keystream Payload Format April 2001 References [1] , ., Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [2] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. [3] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [4] Blom, R., "The Secure Real Time Transport Protocol", draft-ietf- avt-srtp-00 (work in progress), February 2001. Author's Address Chuck Harrison Far Field Associates, LLC 18815 111th Pl SE Snohomish, WA 98290 US Phone: +1 360 863 8340 EMail: chuck_harrison@iname.com Harrison Expires October 26, 2001 [Page 9] Internet-Draft KS Keystream Payload Format April 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Harrison Expires October 26, 2001 [Page 10]