Internet DRAFT - draft-harrison-avt-rtpkeys
draft-harrison-avt-rtpkeys
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]
