MSEC S. Fries
Internet-Draft Siemens
Intended status: Informational D. Ignjatic
Expires: December 27, 2007 Polycom
June 25, 2007
On the applicability of various MIKEY modes and extensions
draft-ietf-msec-mikey-applicability-05.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.
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 27, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Fries & Ignjatic Expires December 27, 2007 [Page 1]
Internet-Draft MIKEY modes applicability June 2007
Abstract
Multimedia Internet Keying - MIKEY - is a key management protocol
that can be used for real-time applications. In particular, it has
been defined focusing on the support of the Secure Real-time
Transport Protocol. MIKEY itself is standardized within RFC3830 and
defines four key distribution methods. Moreover, it is defined to
allow extensions of the protocol. As MIKEY becomes more and more
accepted, extensions to the base protocol arose, especially in terms
of additional key distribution methods, but also in terms of payload
enhancements.
This document provides an overview about the MIKEY base document in
general as well as the existing extensions for MIKEY, which have been
defined or are in the process of definition. It is intended as
additional source of information for developers or architects to
provide more insight in use case scenarios and motivations as well as
advantages and disadvantages for the different key distribution
schemes. The use cases discussed in this document are strongly
related to dedicated SIP call scenarios providing challenges for key
management in general among them media before SDP answer, forking,
and shared key conferencing.
Fries & Ignjatic Expires December 27, 2007 [Page 2]
Internet-Draft MIKEY modes applicability June 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6
3. MIKEY Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Pre-shared key protected distribution . . . . . . . . . . 8
3.2. Public Key encrypted key distribution . . . . . . . . . . 9
3.3. Diffie-Hellman key agreement protected with digital
signatures . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Unprotected key distribution . . . . . . . . . . . . . . . 10
3.5. Diffie-Hellman key agreement protected with pre-shared
secrets . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.6. SAML assisted DH-key agreement . . . . . . . . . . . . . . 11
3.7. Asymmetric key distribution with in-band certificate
exchange . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Further MIKEY Extensions . . . . . . . . . . . . . . . . . . . 15
4.1. ECC algorithms support . . . . . . . . . . . . . . . . . . 15
4.1.1. Elliptic Curve Integrated Encryption Scheme
application in MIKEY . . . . . . . . . . . . . . . . . 16
4.1.2. Elliptic Curve Menezes-Qu-Vanstone Scheme
application in MIKEY . . . . . . . . . . . . . . . . . 16
4.2. New MIKEY Payload for bootstrapping TESLA . . . . . . . . 16
4.3. MBMS extensions to the Key ID information type . . . . . . 17
4.4. OMA BCAST MIKEY General Extension Payload Specification . 17
4.5. Supporting Integrity Transform carrying the Rollover
Counter . . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Selection and interworking of MIKEY modes . . . . . . . . . . 19
5.1. MIKEY and Early Media . . . . . . . . . . . . . . . . . . 20
5.2. MIKEY and Forking . . . . . . . . . . . . . . . . . . . . 21
5.3. MIKEY and Call Transfer/Redirect/Retarget . . . . . . . . 22
5.4. MIKEY and Shared Key Conferencing . . . . . . . . . . . . 22
6. Transport of MIKEY messages . . . . . . . . . . . . . . . . . 24
7. MIKEY alternatives for SRTP security parameter negotiation . . 25
8. Summary of MIKEY related IANA Registrations . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
12.1. Normative References . . . . . . . . . . . . . . . . . . . 31
12.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 35
Fries & Ignjatic Expires December 27, 2007 [Page 3]
Internet-Draft MIKEY modes applicability June 2007
1. Introduction
Key distribution describes the process of delivering cryptographic
keys to the required parties. MIKEY [RFC3830], the Multimedia
Internet Keying, has been defined focusing on support for the
establishment of security context for the Secure Real-time Transport
Protocol [RFC3711]. Note that RFC3830 is not restricted to be used
for SRTP only, as it features a generic approach and allows for
extensions to the key distribution schemes.Thus, it may also be used
for security parameter negotiation for other protocols.
For MIKEY meanwhile seven key distribution methods are described as
there are:
o Symmetric key distribution as defined in [RFC3830] (MIKEY-PSK)
o Asymmetric key distribution as defined in [RFC3830] (MIKEY-RSA)
o Diffie-Hellman key agreement protected by digital signatures as
defined in [RFC3830] (MIKEY-DHSIGN)
o Unprotected key distribution (MIKEY-NULL)
o Diffie-Hellman key agreement protected by symmetric pre-shared
keys as defined in [RFC4650] (MIKEY-DHHMAC)
o SAML assisted Diffie-Hellman key agreement as defined (not
available as seperate document, but discussions are reflected
within this document (MIKEY-DHSAML))
o Asymmetric key distribution (based on asymmetric encryption) with
in-band certificate provision as defined in [RFC4738]
(MIKEY-RSA-R)
Note that the latter three modes are extensions to MIKEY as there
have been scenarios where none of the first four modes defined in
[RFC3830] fits perfectly. There are further extensions to MIKEY
comprising algorithm enhancements and a new payload definition
supporting other protocols than SRTP.
Algorithm extensions are defined in the following document:
o ECC algorithms for MIKEY as defined in [I-D.ietf-msec-mikey-ecc]
Payload extensions are defined in the following documents:
o Bootstrapping TESLA, defining a new payload for the Timed
Efficient Stream Loss-tolerant Authentication protocol [RFC4082]
Fries & Ignjatic Expires December 27, 2007 [Page 4]
Internet-Draft MIKEY modes applicability June 2007
as defined in [RFC4442]
o The Key ID information type for the general extension payload as
defined in [RFC4563]
o OMA BCAST MIKEY General Extension Payload Specification, as
defined in [I-D.dondeti-msec-mikey-genext-oma]
o Integrity Transform Carrying Roll-over Counter for SRTP, as
defined in [RFC4771]. Note that this is rather an extension to
SRTP and requires MIKEY to carry a new parameter, but is stated
here for completeness.
This document provides an overview about RFC3830 and the relations to
the different extensions to provide a framework when using MIKEY. It
is intended as additional source of information for developers or
architects to provide more insight in use case scenarios and
motivations as well as advantages and disadvantages for the different
key distribution schemes. The use cases discussed in this document
are strongly related to dedicated SIP call scenarios providing
challenges for key management in general, as there are:
o Early Media respectively Media before SDP answer
o Forking
o Call Transfer/Redirect/Retarget
o Shared Key Conferencing
Fries & Ignjatic Expires December 27, 2007 [Page 5]
Internet-Draft MIKEY modes applicability June 2007
2. Terminology and Definitions
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].
The following definitions have been taken from [RFC3830]:
(Data) Security Protocol: the security protocol used to protect the
actual data traffic. Examples of security protocols
are IPsec and SRTP.
Data SA Data Security Association information for the security
protocol, including a TEK and a set of parameters/
policies.
CS Crypto Session, uni- or bi-directional data stream(s),
protected by a single instance of a security protocol.
CSB Crypto Session Bundle, collection of one or more
Crypto Sessions, which can have common TGKs (see
below) and security parameters.
CS ID Crypto Session ID, unique identifier for the CS within
a CSB.
CSB ID Crypto Session Bundle ID, unique identifier for the
CSB.
TGK TEK Generation Key, a bit-string agreed upon by two or
more parties, associated with CSB. From the TGK,
Traffic-encrypting Keys can then be generated without
needing further communication.
TEK Traffic-Encrypting Key, the key used by the security
protocol to protect the CS (this key may be used
directly by the security protocol or may be used to
derive further keys depending on the security
protocol). The TEKs are derived from the CSB's TGK.
TGK re-keying the process of re-negotiating/updating the TGK (and
consequently future TEK(s)).
Initiator the initiator of the key management protocol, not
necessarily the initiator of the communication.
Fries & Ignjatic Expires December 27, 2007 [Page 6]
Internet-Draft MIKEY modes applicability June 2007
Responder the responder in the key management protocol.
Salting key a random or pseudo-random (see [RAND, HAC]) string
used to protect against some off-line pre-computation
attacks on the underlying security protocol.
HDR denotes the protocol header
PRF(k,x) a keyed pseudo-random function
E(k,m) encryption of m with the key k
RAND Random value
T Timestamp
CERTx the certificate of x
SIGNx the signature from x using the private key of x
PKx the public key of x
IDx the identity of x
[] an optional piece of information
{} denotes zero or more occurrences
|| concatenation
| OR (selection operator)
^ exponentiation
XOR exclusive or
The following definition has been added to the ones from [RFC3830]:
SSRC Synchronization Source Identifier
Fries & Ignjatic Expires December 27, 2007 [Page 7]
Internet-Draft MIKEY modes applicability June 2007
3. MIKEY Overview
This section will provide an overview about MIKEY. The focus lies on
the key distribution methods as well as the discussion about
advantages and disadvantages of the different schemes. Note that the
MIKEY key distribution schemes rely on loosely synchronized clocks.
A secure network clock synchronization protocol should realize this.
RFC3830 recommends the ISO time synchronization protocol
[ISO_sec_time]. The format applied to the timestamps submitted in
the MIKEY have to match the NTP format described in [RFC1305]. In
other cases, such as of a SIP endpoint, clock synchronization by
deriving time from a trusted outbound proxy may be appropriate.
If MIKEY is used for SRTP [RFC3711] bootstrapping, it also uses the
SSRC to associate security policies with actual sessions. The SSRC
identifies the synchronization source. The value is chosen randomly,
with the intent that no two synchronization sources within the same
SRTP session will have the same SSRC. Although the probability of
multiple sources choosing the same identifier is low, all (S)RTP
implementations must be prepared to detect and resolve collisions.
Nevertheless in multimedia communication scenarios supporting forking
(see Section 5.2), collisions may occur leading to so-called two-time
pads, i.e., the same key is used for media streams to different
destinations. Note that two time pads may also occur for media
streams to the same destination.
3.1. Pre-shared key protected distribution
This option of the key management uses a pre-shared secret key to
derive key material for integrity protection and encryption to
protect the actual exchange of key material. Note that the pre-
shared secret is agreed upon before the session, e.g., by out-of-band
means. The response message is optional and may be used for mutual
authentication or error signaling.
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi],[IDr],
{SP}, KEMAC --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
The advantages of this approach lay in the fact that there is no
dependency on a PKI (Public Key Infrastructure), the solution
consumes low bandwidth and enables high performance, and is all in
all a simple straightforward master key provisioning. The
disadvantages are that no perfect forward secrecy is provided and key
Fries & Ignjatic Expires December 27, 2007 [Page 8]
Internet-Draft MIKEY modes applicability June 2007
generation is just performed by the initiator. Furthermore, the
approach is not scalable to larger configurations but is acceptable
in small-sized groups. Note that according to [RFC3830] this option
is mandatory to implement.
3.2. Public Key encrypted key distribution
Using the asymmetric option of the key management, the initiator
generates the key material (TGK's) to be transmitted and sends it
encrypted with a so-called envelope key, which in turn is encrypted
with the receiver's public key. The envelope key, env-key, which is
a random number, is used to derive the auth-key and the enc-key.
Moreover, the envelope key may be used as a pre-shared key to
establish further crypto sessions. The response message is optional
and may be used for mutual authentication or error signaling.
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP}, KEMAC, [CHASH],
PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
An advantage of this approach is that the usage of self-signed
certificates can avoid PKI. Note that using self-signed certificates
may result in limited scalability and also require additional means
for authentication such as exchange of fingeprints of the
certificates or similar techniques. The disadvantages comprise the
necessity of a PKI for fully scalability, the performance of the key
generation just by the initiator, and no provision of perfect forward
secrecy. Additionally, the responder certificate needs to be
available in advance at the sender's side. Furthermore, the
verification of certificates may not be done in real-time. This
could be the case in scenarios where the revocation status of
certificates is checked through a further component. Note, according
to [RFC3830] this option is mandatory to implement.
3.3. Diffie-Hellman key agreement protected with digital signatures
The Diffie-Hellman option of the key management enables a shared
secret establishment between initiator and responder in a way where
both parties contribute to the shared secret. The Diffie-Hellman key
agreement is authenticated (and integrity protected) using digital
signatures.
Fries & Ignjatic Expires December 27, 2007 [Page 9]
Internet-Draft MIKEY modes applicability June 2007
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP}, DHi, SIGNi --->
R_MESSAGE =
<--- HDR, T, [IDr|CERTr],
IDi, DHr, DHi, SIGNr
[RFC3830] does mandate the support of RSA as specific asymmetric
algorithm for the signature generation. Additionally the algorithm
used for signature or public key encryption is defined by, and
dependent on the certificate used. Besides the use of X.509v3
certificates it is mandatory to support the Diffie-Hellmann group
"OAKLEY5" [RFC2412]. The advantages of this approach are a fair,
mutual key agreement (both parties provide to the key), perfect
forward secrecy, and the absence of the need to fetch a certificate
in advance as needed for the MIKEY-RSA method depicted above.
Moreover, it provides also the option to use self-signed certificates
to avoid PKI (would result in limited scalability and more complex
provisioning). Note that, depending on the security policy, self-
signed certificates may not be suitable for every use case.
Negatively to remark is that this approach scales mainly to point-to-
point and depends on PKI for full scalability. Multiparty
conferencing is not supported using just MIKEY-DHSIGN. Nevertheless,
the established Diffie-Hellman-Secret may serve as a pre-shared key
to bootstrap group-related security parameter. Furthermore, as for
the MIKEY-RSA mode described above, the verification of certificates
may not be necessarily done in real-time. This could be the case in
scenarios where the revocation status of certificates is checked
through a further component.
3.4. Unprotected key distribution
RFC3830 also supports a mode to provide a key in an unprotected
manner (MIKEY-NULL). This is based on the symmetric key encryption
option depicted in Section 3.1 but is used with the NULL encryption
and the NULL authentication algorithm. It may be compared with the
plain approach in sdescriptions [RFC4568]. MIKEY-NULL completely
relies on the security of the underlying layer, e.g., provided by
TLS. This option should be used with caution as it does not protect
the key management.
3.5. Diffie-Hellman key agreement protected with pre-shared secrets
This is an additional option which has been defined in [RFC4650]. In
contrast to the method described in Section 3.3 here the Diffie-
Fries & Ignjatic Expires December 27, 2007 [Page 10]
Internet-Draft MIKEY modes applicability June 2007
Hellmann key agreement is authenticated (and integrity protected)
using a pre-shared secret and keyed hash function.
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi],
IDr, {SP}, DHi, KEMAC --->
R_MESSAGE =
<--- HDR, T,[IDr], IDi,
DHr, DHi, KEMAC
TGK = g^(xi * yi) TGK = g^(xi * yi)
For the integrity protection of the Diffie-Hellman key agreement
[RFC4650] mandates the use of HMAC SHA-1. Regarding Diffie-Hellman
groups [RFC3830] is referenced. Thus, it is mandatory to support the
Diffie-Hellman group "OAKLEY5" [RFC2412]. This option has also
several advantages, as there are the fair mutual key agreement, the
perfect forward secrecy, and no dependency on a PKI and PKI
standards. Moreover, this scheme has a sound performance and reduced
bandwidth requirements and provides a simple and straightforward
master key provisioning. The scalability of this approach comprising
only point-to-point communication is a disadvantage.
This mode of operation provides an efficient scheme in deployments
where there is a central trusted server that is provisioned with
shared secrets for many clients. Such setups could for example be
enterprise PBXs, service provider proxies, etc. In contrast to the
plain pre-shared key encryption based mode, described in Section 3.1,
this mode offers perfect forward secrecy.
3.6. SAML assisted DH-key agreement
There has been a longer discussion during meetings and also on the
MSEC mailing about a SAML assisted DH approach. This idea has not
been submitted as a separate draft. Nevertheless, the discussion is
reflected here as it is targeted to fulfill general requirements on
key management approaches. Those requirements can be summarized as:
1. Mutual authentication of involved parties
2. Both parties involved contribute to the session key generation
3. Provide perfect forward secrecy
4. Support distribution of group session keys
Fries & Ignjatic Expires December 27, 2007 [Page 11]
Internet-Draft MIKEY modes applicability June 2007
5. Provide liveliness tests when involved parties do not have a
reliable clock
6. Support of limited parties involved
To fulfill all of the requirements, it was proposed to use a classic
Diffie-Hellman key agreement protocol for key establishment in
conjunction with a UA's SIP server signed element, authenticating the
Diffie-Hellman key and the ID using the SAML (Security Association
Markup Language, [SAML_overview]) approach. Here the client's public
Diffie-Hellman-credentials are signed by the server to form a SAML
assertion (referred to as CRED below), which may be used for later
sessions with other clients. This assertion needs at least to convey
the ID, public DH key, expiry, and the signature from the server. It
provides the involved clients with mutual authentication and message
integrity of the key management messages exchanged.
Initiator Responder
I_MESSAGE =
HDR, T, RAND1, [CREDi],
IDr, {SP} --->
R_MESSAGE =
<--- HDR, T, [CREDr], IDi, DHr,
RAND2, (SP)
TGK = HMACx(RAND1|RAND2), where x = g^(xi * xr).
Additionally the document proposes a second roundtrip to avoid the
dependence on synchronized clocks and provide liveliness checks.
This is achieved by exchanging nonces, protected with the session
key. The second roundtrip can also be used for distribution of group
keys or to leverage a weak DH key for a stronger session key. The
trigger for the second round trip would be handled via SP, the
Security Policy communicated via MIKEY.
Initiator Responder
I_MESSAGE =
HDR, SIGN(ENC(RAND3)) --->
R_MESSAGE =
<--- SIGN(ENC(RAND4))
Note if group keys are to be provided RAND would be substituted by
that group key.
With the second roundtrip, this approach also provides an option for
all of the other key distribution methods, when liveliness checks are
needed. The drawback of the second roundtrip is that these messages
Fries & Ignjatic Expires December 27, 2007 [Page 12]
Internet-Draft MIKEY modes applicability June 2007
need to be integrated into the call flow of the signaling protocol.
In straight forward call one roundtrip may be enough to setup a
session. Thus this second roundtrip would require additional
messages to be exchanged.
3.7. Asymmetric key distribution with in-band certificate exchange
This is an additional option which has been defined in [RFC4738]. It
describes the asymmetric key distribution with optional in-band
certificate exchange.
Initiator Responder
I_MESSAGE =
HDR, T, [IDi|CERTi], [IDr],
{SP}, [RAND], SIGNi --->
R_MESSAGE =
<--- HDR, [GenExt(CSB-ID)], T,
RAND, [IDr|CERTr], [SP],
KEMAC, SIGNr
This option has some advantages compared to the asymmetric key
distribution stated in Section 3.2. Here, the sender and receiver do
not need to know the certificate of the other peer in advance as it
may be sent in the MIKEY initiator message (if the receiver knows the
certificate in advance, RFC3830's MIKEY-RSA mode may be used
instead). Thus, the receiver of this message can utilize the
received key material to encrypt the session parameter and send them
back as part of the MIKEY response message. The certificate check
may be done depending on the signing authority. If the certificate
is signed by a publicly accepted authority the certificate validation
can be done in a straightforward manner, by using the commonly known
certificate authority's public key. In the other case additional
steps may be necessary. The disadvantage is that no perfect forward
secrecy is provided.
This mode is meant to provide an easy option for certificate
provisioning when PKI is present and/or required. Specifically in
SIP, session invitations can be retargeted or forked. MIKEY modes
that require the Initiator to target a single well known Responder
may be impractical here as they may require multiple roundtrips to do
key negotiation. By allowing the Responder to generate secret
material used for key derivation this mode allows for an efficient
key delivery scheme. Note that the Initiator can contribute to the
material the key is derived from through CSB-ID and RAND payloads in
unicast use cases. This mode is also useful in multicast scenarios
where multiple clients are contacting a known server and are
downloading the key. Responder workload is significantly reduced in
Fries & Ignjatic Expires December 27, 2007 [Page 13]
Internet-Draft MIKEY modes applicability June 2007
these scenarios compared to MIKEY in public key mode. This is due to
the fact that the asymmetric encryption requires less effort compared
to the decryption using the private key. Examples of deployments
where this mode can be used are enterprises with PKI, service
provider setups where the service provider decides to provision
certificates to its users, etc.
Fries & Ignjatic Expires December 27, 2007 [Page 14]
Internet-Draft MIKEY modes applicability June 2007
4. Further MIKEY Extensions
This section will provide an overview about further MIKEY [RFC3830]
extensions for crypto algorithms, generic payload enhancements, as
well as enhancements to support the negotiation of security
parameters for other security protocols than SRTP. These extensions
have been defined in several additional documents.
4.1. ECC algorithms support
[I-D.ietf-msec-mikey-ecc] proposes extensions to the authentication,
encryption and digital signature methods described for use in MIKEY,
employing elliptic-curve cryptography (ECC). These extensions are
defined to align MIKEY with other ECC implementations and standards.
The motivation for supporting ECC within the MIKEY stems from the
following advantages:
o ECC modes are more and more added to security protocols
o ECC support requires considerably smaller keys by keeping the same
security level compared to other asymmetric techniques (like RSA).
Elliptic curve algorithms are capable of providing security
consistent with AES keys of 128, 192, and 256 bits without
extensive growth in asymmetric key sizes.
o As stated in [I-D.ietf-msec-mikey-ecc] implementations have shown
that elliptic curve algorithms can significantly improve
performance and security-per-bit over other recommended
algorithms.
These advantages make the usage of ECC especially interesting for
embedded devices, which may have only limited performance and storage
capabilities.
[I-D.ietf-msec-mikey-ecc] proposes several ECC based mechanisms to
enhance the MIKEY key distribution schemes, as there are:
o Use of ECC methods extending the Diffie-Hellman key exchange:
MIKEY-DHSIGN with ECDSA or ECGDSA
o Use of ECC methods extending the Diffie-Hellman key exchange:
MIKEY-DHSIGN with ECDH
o Use of Elliptic Curve Integrated Encryption Scheme (MIKEY-ECIES)
o Use of Elliptic Curve Scheme Menezes-Qu-Vanstone (MIKEY-ECMQV)
Fries & Ignjatic Expires December 27, 2007 [Page 15]
Internet-Draft MIKEY modes applicability June 2007
The following subsections will provide more detailed information
about the message exchanges for MIKEY-ECIES and MIKEY-ECMQV.
4.1.1. Elliptic Curve Integrated Encryption Scheme application in MIKEY
The following figure shows the message exchange for the MIKEY-ECIES
scheme:
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP}, KEMAC,
[CHASH], PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
4.1.2. Elliptic Curve Menezes-Qu-Vanstone Scheme application in MIKEY
The following figure shows the message exchange for the MIKEY-ECMQV
scheme:
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP},
ECCPTi, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
4.2. New MIKEY Payload for bootstrapping TESLA
TESLA [RFC4082] is a protocol for providing source authentication in
multicast scenarios. TESLA is an efficient protocol with low
communication and computation overhead, which scales to large numbers
of receivers, and also tolerates packet loss. TESLA is based on
loose time synchronization between the sender and the receivers.
Source authentication is realized in TESLA by using Message
Authentication Code (MAC) chaining. The use of TESLA within the
Secure Real-time Transport Protocol (SRTP) has been published in
[RFC4383] targeting multicast authentication in scenarios, where SRTP
is applied to protect the multimedia data. This solution assumes
that TESLA parameters are made available by out-of-band mechanisms.
[RFC4442] specifies payloads for MIKEY to bootstrap TESLA for source
authentication of secure group communications using SRTP. TESLA may
be bootstrapped using one of the MIKEY key management approaches
Fries & Ignjatic Expires December 27, 2007 [Page 16]
Internet-Draft MIKEY modes applicability June 2007
described above by sending the MIKEY message via unicast, multicast
or broadcast. This approach provides the necessary parameter payload
extensions for the usage of TESLA in SRTP. Nevertheless, if the
parameter set is also sufficient for other TESLA use cases, it can be
applied as well.
4.3. MBMS extensions to the Key ID information type
This extension specifies a new Type (the Key ID Information Type) for
the General Extension Payload. This is used in, e.g., the Multimedia
Broadcast/Multicast Service (MBMS) specified in the 3rd Generation
Partnership Project (3GPP). MBMS requires the use of MIKEY to convey
the keys and related security parameters needed to secure the
multimedia that is multicast or broadcast.
One of the requirements that MBMS puts on security is the ability to
perform frequent updates of the keys. The rationale behind this is
that it will be costly for subscribers to re-distribute the
decryption keys to non-subscribers. The cost for re-distributing the
keys using the unicast channel should be higher than the cost of
purchasing the keys for this scheme to have an effect. To achieve
this, MBMS uses a three-level key management, to distribute group
keys to the clients, and be able to re-key by pushing down a new
group key. MBMS has the need to identify, which types of keys are
involved in the MIKEY message and their identity.
[RFC4563] specifies a new Type for the General Extension Payload in
MIKEY, to identify the type and identity of involved keys. Moreover,
as MBMS uses MIKEY both as a registration protocol and a re-key
protocol, this RFC specifies the necessary additions that allow MIKEY
to function both as a unicast and multicast re-key protocol in the
MBMS setting.
4.4. OMA BCAST MIKEY General Extension Payload Specification
The document [I-D.dondeti-msec-mikey-genext-oma] specifies a new
general extension payload type for use in the Open Mobile Alliance's
(OMA) Browser and Content Broadcast (BCAST) group. OMA BCAST's
service and content protection specification uses short term key
message and long term key message payloads that in certain broadcast
distribution systems are carried in MIKEY. The document defines a
general extensions payload to allow possible extensions to MIKEY
without defining a new payload. The general extension payload can be
used in any MIKEY message and is part of the authenticated or signed
data part. Note, that only a parameter description is included, but
no key information.
Fries & Ignjatic Expires December 27, 2007 [Page 17]
Internet-Draft MIKEY modes applicability June 2007
4.5. Supporting Integrity Transform carrying the Rollover Counter
The document [RFC4771] defines a new integrity transform for SRTP
[RFC3711] providing the option to also transmit the Roll Over Counter
(ROC) as part of dedicated SRTP packets. This extension has been
defined for the use in the 3GPP multicast/broadcast service. While
the communicating parties did agree on a starting ROC, in some cases
the receiver may not be able to synchronize his ROC with the one used
by the sender even if it is signaled to him out of band. Here the
new extension provides the possibility for the receiver to re-
synchronize to the sender's ROC. To signal the use of the new
integrity transform new definitions for certain MIKEY payloads need
to be done. These new definition comprise the integrity transforms
itself as well as new integrity transform parameter. Moreover, the
document specifies additional parameter, to enable the usage of
different integrity transforms for SRTP and SRTCP.
Fries & Ignjatic Expires December 27, 2007 [Page 18]
Internet-Draft MIKEY modes applicability June 2007
5. Selection and interworking of MIKEY modes
While MIKEY and its extensions provide plenty of choice in terms of
modes of operation an implementation may choose to simplify its
behavior. This can be achieved by operating in a single mode of
operation when in Initiator's role. Where PKI is available and/or
required an implementation may choose for example to start all
sessions in RSA-R mode but it would be trivial for it to act as a
Responder in public key mode. If envelope keys are cached it can
then also choose to do re-keying in shared key mode. In general,
modes of operation where the Initiator generates keying material are
useful when two peers are aware of each other before the MIKEY
communication takes place. An implementation that does not support
shared key mode can mimic behavior of a peer that does but lacks the
shared key. Similarly, if a peer chooses not to operate in the
public key mode it may reject the certificate of the Initiator. The
same applies to peers that choose to operate in one of the DH modes
exclusively.
Forward MIKEY modes, were the initiator provides the key material,
like public key or shared key mode when used in SIP/SDP may lead to
complications in some calls scenarios, for example forking scenarios
were key derivation material gets distributed to multiple parties.
As mentioned earlier this may be impractical as some of the
destinations may not have the resources to validate the message and
may cause the initiator to drop the session invitation. Even in the
case all parties involved have all the prerequisites for interpreting
the MIKEY message received there is a possible problem with multiple
responders starting media sessions using the same key. While the
SSRCs will be different in most of the cases they are only sixteen
bits long and there is a high probability of a two-time pad problem.
As suggested earlier forward modes are most useful when the two peers
are aware of each other before the communication takes place (as is
the case in key renewal scenarios when costly public key operations
can be avoided by using the envelope key).
The following list may give an idea, how the different MIKEY modes
may be used or combined, depending on available key material at the
initiator side.
1. If the Initiator has a PSK with the Responder, it uses the PSK
mode.
2. If the Initiator has a PSK with the Responder, but needs PFS or
knows that the responder has a policy that both parties should
provide entropy to the key, then it uses the DH-HMAC mode.
Fries & Ignjatic Expires December 27, 2007 [Page 19]
Internet-Draft MIKEY modes applicability June 2007
3. If the Initiator has the RSA key of the Responder, it uses the
RSA mode to establish the TGK. Note that the TGK may be used as
PSK together with Option 1 for further key management operations.
4. If the Initiator expects the receiver not having his certificate
he may use RSA-R. Using RSA-R he can provide the initiators
certificate information in-band to the receiver. Moreover, the
initiator may also provide a random number which can be used by
the receiver for key generation. Thus both parties can be
involved in the key management. But as the inclusion of the
random number cannot be forced by the initiator, true PFS cannot
be provided. Note that in this mode, after establishing the TGK,
it may be used as PSK with other MIKEY options.
5. The Initiator uses DH-SIGN when PFS is required by his policy and
he knows that the responder has a policy that both parties should
provide entropy. Note that also in this mode, after establishing
the TGK, it may be used as PSK with other MIKEY options.
6. If no PSK or certificate is available at the initiators side (and
likewise at the receivers side) but lower level security (like
TLS ot IPSec) is in place the user may use the unprotected mode
of MIKEY.
Besides the available key material choosing between the different
modes of MIKEY depends strongly on the use case. This document will
discuss further scenarios to argue for preferred modes. The
following call scenarios provide a list of potential call scenarios
and are matter of discussion:
o Early Media
o Forking
o Call Transfer/Redirect/Retarget
o Shared key conferencing
5.1. MIKEY and Early Media
In early media scenarios, SRTP data may be received before the answer
over the SIP signaling arrives. The two MIKEY modes, which only
require one message to be transported (Section 3.1 and Section 3.2),
work nicely in early media situations, as both, sender and receiver
have all the necessary parameters in place before actually sending/
receiving encrypted data. The other modes, featuring either Diffie-
Hellman key agreement (Section 3.3, Section 3.5, and Section 3.6) or
the enhanced asymmetric variant (Section 3.7) suffer from the
Fries & Ignjatic Expires December 27, 2007 [Page 20]
Internet-Draft MIKEY modes applicability June 2007
requirements that the initiator has to wait for the response before
being able to decrypt the incoming SRTP media. In fact, even if
early media is not used, in other words if media is not sent before
the SDP answer a similar problem may arise from the fact that SIP/SDP
signaling has to traverse multiple proxies on its way back and media
may arrive before the SDP answer. It is expected that this delay
would be significantly shorter than in the case of early media
though.
It is worth mentioning here that security descriptions [RFC4568] has
basically the same problem as the initiating end needs the SDP answer
before it can start decrypting SRTP media.
To cope with the early media problem there are further approaches to
describe security preconditions
[I-D.ietf-mmusic-securityprecondition], i.e., certain preconditions
need to be met to enable voice data encryption. One example is for
instance that a scenario where a provisional response, containing the
required MIKEY parameter, is sent before encrypted media is
processed.
5.2. MIKEY and Forking
In SIP forking scenarios a SIP proxy server sends an INVITE request
to more than one location. This means that also the MIKEY payload,
which is part of the SDP is sent to several (different) locations.
MIKEY modes supporting signatures may be used in forking scenarios
(Section 3.3 and Section 3.7) as here the receiver can validate the
signature. There are limitations with the symmetric key encryption
as well as the asymmetric key encryption modes (Section 3.1 and
Section 3.2). This is due to the fact that in symmetric encryption
the recipient needs to possess the symmetric key before handling the
MIKEY data. For asymmetric MIKEY modes, if the sender is aware of
the forking he may not know in advance to which location the INVITE
is forked and thus may not use the right receiver certificate to
encrypt the MIKEY envelope key. Note, the sender may include several
MIKEY containers into the same INVITE message to cope with forking,
but this requires the knowledge of all forking targets in advance and
also requires the possession of the target certificates. It is out
of the scope of MIKEY to specify behavior in such a case. DH modes
or the Section 3.7 do not have this problem. In scenarios, where the
sender is not aware of forking, only the intended receiver is able to
decrypt the MIKEY container.
If forking is combined with early media the situation gets
aggravated. If MIKEY modes requiring a full roundtrip are used, like
the signed Diffie-Hellman, multiple responses may overload the end
device. An example is forking to 30 destinations (group pickup),
Fries & Ignjatic Expires December 27, 2007 [Page 21]
Internet-Draft MIKEY modes applicability June 2007
while MIKEY is used with the signed Diffie-Hellman mode together with
security preconditions. Here, every target would answer with a
provisional response, leading to 30 signature validations and Diffie-
Hellman calculations at the senders site. This may lead to a
prolonged media setup delay.
Moreover, depending on the MIKEY mode chosen, a two-time pad may
occur in dependence of the negotiated key material and the SSRC. For
the non Diffie-Hellman modes other than RSA-R, a two-time pad may
occur when multiple receivers pick the same SSRC.
5.3. MIKEY and Call Transfer/Redirect/Retarget
In a SIP environment MIKEY exchange is tied to SDP offer/answer and
irrespective of the implementation model used for call transfer the
same properties and limitations of MIKEY modes apply as in a normal
call setup scenarios.
In certain SIP scenarios the functionality of redirect is supported.
In redirect scenarios the call initiator gets a response that the
called party for instance has temporarily moved and may be reached at
a different destination. The caller can now perform a call
establishment with the new destination. Depending on the originally
chosen MIKEY mode, the caller may not be able to perform this mode
with the new destination. To be more precise MIKEY-PSK, and MIKEY-
DHHMAC require a pre-shared secret in advance. MIKEY-RSA requires
the knowledge about the target's certificate. Thus, these modes may
influence the ability of the caller to initiate a session.
Another functionality, which may be supported in SIP is retargeting.
In contrast to redirect, the call initiator does not get a response
about the different target. The SIP proxy sends the request to a
different target about receiving a redirect response from the
originally called target. This most likely will lead to problems
when using MIKEY modes requiring a pre-shared key (MIKEY-PSK, MIKEY-
DHHMAC) or were the caller used asymmetric key encryption (MIKEY-RSA)
because the key management was originally targeted to a different
destination.
5.4. MIKEY and Shared Key Conferencing
First of all, not all modes of MIKEY support shared key conferencing.
Mainly the Diffie Hellman modes cannot be used straight forward for
conferencing as this mechanism results in a pairwise shared secret
key. All other modes can be applied in conferencing scenarios by
obeying the initiator and responder role, i.e., the half roundtrip
modes need to be initiated by the conferencing unit, to be able to
distribute the conferencing key. The remaining full roundtrip mode,
Fries & Ignjatic Expires December 27, 2007 [Page 22]
Internet-Draft MIKEY modes applicability June 2007
MIKEY RSA-R will be initiated by the client, while the conferencing
unit provides the conferencing key based on the received certificate.
An example conferencing architecture is defined in the IETF's XCON
WG. The scope of this working group relates to mechanism for
membership and authorization control, a mechanism to manipulate and
describe media "mixing" or "topology" for multiple media types
(audio, video, text), a mechanism for notification of conference
related events/changes (for example a floor change), and a basic
floor control protocol. A docuemnt describing possible use case
scenarios is available in [RFC4597].
Fries & Ignjatic Expires December 27, 2007 [Page 23]
Internet-Draft MIKEY modes applicability June 2007
6. Transport of MIKEY messages
MIKEY defines message formats to transport key information and
security policies between communicating entities. It does not define
the embedding of these messages into the used signaling protocol.
This definition is provided in separate documents, depending on the
used signaling protocol. Nevertheless, MIKEY can also be transported
over plain UDP or TCP to port 2269.
Several IETF defined protocols utilize the Session Description
Protocol (SDP, [RFC2327]) to transport the session parameters.
Examples are the Session Initiation Protocol (SIP, [RFC3261] or the
Gateway Control Protocol (GCP, [RFC3525]). The transport of MIKEY
messages as part of SDP is described in [RFC4567]. Here, the
complete MIKEY message is base64 encoded and transmitted as part of
the SDP part of the signaling protocol message. Note, as several key
distribution messages may be transported within one SDP container,
[RFC4567] also comprises an integrity protection regarding all
supplied key distribution attempts. Thus, bidding down attacks will
be recognized.
MIKEY is also applied in ITU-T protocols like H.323, which is used to
establish communication sessions similar to SIP. For H.323 a
security framework exists, which is defined in H.235. Within this
framework H.235.7 [H.235.7] describes the usage of MIKEY and SRTP in
the context of H.323. In contrast to SIP H.323 uses ASN.1 (Abstract
Syntax Notation). Thus there is no need to encode the MIKEY
container as base64. Within H.323 the MIKEY container is binary
encoded.
Fries & Ignjatic Expires December 27, 2007 [Page 24]
Internet-Draft MIKEY modes applicability June 2007
7. MIKEY alternatives for SRTP security parameter negotiation
Besides MIKEY there exists several approaches to handle the security
parameter establishment. This is due to the fact, that some
limitations in certain scenarios have been seen. Examples are early
media and forking situations as described in Section 5. The
following list provides a short summary about possible alternatives:
o sdescription - [RFC4568] describes a key management scheme, which
uses SDP for transport and completely relies on underlying
protocol security. For transport the documents defines a SDP
attribute transmitting all necessary SRTP parameter in clear. For
security it references TLS and S/MIME.In contrast to MIKEY in the
message from the initiator to the responder the SRTP parameter for
the direction initiator to responder is sent rather than vice
versa. This may lead to problems in early media scenarios.
o sdescription with early media support -
[I-D.wing-mmusic-sdes-early-media] enhances the above scheme with
the possibility to also be usable in early media scenarios, when
security preconditions is not used.
o Encrypted Key Transport for Secure RTP - [I-D.mcgrew-srtp-ekt] is
an extension to SRTP that provides for the secure transport of
SRTP master keys, Rollover Counters, and other information, within
SRTCP. This facility enables SRTP to work for decentralized
conferences with minimal control, and to handle situations caused
by SIP forking and early media.It may also be used in conjunction
with MIKEY.
o Diffie Hellman support in SDP - [I-D.baugher-mmusic-sdp-dh]
defines a new SDP attribute for exchanging Diffie-Hellman public
keys. The attribute is an SDP session-level attribute for
describing DH keys, and there is a new media-level parameter for
describing public keying material for SRTP key generation.
o DTLS-SRTP describing SRTP extensions for DTLS -
[I-D.mcgrew-tls-srtp] describes a method of using DTLS key
management for SRTP by using a new extension that indicates that
SRTP is to be used for data protection, and which establishes SRTP
keys.
o ZRTP - [I-D.zimmermann-avt-zrtp] This document defines ZRTP as RTP
header extensions for a Diffie-Hellman exchange to agree on a
session key and parameters for establishing SRTP sessions. The
ZRTP protocol is completely self-contained in RTP and does not
require support in the signaling protocol or assume a PKI.
Fries & Ignjatic Expires December 27, 2007 [Page 25]
Internet-Draft MIKEY modes applicability June 2007
There has been a longer discussion regarding a preferred key
management approach in the IETF coping with the different scenarios
and requirements continuousely sorting out key management approaches.
During IETF 68 there were three options MIKEY in an updated version
(referred to as MIKEYv2), ZRTP, and DTLS-SRTP. The potential key
management protocol for the standards track for media security was
voted in favor of DTLS-SRTP. Thus, the reader is pointed to the
appropriate resources for further information. Note that MIKEY has
already been deployed and is also targeted for use in 3GPP and MBMS
applications.
Fries & Ignjatic Expires December 27, 2007 [Page 26]
Internet-Draft MIKEY modes applicability June 2007
8. Summary of MIKEY related IANA Registrations
For MIKEY and the extensions to MIKEY IANA registrations have been
made. Here only a link to the appropriate IANA registration is
provided to avoid inconsistencies. The IANA registrations for MIKEY
payloads can be found under
http://www.iana.org/assignments/mikey-payloads These registrations
comprise the MIKEY base registrations as well as registrations made
by MIKEY extensions regarding the payload.
The IANA registrations for MIKEY port numbers can be found under
http://www.iana.org/assignments/port-numbers (search for MIKEY).
Fries & Ignjatic Expires December 27, 2007 [Page 27]
Internet-Draft MIKEY modes applicability June 2007
9. Security Considerations
This document does not define extensions to existing protocols. It
rather provides an overview about the set of MIKEY and available
extensions. Thus, the reader is referred to the original documents
defining the base protocol and the extensions for the security
considerations.
Fries & Ignjatic Expires December 27, 2007 [Page 28]
Internet-Draft MIKEY modes applicability June 2007
10. IANA Considerations
This document does not require any IANA registration.
Fries & Ignjatic Expires December 27, 2007 [Page 29]
Internet-Draft MIKEY modes applicability June 2007
11. Acknowledgments
The authors would like to thank Lakshminath Dondeti for his document
reviews and for his guidance.
Fries & Ignjatic Expires December 27, 2007 [Page 30]
Internet-Draft MIKEY modes applicability June 2007
12. References
12.1. Normative References
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
12.2. Informative References
[H.235.7] ""ITU-T Recommendation H.235.7: Usage of the MIKEY Key
Management Protocol for the Secure Real Time Transport
Protocol (SRTP) within H.235"", 2005.
[I-D.baugher-mmusic-sdp-dh]
Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for
Multimedia Sessions", draft-baugher-mmusic-sdp-dh-00 (work
in progress), February 2006.
[I-D.dondeti-msec-mikey-genext-oma]
Dondeti, L., "MIKEY General Extension Payload for OMA
BCAST LTKM/STKM Transport",
draft-dondeti-msec-mikey-genext-oma-04 (work in progress),
February 2007.
[I-D.ietf-mmusic-securityprecondition]
Andreasen, F. and D. Wing, "Security Preconditions for
Session Description Protocol (SDP) Media Streams",
draft-ietf-mmusic-securityprecondition-03 (work in
progress), October 2006.
[I-D.ietf-msec-mikey-ecc]
Milne, A., "ECC Algorithms for MIKEY",
draft-ietf-msec-mikey-ecc-03 (work in progress),
June 2007.
[I-D.mcgrew-srtp-ekt]
McGrew, D., "Encrypted Key Transport for Secure RTP",
draft-mcgrew-srtp-ekt-02 (work in progress), March 2007.
[I-D.mcgrew-tls-srtp]
Rescorla, E. and D. McGrew, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for Secure
Real-time Transport Protocol (SRTP)",
draft-mcgrew-tls-srtp-02 (work in progress), March 2007.
[I-D.wing-mmusic-sdes-early-media]
Raymond, R. and D. Wing, "Security Descriptions Extension
Fries & Ignjatic Expires December 27, 2007 [Page 31]
Internet-Draft MIKEY modes applicability June 2007
for Early Media", draft-wing-mmusic-sdes-early-media-00
(work in progress), October 2005.
[I-D.zimmermann-avt-zrtp]
Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure
RTP", draft-zimmermann-avt-zrtp-03 (work in progress),
March 2007.
[ISO_sec_time]
""ISO/IEC 18014 Information technology - Security
techniques - Time-stamping services, Part 1-3."", 2002.
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor,
"Gateway Control Protocol Version 1", RFC 3525, June 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, June 2005.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383,
Fries & Ignjatic Expires December 27, 2007 [Page 32]
Internet-Draft MIKEY modes applicability June 2007
February 2006.
[RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed
Efficient Stream Loss-Tolerant Authentication (TESLA)",
RFC 4442, March 2006.
[RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID
Information Type for the General Extension Payload in
Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006.
[RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios",
RFC 4597, August 2006.
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for
Multimedia Internet KEYing (MIKEY)", RFC 4650,
September 2006.
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-
RSA-R: An Additional Mode of Key Distribution in
Multimedia Internet KEYing (MIKEY)", RFC 4738,
November 2006.
[RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity
Transform Carrying Roll-Over Counter for the Secure Real-
time Transport Protocol (SRTP)", RFC 4771, January 2007.
[SAML_overview]
Huges, J. and E. Maler, ""Security Assertion Markup
Language (SAML) 2.0 Technical Overview, Working Draft"",
2005.
Fries & Ignjatic Expires December 27, 2007 [Page 33]
Internet-Draft MIKEY modes applicability June 2007
Authors' Addresses
Steffen Fries
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: steffen.fries@siemens.com
Dragan Ignjatic
Polycom
1000 W. 14th Street
North Vancouver, BC V7P 3P3
Canada
Email: dignjatic@polycom.com
Fries & Ignjatic Expires December 27, 2007 [Page 34]
Internet-Draft MIKEY modes applicability June 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).
Fries & Ignjatic Expires December 27, 2007 [Page 35]
