Network WG L. Dondeti
Internet-Draft QUALCOMM, Inc.
Expires: December 21, 2006 June 19, 2006
MIKEYv2: SRTP Key Management using MIKEY, revisited
draft-dondeti-msec-rtpsec-mikeyv2-00
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.
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 December 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
We specify a new version of the Multimedia Internet Keying (MIKEY)
protocol, MIKEYv2, tailored for the secure real-time transport
protocol (SRTP). MIKEYv2 uses the same payloads and message formats
as MIKEY; it supports mode negotiation, uses either SDP in the
signaling path or UDP for transport, does not require time
synchronization, and does not need SIP support for accessing end-
point credentials.
Editor's note
Dondeti Expires December 21, 2006 [Page 1]
Internet-Draft MIKEYv2 June 2006
This is a strawman proposal of the MIKEYv2 protocol. The protocol as
specified in this document is broken in several different ways: the
security of the protocol, the payload formats of RFC 3830 not quite
agreeing with the vision of the author to begin with and perhaps in
other ways. This will first be discussed with interested parties to
hash out the details and a revision will be submitted at the latest
before the Montreal IETF meeting in July 2006. Please feel free to
send reviews to ldondeti@qualcomm.com, but it might be better to hold
judgement until the revision appears.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SRTP key management design goals, constraints and use cases . 4
3.1. SRTP use cases . . . . . . . . . . . . . . . . . . . . . . 5
3.2. SRTP key management design goals and constraints . . . . . 5
3.3. SRTP cryptographic context . . . . . . . . . . . . . . . . 7
3.4. SRTCP crypto context . . . . . . . . . . . . . . . . . . . 8
4. MIKEYv2 outline . . . . . . . . . . . . . . . . . . . . . . . 8
5. MIKEYv2 protocol details . . . . . . . . . . . . . . . . . . . 9
5.1. Initial exchange . . . . . . . . . . . . . . . . . . . . . 9
5.2. Create crypto context exchange . . . . . . . . . . . . . . 11
5.3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. Transporting MIKEYv2 Messages . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Dondeti Expires December 21, 2006 [Page 2]
Internet-Draft MIKEYv2 June 2006
1. Introduction
The Multimedia Internet Keying (MIKEY) [RFC3830] protocol is a key
management protocol for SRTP. It's a half or one round trip
authentication and key delivery/establishment protocol that uses
timestamps for replay protection, and asymmetric or symmetric keys
for entity authentication. MIKEY is a general purpose efficient key
management protocol for real-time applications, but has been designed
with SRTP key establishment as the primary application.
MIKEY supports point-to-point as well as group key establishment and
is the protocol of choice in other standards development
organizations: for instance, the 3GPP Multimedia Broadcast and
Multicast Service (MBMS) uses MIKEY for session key establishment via
unicast and traffic key establishment and update via broadcast. 3GPP
uses the IANA assigned UDP port 2269 for MIKEY transport. The Open
Mobile Alliance (OMA)'s Broadcast (BCAST) specification uses MIKEY to
transport the long and short term key messages.
However, several shortcomings of MIKEY have been identified,
especially on its applicability to general purpose key management for
VoIP application.
MIKEY has too many modes and no real support for mode negotiation.
While MIKEY can finish in half or one round trip, it requires time
synchronization to do so.
MIKEY, as specified in RFC 3830 [RFC3830] requires SDP for
transport. This is disadvantageous for MIKEY modes that require
more than one message.
There are two MIKEY modes that require one message:
The RSA mode requires that the Initiator of the protocol know
the identity and certificate of the recipient, and the PSK mode
requires that the Initiator share a PSK with the Responder.
This is simply not a practical assumption; furthermore, in case
of SIP forking and call forwarding, MIKEY-RSA and MIKEY-PSK
modes do not work.
There are MIKEY modes that can handle SIP forking and call
forwarding; however, they cannot handle RTP early media very well.
While there are solutions like security preconditions to help
alleviate the early media case, those solutions might not be
widely deployed or even if deployed will cause unnecessary delay
in SRTP context establishment.
Dondeti Expires December 21, 2006 [Page 3]
Internet-Draft MIKEYv2 June 2006
The discussion so far provides sufficient motivation to develop
alternative protocols for SRTP. To that end several proposals have
been made: zRTP, DTLS-SRTP are among them. While these solve some of
the problems of MIKEY discussed earlier, introduce issues of their
own and leave open several problems. For instance,
zRTP requires a large number of round trips, uses RTP to carry key
management messages, and supports SRTP context establishment for
unicast communication alone. MIKEY messages can just as easily be
carried within RTP, whereas MIKEY requires few round trips and
supports unicast and group key management.
DTLS-SRTP uses UDP for transport, but has limited support for SRTP
context establishment. For instance, each SRTP stream requires a
separate DTLS session. Like zRTP, DTLS-SRTP supports point-to-
point communication only.
With this background, we propose MIKEYv2, extending MIKEY along the
lines of the IKEv2 [RFC4306], given the lessons learned in the
process of implementing and deploying MIKEY.
Below is a list of properties of MIKEYv2:
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 [RFC2119].
In addition, we use the terminology in the MIKEY [RFC3830] and SRTP
[RFC3711] specifications. Furthermore, we define the following
terms:
3. SRTP key management design goals, constraints and use cases
The primary goal of SRTP key management is to establish the
cryptographic context for SRTP encapsulation. In the rest of this
document, we refer to this as the SRTP crypto context. The
information includes, SRTP encryption and integrity protection keys,
cryptographic algorithms used, key lengths, initialization vectors
(IVs), salts and identifiers, and replay protection counters and
state information. The key management protocol is expected to
Dondeti Expires December 21, 2006 [Page 4]
Internet-Draft MIKEYv2 June 2006
bootstrap the SRTP crypto context, and so we delve into the details
of these parameters and explore how communicating parties might be
able to arrive at sharing the same crypto context. Note that the RTP
traffic may be flowing between two parties or from one to two or more
parties. In the following, we list SRTP use cases, design goals and
constraints, and describe SRTP and SRTCP cryptographic context.
3.1. SRTP use cases
We identify three simple use cases:
Unicast: In the first, there are one or more RTP sessions between two
communicating parties and session keys need to be derived for
them.
One-to-many Conferencing: In the second, there are one or more one-
to-many RTP sessions, all from one sender to two or more
receivers. Key distribution for such use cases, where one speaker
is delivering a lecture to an audience is of interest.
Many-to-many Conferencing: The final use case is multi-party
multimedia conferencing, where two or more speakers are
originators of RTP streams (one or more each) and two or more
receivers are recipients of those streams.
3.2. SRTP key management design goals and constraints
A key management protocol for SRTP should meet the following design
goals and constraints; [I-D.wing-rtpsec-keying-eval] provides a more
detailed description of some of these issues and how various proposed
key management protocols for SRTP address them.
Identity and Credential Transport: The protocol should allow the
Initiator and Responder to send each other's identities and
credentials to the other parties. This was for instance absent in
the MIKEY-RSA mode.
Mode Negotiation: The communicating parties should be able to
negotiate the mode of authentication.
Algorithm Agility: Cryptographic algorithm negotiation support to
help the communicating parties negotiate the use of the most
secure algorithms they both support. Note that in group
communication algorithm negotiation may not be possible; in that
case algorithm agility support is defined as the ability of the
group key manager to transition from one suite of algorithms to
another.
Dondeti Expires December 21, 2006 [Page 5]
Internet-Draft MIKEYv2 June 2006
Support for Multiple RTP Sessions: It is desirable for the key
management protocol to establish crypto context for more than one
RTP session between the same communicating parties in one run of
the protocol.
Unicast and Group Communication Support: It is desirable for the key
management protocol to support or be extensible to group security
context establishment. Whereas the predominant application in
circa 2006 might be point-to-point voice communications, it is
unattractive to having to develop a different key management
protocol for unicast communication and another for group
communication. Since unicast communication is the more popular
mode of communication, it makes sense to optimize for that use
case.
Rekeying Support: It is desirable for the key management protocol to
support rekeying in an efficient manner. In case of unicast
communication, rekeying might finish faster than initial crypto
context establishment process; more specifically, rekeying might
finish in a single round trip, whereas initial run of the protocol
might take two or more round trips. In case of group
communication, rekeying might allow communication of a new group
key with a single message from the group key manager to the
members.
Transport Requirements: SRTP key management messages can be
transported in one of three different ways: in the first, the
messages are sent as part of SDP over SIP. In that case, the
return message may arrive later than the media resulting in
clipping. This is because the media path is for the most part
faster than the signaling path, due to the many intermediate
entities involved in the signaling path. The second method of
transport is to use the bearer path. While the bearer path
transport might be more efficient than signaling path, the first
message may have to come from the answerer as opposed to the
offerer (this is because the offerer might not always know the
address of the answerer and because UDP port control may not allow
communications to pass through until the first signaling message
has made it to the answerer from the offerer). The third method
of transport is to send the key management messages as part of RTP
or RTCP packets, for instance in extension headers or with a new
transform to the RTP or RTCP packets.
SIP Constraints: In the following we describe some SIP related
constraints and design considerations:
Dondeti Expires December 21, 2006 [Page 6]
Internet-Draft MIKEYv2 June 2006
Clipping Media Before SDP Answer: RTP packets take a direct route
between the communicating parties, whereas the SIP packets pass
through various servers and gateways, resulting in RTP packets
arriving before SIP packets. Thus it is possible for RTP
packets from the answerer to the offerer to arrive before the
SDP answer via the signaling path, carrying a key management
protocol message required to decipher the RTP packets. This
results in the offerer to be not be able to play the media;
this is defined as clipping. It is desirable that the key
management protocol avoids clipping without the help of
external mechanisms.
Secure Retargeting and Secure Forking: In cases such as call
forwarding, a SIP message may reach a different party than
specified either in the SIP message or the key management
message. In most practical scenarios, it is ok to continue
secure session establishment with the new peer as long as the
peer is correctly identified and has appropriate credentials.
In forking the messages reach multiple parties and the multiple
parties might respond resulting potentially in multiple
sessions.
Perfect-forward Secrecy: In some applications, perfect forward
secrecy, defined as the property that past short-term keys or
session keys are not compromised due to a compromise of the long-
term keys or credentials, may be a desirable property.
Infrastructure Support: For some applications, a center or server may
have a PSK with each potential end-user, or there may be a PKI
support, but these assumptions are not valid in general. The key
management protocol should take this into account.
3.3. SRTP cryptographic context
The SRTP specification [RFC3711] identifies transform dependent and
transform independent parameters that comprise the crypto context.
The transform-dependent parameters are as follows:
encryption algorithm, e.g., AES-CTR, AES-f8, and associated key
length
integrity protection transform, e.g., TESLA or algorithm, e.g.,
HMAC-SHA1, associated key length and output length (e.g., MAC/ICV
truncation)
key derivation parameters
Dondeti Expires December 21, 2006 [Page 7]
Internet-Draft MIKEYv2 June 2006
input for IV formation
The transform-independent parameters are listed below:
32-bit unsigned rollover counter (RoC), which records how many
times the 16-bit RTP sequence number has been reset to zero after
passing through 65,535 (2^16-1),
for each master key, an SRTP stream MAY use the following
associated values:
a master salt, to be used in the key derivation of session
keys. Note that the master salt, MUST be random, but MAY be
public
an integer in the set {1,2,4,...,2^24}, the
"key_derivation_rate"; the key management protocol may leave
this unspecified and in that cast the key_derivation_rate is
assumed to be zero
a master key identifier (MKI) value to identify the SRTP crypto
context
The key management system may also specify the lifetime of the
crypto context with a range of SRTP packet indices, From and
To. The SRTP packet index is a 48-bit value formed by
concatenating the 32-bit RoC with the 16-bit RTP packet index.
3.4. SRTCP crypto context
SRTCP by default shares the crypto context with SRTP, except there is
no need to establish the rollover counter via key management as the
RTCP index is explicitly carried in each SRTCP packet,
A cryptographic context SHALL be uniquely identified by the triplet
context identifier:
context id = < SSRC, destination network address, destination
transport port number >
where the destination network address and the destination transport
port are the ones in the SRTP packet. It is assumed that, when
presented with this information, the key management returns a context
with the information as described in Section 3.2.
4. MIKEYv2 outline
Dondeti Expires December 21, 2006 [Page 8]
Internet-Draft MIKEYv2 June 2006
The proposal is to revise MIKEY with the intent of adding mode
negotiation and removing the time synchronization requirement, and
specify MIKEYv2. In addition, we will specify UDP transport for
MIKEYv2, borrowing from the original proposal, which at one time did
contain the semantics for UDP transport.
MIKEYv2 reuses MIKEY payloads and introduces as few new payloads as
possible to facilitate the revised design and the new features.
MIKEYv2 messages use version number 0x02 in the common HDR payload
specified in RFC3830. Version number 0x02 is reserved for messages
described in this specification. Reuse of that version number is
allowed only with a revision of this specification.
MIKEYv2 takes two round trips to complete and establishes unicast and
optionally group SRTP and/or SRTCP crypto contexts. We reuse the key
derivation and traffic key containers defined in RFC3830. The
payloads and message structure while retained, are essentially part
of a new key management protocol and need a fresh security analysis.
MIKEYv2 is a DH-based key management protocol based on SIGMA. In the
first round trip, the communicating parties learn each other's
identities, agree on a MIKEY mode (type of entity authentication
primarily), MIKEY crypto algorithms, SRTP policy, and exchange nonces
for replay protection. In the second round trip, they negotiate
unicast and/or group SRTP crypto context for SRTP and/or SRTCP.
5. MIKEYv2 protocol details
MIKEYv2 has two sets of exchanges. The initial exchange consists of
identity establishment, MIKEY mode and algorithm negotiation and the
second exchange consists of SRTP and SRTCP crypto context
establishment.
5.1. Initial exchange
Dondeti Expires December 21, 2006 [Page 9]
Internet-Draft MIKEYv2 June 2006
MIKEYv2_INIT_EXCH message is as follows:
Initiator Responder
========= =========
HDR, RANDi, M-SPi, IDi,
[IDr], DHi --->
<--- HDR, RANDr, M-SPr, IDr,
[CERTREQ,] DHr
Figure 1: MIKEYv2 negotiation exchange
MIKEYv2 is closely modeled after IKEv2 [RFC4306] and relies on the
SIGMA protocol for its security. The payloads, at least most of
them, are reused from the original MIKEY specification, in the
interest of code reuse (and potential backward compatibility. This
is for further discussion and study).
MIKEYv2_INIT_EXCH is a Diffie-Hellman exchange, which allows the two
parties to establish an unauthenticated secure channel.
There is no identity protection as it is specified currently, but
that can be added easily. SIGMA provides some identity protection to
the Initiator's or the Responder's identities.
The M-SPi payloads allow mode and algorithm negotiation for the
secure channel. These payloads are intended to be used to negotiate
the algorithm used in generating the AUTH and KEMAC paylods of the
MIKEYv2 SRTP Cryptographic Context Establishment Exchange or
MIKEYv2_SRTP_CCE.
In the second message, the Responder can request that Certificates be
used for entity authentication. The proposal is to allow negotiation
of this via the M-SPi payload.
The RAND paylods provide replay protection and are used to provide
entropy for key derivation in the unicast case.
Dondeti Expires December 21, 2006 [Page 10]
Internet-Draft MIKEYv2 June 2006
5.2. Create crypto context exchange
MIKEYv2_SRTP_CCE message is as follows:
Unicast case:
=============
Initiator Responder
========= =========
HDR, [CERTi,] [CERTREQ,]
SRTP-SPi, AUTH --->
<--- HDR, [CERTr,] SRTP-SPr
AUTH
Group key establishment:
========================
Initiator Group Controller
========= ================
HDR, [CERTi,] [CERTREQ,]
GCC-REQ, AUTH --->
<--- HDR, [CERTr,] SRTP-SPg
AUTH, KEMAC
Figure 2: MIKEYv2 SRTP Crypto Context Establishment
The key material derived in the MIKEYv2_INIT_EXCH is used to protect
the messages/payloads of MIKEYv2_SRTP_CCE. The purpose of this
exchange is to authenticate the first exchange via the AUTH payloads
computed in a manner similar to that in RFC 4306 [RFC4306] and to
negotiate or distribute the SRTP crypto context.
5.3. Rekeying
5.4. Transporting MIKEYv2 Messages
MIKEYv2 messages are transported via UDP using IANA assigned port
2269.
6. Security Considerations
Dondeti Expires December 21, 2006 [Page 11]
Internet-Draft MIKEYv2 June 2006
7. IANA Considerations
Several IANA registrations may be required, include MIKEY version
number and new payload types. Detailed instructions to IANA will be
included in a future version.
8. Acknowledgments
This work benefited from discussions with various folks at the IETF,
among them are Flemming Andreasan, Francois Audet, Rolf Blom, Ran
Canetti, Steffen Fries, Dragan Ignjatic, Cullen Jennings, David
McGrew, Karl Norrman, Jon Peterson, Rohan Mahy, and Dan Wing. Note
that these folks may not necessarily be endorsing the MIKEYv2
protocol; in fact, it is plausible many of them do not even like the
protocol.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
9.2. Informative References
[I-D.ietf-msec-mikey-ecc]
Milne, A., "ECC Algorithms For MIKEY",
draft-ietf-msec-mikey-ecc-00 (work in progress),
February 2006.
[I-D.ietf-msec-mikey-rsa-r]
Ignjatic, D., "An additional mode of key distribution in
MIKEY: MIKEY-RSA-R", draft-ietf-msec-mikey-rsa-r-06 (work
in progress), June 2006.
[I-D.ietf-msec-mikey-applicability]
Fries, S. and D. Ignjatic, "On the applicability of
various MIKEY modes and extensions",
draft-ietf-msec-mikey-applicability-01 (work in progress),
June 2006.
[I-D.ietf-msec-mikey-dhhmac]
Dondeti Expires December 21, 2006 [Page 12]
Internet-Draft MIKEYv2 June 2006
Euchner, M., "HMAC-authenticated Diffie-Hellman for
MIKEY", draft-ietf-msec-mikey-dhhmac-11 (work in
progress), April 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[I-D.wing-rtpsec-keying-eval]
Audet, F. and D. Wing, "Evaluation of SRTP Keying with
SIP", draft-wing-rtpsec-keying-eval-00 (work in progress),
June 2006.
Dondeti Expires December 21, 2006 [Page 13]
Internet-Draft MIKEYv2 June 2006
Author's Address
Lakshminath Dondeti
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-1267
Email: ldondeti@qualcomm.com
Dondeti Expires December 21, 2006 [Page 14]
Internet-Draft MIKEYv2 June 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Dondeti Expires December 21, 2006 [Page 15]