Network WG L. Dondeti
Internet-Draft QUALCOMM, Inc.
Intended status: Standards Track March 5, 2007
Expires: September 6, 2007
MIKEYv2: SRTP Key Management using MIKEY, revisited
draft-dondeti-msec-rtpsec-mikeyv2-01
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 September 6, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The Multimedia Internet Keying (MIKEY) protocol is a general purpose
key management protocol; it is used especially for key management for
secure RTP. We specify a couple of variations of that protocol to
support mode negotiation, media path key establishment and other
assorted requirements.
Dondeti Expires September 6, 2007 [Page 1]
Internet-Draft MIKEYv2 March 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation to Designing MIKEYv2 . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. SRTP Key Management Design Goals, Constraints and Use Cases . 5
3.1. SRTP Use Cases . . . . . . . . . . . . . . . . . . . . . . 5
3.2. SRTP Cryptographic Context . . . . . . . . . . . . . . . . 6
3.3. SRTCP Crypto Context . . . . . . . . . . . . . . . . . . . 6
4. MIKEYv2 Outline . . . . . . . . . . . . . . . . . . . . . . . 7
5. MIKEYv2 Protocol Details: Option 1 . . . . . . . . . . . . . . 8
5.1. Initial Exchange . . . . . . . . . . . . . . . . . . . . . 8
5.2. Create Crypto Context Exchange . . . . . . . . . . . . . . 9
6. MIKEYv2 Protocol Details: Option 2 . . . . . . . . . . . . . . 10
6.1. MIKEY Mode Negotiation Exchange . . . . . . . . . . . . . 10
6.2. MIKEY-RSA/PSK Exchange . . . . . . . . . . . . . . . . . . 10
7. Transporting MIKEYv2 Messages . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Dondeti Expires September 6, 2007 [Page 2]
Internet-Draft MIKEYv2 March 2007
1. Introduction
The Multimedia Internet Keying (MIKEY) [RFC3830] protocol is a
general purpose key management protocol for real-time applications,
especially 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 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.
It requires time synchronization for replay protected.
MIKEY, as specified in RFC 3830 [RFC3830] requires SDP for
transport.
MIKEY-RSA mode requires that the Initiator of the protocol know
the identity and certificate of the recipient. This mode does not
handle SIP forking well.
MIKEY-PSK mode requires that the Initiator share a PSK with the
Responder. This is simply not a practical assumption. This mode
also does not handle SIP forking well.
MIKEY-RSA-R does not handle early media well. Early media may
arrive before the SDP answer arrives.
Next, after some debate and discussion at the IETF, there is a
consensus on some of the requirements for a common key management
protocol for an application such as VoIP so there is a chance for
cross-domain interoperability. The idea is to come up with a single
protocol for key management for SRTP.
However, given the variety of constraints and use cases, it may not
be possible to have a single universal key management protocol for
Dondeti Expires September 6, 2007 [Page 3]
Internet-Draft MIKEYv2 March 2007
SRTP. Many of the devices that will need to implement the protocol
are resource-constrained and some of them have one of the candidate
protocols or their close cousins already implemented. There may be
resistance to implement another protocol. Next some of the
requirements may force resource-intensive computations, especially
when there is SIP forking; a PSTN gateway may not be able to perform
several DH computations per session.
1.1. Motivation to Designing MIKEYv2
There are at least two candidates for key management for SRTP, namely
DTLS-SRTP and zRTP other than MIKEYv2. Considering the goal of
specifying a single protocol, it makes sense to not design a new
protocol. So the question is why design MIKEYv2? We consider that
question in detail below:
First, MIKEY [RFC3830] was designed with SRTP as the primary
application and has taken into account a number of design
considerations. It is as good a candidate for reuse as any. None
of the shortcomings listed earlier are inherent to MIKEY. In the
end, just as any other candidate key management protocol it can be
extended to meet the requirements at hand.
Next, MIKEY is the key management protocol for SRTP for other use
cases such as broadcast key management. MIKEY is (planned to be)
implemented in a smartcard, which is typically the device with
which 3GPP and 3GPP2 operators share credentials with. The
question may be whether it is difficult to implement TLS or DTLS
on the smartcard. Difficult? Yes. Improbable, no! There are
known implementations of TLS on a smartcard. It is definitely
wasteful to have to implement two different protocols for key
management for SRTP on the same device, and especially on a
smartcard.
Finally, the current designs of some of the candidate protocols
seem to indicate that negotiation of SRTP parameters may have to
be split between the key management protocol and SDP. It is not
clear whether there is an inherent shortcoming in the key
management protocol or not. Furthermore, session reestablishment
semantics seem less than optimal. There is also no support for
group keying; whereas shared key conferencing is not a consensus
requirement, broadcast/multicast using SRTP is a known use case
today. Thus, it may be better to explore other options for key
management for SRTP.
With this background, we propose MIKEYv2. We consider two possible
designs: the first is to extend MIKEY along the lines of the IKEv2
[RFC4306], taking into account the lessons learned in the process of
Dondeti Expires September 6, 2007 [Page 4]
Internet-Draft MIKEYv2 March 2007
implementing and deploying MIKEY. The second is to simply add mode
negotiation to base MIKEY exchanges limiting modifications to MIKEY
to an absolute minimum.
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.
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
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 group communication: In the second, there are one or
more one-to-many RTP sessions, all from one sender to two or more
receivers.
Many-to-many group communication: 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.
Dondeti Expires September 6, 2007 [Page 5]
Internet-Draft MIKEYv2 March 2007
3.2. 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; integrity algorithm,
e.g., HMAC-SHA1, associated key length and output length (e.g.,
MAC/ICV truncation)
key derivation parameters (e.g., PRF algorithm)
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.3. 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,
Dondeti Expires September 6, 2007 [Page 6]
Internet-Draft MIKEYv2 March 2007
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
MIKEYv2 supports mode negotiation, allows fast session
reestablishment using reduced roundtrip exchanges, but does not
require time synchronization.
MIKEYv2 runs over UDP (reusing the port number assigned for MIKEY) or
over RTP/RTCP.
It may be plausible to specify starting MIKEYv2 over the signaling
path and resume it via the media path (Steffen Fries talked about
this at various times).
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/or 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.
For fast session reestablishment, it is plausible to use one of the
RFC 3830 MIKEY exchange.
MIKEYv2 can also take advantage of the SAS technique introduced by
zRTP or the certificate fingerprint transport via SDP as described in
the context of DTLS-SRTP.
We explore two possible approaches to designing MIKEYv2:
Dondeti Expires September 6, 2007 [Page 7]
Internet-Draft MIKEYv2 March 2007
MIKEYv2 is an authenticated DH 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, 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.
The second option is to simply add mode negotiation to MIKEY
exchanges.
5. MIKEYv2 Protocol Details: Option 1
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
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 Policy 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
Dondeti Expires September 6, 2007 [Page 8]
Internet-Draft MIKEYv2 March 2007
that can be added easily. SIGMA provides some identity protection to
the Initiator's or the Responder's identities.
The M-SPi payloads allow MIKEY 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.
5.2. Create Crypto Context Exchange
MIKEYv2_SRTP_CCE message is as follows:
Unicast case:
=============
Initiator Responder
========= =========
HDR, [CERTi,] [CERTREQ,]
SRTP-SPi, AUTH, KEMAC --->
<--- HDR, [CERTr,] SRTP-SPr
AUTH, KEMAC
Group key establishment:
========================
Initiator Group Controller
========= ================
HDR, [CERTi,] [CERTREQ,]
GCC-REQ, AUTH, KEMAC --->
<--- HDR, [CERTr,] SRTP-SPg
AUTH, KEMAC
Figure 2: MIKEYv2 SRTP Crypto Context Establishment
Dondeti Expires September 6, 2007 [Page 9]
Internet-Draft MIKEYv2 March 2007
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 via the SRTP-SP
payloads. The KEMAC payloads in the unicast case do not necessarily
contain keys, but the MAC portion of KEMAC integrity protects the
entire message. The KEMAC payload sent by the Group Controller MUST
contain keys.
6. MIKEYv2 Protocol Details: Option 2
6.1. MIKEY Mode Negotiation Exchange
MIKEYv2_MODE_NEG_EXCH message is as follows:
Initiator Responder
========= =========
HDR, RANDi, M-SPi, IDi,
[IDr], DHi --->
<--- HDR, RANDr, M-SPr, IDr,
[CERTREQ,] DHr
Figure 3: MIKEYv2 Mode Negotiation Exchange
6.2. MIKEY-RSA/PSK Exchange
MIKEYv2_CCE2 message is as follows:
Initiator Responder
========= =========
HDR, T, RAND, {SP}, KEMAC,
[CHASH], [PKE, SIGNi] --->
<--- HDR, T, IDr, [V],
[PKE, SIGNr]
Figure 4: MIKEYv2 SRTP Crypto Context Establishment Exchange
Dondeti Expires September 6, 2007 [Page 10]
Internet-Draft MIKEYv2 March 2007
The idea here is to authenticate the initial exchange as part of the
SIGNx payload and provide a proof of possession of the key derived
using the DH exchange via the KEMAC and the V payload. These
processing semantics are slightly different from that of RFC 3830.
Note that these exchanges are shown to given an idea on how MIKEY may
be reused; the details are TBD. The T payload contains a sequence
number instead of a timestamp (note that the 3GPP MBMS specification
also uses a sequence number instead of a timestamp in the exchange).
The CCE exchange may be used for 1 RT rekeying. The timestamp field
contains a monotonically increasing sequence number (and serves a
similar purpose as the message-id field of IKEv2 [RFC4306]).
7. Transporting MIKEYv2 Messages
MIKEYv2 messages may be transported via UDP using IANA assigned port
2269. Alternatively, MIKEYv2 messages may share the RTP/RTCP port
with media/control packets. In the end, we may allow one option of
this based on consensus.
8. Security Considerations
Security considerations of RFC 3830 apply. For Option 1, security
considerations of RFC 4306 also apply.
9. 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.
10. 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.
11. References
Dondeti Expires September 6, 2007 [Page 11]
Internet-Draft MIKEYv2 March 2007
11.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.
11.2. Informative References
[I-D.ietf-msec-mikey-ecc]
Milne, A., "ECC Algorithms for MIKEY",
draft-ietf-msec-mikey-ecc-01 (work in progress),
October 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-07 (work
in progress), August 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-03 (work in progress),
December 2006.
[I-D.ietf-msec-mikey-dhhmac]
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-02 (work in progress),
February 2007.
[I-D.wing-media-security-requirements]
Wing, D., "Media Security Requirements",
draft-wing-media-security-requirements-00 (work in
progress), October 2006.
Dondeti Expires September 6, 2007 [Page 12]
Internet-Draft MIKEYv2 March 2007
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 September 6, 2007 [Page 13]
Internet-Draft MIKEYv2 March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Dondeti Expires September 6, 2007 [Page 14]