One document matched: draft-ietf-msec-mikey-applicability-09.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ietf-msec-mikey-ecc PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-msec-mikey-ecc.xml' >
<!ENTITY I-D.baugher-mmusic-sdp-dh PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.baugher-mmusic-sdp-dh.xml' >
<!ENTITY I-D.zimmermann-avt-zrtp PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zimmermann-avt-zrtp.xml' >
<!ENTITY I-D.wing-mmusic-sdes-early-media PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wing-mmusic-sdes-early-media.xml' >
<!ENTITY I-D.mcgrew-srtp-ekt PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mcgrew-srtp-ekt.xml' >
<!ENTITY I-D.ietf-avt-dtls-srtp PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avt-dtls-srtp.xml' >
<!ENTITY I-D.ietf-sip-media-security-requirements PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-media-security-requirements.xml' >
<!ENTITY RFC2412 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2412.xml' >
<!ENTITY RFC3261 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml' >
<!ENTITY RFC3711 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml' >
<!ENTITY RFC3830 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3830.xml' >
<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml' >
<!ENTITY RFC1305 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1305.xml' >
<!ENTITY RFC3525 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3525.xml' >
<!ENTITY RFC4082 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4082.xml' >
<!ENTITY RFC4383 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4383.xml' >
<!ENTITY RFC4442 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4442.xml' >
<!ENTITY RFC4563 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4563.xml' >
<!ENTITY RFC4566 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml' >
<!ENTITY RFC4567 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4567.xml' >
<!ENTITY RFC4568 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4568.xml' >
<!ENTITY RFC4597 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4597.xml' >
<!ENTITY RFC4650 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4650.xml' >
<!ENTITY RFC4738 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4738.xml' >
<!ENTITY RFC4771 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4771.xml' >
<!ENTITY RFC4909 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4909.xml' >
<!ENTITY RFC4949 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml' >
<!ENTITY RFC5027 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5027.xml' >
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<rfc category="info" ipr="full3978" docName="draft-ietf-msec-mikey-applicability-09.txt">
<front>
<title abbrev="MIKEY modes applicability">On the applicability of various MIKEY modes and extensions</title>
<author initials="S." surname="Fries" fullname="Steffen Fries">
<organization abbrev="Siemens">Siemens</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<region>Bavaria</region>
<code>81739</code>
<country>Germany</country>
</postal>
<email>steffen.fries@siemens.com</email>
</address>
</author>
<author initials="D." surname="Ignjatic" fullname="Dragan Ignjatic">
<organization abbrev="Polycom">Polycom</organization>
<address>
<postal>
<street>1000 W. 14th Street</street>
<city>North Vancouver</city>
<region>BC</region>
<code>V7P 3P3</code>
<country>Canada</country>
</postal>
<email>dignjatic@polycom.com</email>
</address>
</author>
<date month="March" year="2008"/>
<area>Security Area</area>
<workgroup>MSEC</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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.</t>
<t> 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. </t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="introduction" title="Introduction">
<t>Key distribution describes the process of delivering cryptographic keys to the
required parties. MIKEY <xref target="RFC3830"/>, the Multimedia Internet Keying,
has been defined focusing on support for the establishment of security context
for the Secure Real-time Transport Protocol <xref target="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. </t>
<t> For MIKEY, meanwhile seven key distribution methods are described as there are:
<list style="symbols">
<t> Symmetric key distribution as defined in <xref target="RFC3830"/> (MIKEY-PSK)</t>
<t> Asymmetric key distribution as defined in <xref target="RFC3830"/> (MIKEY-RSA)</t>
<t> Diffie-Hellman key agreement protected by digital signatures as defined in
<xref target="RFC3830"/> (MIKEY-DHSIGN)</t>
<t> Unprotected key distribution (MIKEY-NULL)</t>
<t> Diffie-Hellman key agreement protected by symmetric pre-shared keys as defined
in <xref target="RFC4650"/> (MIKEY-DHHMAC)</t>
<t> SAML assisted Diffie-Hellman key agreement as defined (not available as seperate
document, but discussions are reflected within this document (MIKEY-DHSAML))</t>
<t> Asymmetric key distribution (based on asymmetric encryption) with in-band
certificate provision as defined in <xref target="RFC4738"/>
(MIKEY-RSA-R)</t>
</list>
Note that the latter three modes are extensions to MIKEY as there have been scenarios
where none of the first four modes defined in <xref target="RFC3830"/> fits perfectly.
There are further extensions to MIKEY comprising algorithm enhancements and a new payload
definition supporting other protocols than SRTP.</t>
<t> Algorithm extensions are defined in the following document:
<list style="symbols">
<t> ECC algorithms for MIKEY as defined in <xref target="I-D.ietf-msec-mikey-ecc"/></t>
</list>
Payload extensions are defined in the following documents:
<list style="symbols">
<t> Bootstrapping TESLA, defining a new payload for the Timed Efficient Stream
Loss-tolerant Authentication (TESLA) protocol <xref target="RFC4082"/> as defined
in <xref target="RFC4442"/></t>
<t> The Key ID information type for the general extension payload as defined
in <xref target="RFC4563"/></t>
<t> OMA BCAST MIKEY General Extension Payload Specification, as defined
in <xref target="RFC4909"/></t>
<t> Integrity Transform Carrying Roll-over Counter for SRTP, as defined
in <xref target="RFC4771"/>. Note that this is rather an
extension to SRTP and requires MIKEY to carry a new parameter, but is
stated here for completeness.</t>
</list>
</t>
<t>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 inspired by specific protocol workings
of SIP that have proved to be problematic for a general key distribution mechanisms in
general. These protocol workings are described in detail in Wing et al.
<xref target="I-D.ietf-sip-media-security-requirements"/> to include the following:
<list style="symbols">
<t> Early Media respectively Media before SDP answer </t>
<t> Forking </t>
<t> Call Transfer/Redirect/Retarget</t>
<t> Shared Key Conferencing </t>
</list>
</t>
</section>
<!-- ====================================================================== -->
<section anchor="terminology" title="Terminology and Definitions">
<t>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 <xref target="RFC2119"/>.</t>
<t>The following definitions have been taken from <xref target="RFC3830"/>:</t>
<list hangIndent="15" style="hanging">
<t hangText="(Data) Security Protocol:"> the security protocol used to protect the actual data
traffic. Examples of security protocols are IPsec and SRTP.</t>
<t hangText="Data SA"> Data Security Association information for the security protocol,
including a TEK and a set of parameters/policies.</t>
<t hangText="CS"> Crypto Session, uni- or bi-directional data stream(s), protected by a single
instance of a security protocol.</t>
<t hangText="CSB"> Crypto Session Bundle, collection of one or more Crypto Sessions, which can
have common TGKs (see below) and security parameters.</t>
<t hangText="CS ID"> Crypto Session ID, unique identifier for the CS within a CSB.</t>
<t hangText="CSB ID"> Crypto Session Bundle ID, unique identifier for the CSB.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="TGK re-keying"> the process of re-negotiating/updating the TGK (and consequently
future TEK(s)).</t>
<t hangText="Initiator"> the initiator of the key management protocol, not necessarily the initiator
of the communication.</t>
<t hangText="Responder"> the responder in the key management protocol.</t>
<t hangText="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.</t>
<t hangText="HDR"> denotes the protocol header</t>
<t hangText="PRF(k,x)"> a keyed pseudo-random function</t>
<t hangText="E(k,m)"> encryption of m with the key k</t>
<t hangText="RAND"> Random value</t>
<t hangText="T"> Timestamp</t>
<t hangText="CERTx"> the certificate of x</t>
<t hangText="SIGNx"> the signature from x using the private key of x</t>
<t hangText="PKx"> the public key of x</t>
<t hangText="IDx"> the identity of x</t>
<t hangText="[]"> an optional piece of information</t>
<t hangText="{}"> denotes zero or more occurrences</t>
<t hangText="||"> concatenation</t>
<t hangText="|"> OR (selection operator)</t>
<t hangText="^"> exponentiation</t>
<t hangText="XOR"> exclusive or</t>
</list>
<t> The following definition has been added to the ones from <xref target="RFC3830"/>:</t>
<list hangIndent="15" style="hanging">
<t hangText="SSRC "> Synchronization Source Identifier</t>
<t hangText="KEMAC "> MIKEY Key Data Transport Payload, containing a set of encrypted
sub-payloads and a MAC. </t>
<t hangText="V "> MIKEY Verification Message</t>
<t hangText="SP "> Security Parameter</t>
<t hangText="Forking "> The ability of a SIP proxy to replicate an incoming request
to multiple outgoing requests in order to efficiently find the called party for
rendezvous. SIP forking can be done in serial (depth-first search), or in parallel
(breadth-first search).</t>
<t hangText="Redirect "> The ability of a SIP proxy to send a final response that
redirects the caller to send a request to an alternate location.</t>
<t hangText="Re-target "> The ability of a SIP proxy to re-write the Request-URI
thereby altering the destination of the request without explicitly notifying the user
agent client.</t>
</list>
</section>
<!-- ====================================================================== -->
<section anchor="mikey_overview" title="MIKEY Overview">
<t> This section will provide an overview about MIKEY. MIKEY focuses on the setup
of cryptographic context to secure multimedia sessions in a heterogeneous environment.
MIKEY is mainly intended to be used for peer-to-peer, simple one-to-many, and small-size
(interactive) groups. One objective of MIKEY is to produce a Data security association
(SA) for the security protocol, including a traffic-encrypting key (TEK), which is
derived from a TEK Generation Key (TGK), and used as input for the security protocol.</t>
<t> MIKEY supports the possibility of establishing keys and parameters for more than one
security protocol (or for several instances of the same security protocol) at the same
time. The concept of Crypto Session Bundle (CSB) is used to denote a collection of one
or more Crypto Sessions that can have common TGK and security parameters, but which
obtain distinct TEKs from MIKEY.</t>
<t> MIKEY as defined in RFC3830 may proceed with one roundtrip at most, using a so-called
Initiator message for the forward direction and a Responder message for the backward
direction. Note that there exist MIKEY schemes, which may proceed within a half roundtrip
(e.g., based on a pre-shared key), while other schemes require a full roundtrip (e.g.,
Diffie Hellman based schemes). The main objective of the Initiator's message (I_MESSAGE)
is to transport one or more TGKs (carried in the KEMAC field) and a set of security parameters
(SPs) to the Responder in a secure manner. As the verification message from the Responder
is optional for some schemes, the Initiator indicates whether it requires a verification
message or not from the Responder.</t>
<t> The focus of the following subsections 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. If clock
synchronization is not available, the replay handling of MIKEY (cf.<xref target="RFC3830"/>)
may not work. This is due to the fact that MIKEY does not use a challenge-response mechanism
for replay handling; instead, timestamps are used together with message caching. Thus the
required synchronization depends on the number of messages that can be cached on either side.
Therefore, MIKEY recommendeds to adjust the cache size depending on the clock skew in the
deployment environment. Moreover, RFC3830 recommends the ISO time synchronization protocol
<xref target="ISO_sec_time"/>.
The format applied to the timestamps submitted in the MIKEY have to match the NTP format
described in <xref target="RFC1305"/>. In other cases, such as of a SIP endpoint, clock
synchronization by deriving time from a trusted outbound proxy may be appropriate.</t>
<t> The different MIKEY related schemes are compared regarding following criteria:
<list style="symbols">
<t> Mandatory for implementation: provides information, if RFC3830 requires the
implementation of this scheme.</t>
<t> Scalability: describes the technical feasibility to easily deploy a solution
based on the considered scheme </t>
<t> Dependency on PKI: states if the support of a PKI is required to support this
scheme. Note, that PKI here relates to PKI services like key generation,
distribution and revocation. </t>
<t> Provision of Perfect Forward Secrecy (PFS): Describes the support of PFS,
which is, according to RFC4949 <xref target="RFC4949"/> the property that
compromising the long-term keying material does not compromise session keys
that were previously derived from the long-term material.</t>
<t> Key generation involvement: Describes if both or just one of the participants
are actively involved in key generation. The option to involve both parties
in the key generation is considered here as it addresses several points:
<list style="symbols">
<t> If both sides contribute public entropy, it is ensured that each side
can guarantee that keys are fresh to avoid replay attacks. </t>
<t> Involvement of both sides avoids that one side generates (intentionally
or unintentionally) weak (predictable) nonces, which in turn may result in
weak keys. </t>
</list></t>
<t> Support of group keying: Feasibility of the MIKEY option to be used also for
group keying, e.g., in conferencing scenarios. </t>
</list></t>
<t> If MIKEY is used for SRTP <xref target="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 <xref target="mikey_forking"/>) or retargeting,
(see <xref target="mikey_calltransfer"/>) collisions may occur leading to
so-called two-time pads, i.e., the same key is used for media streams to different
destinations. This occurs, if two branches have the same TEK (based on the MIKEY key
establishment) and choose the same 32-bit SSRC for the SRTP streams. The SRTP key
derivation will then produce the same session keys (as the input values are the same) and
also derive the same initialization vector per packet, as the SSRC are the same.
Note that two time pads may also occur for media streams to the same
destination. This is outlined in <xref target="RFC3711"/>.</t>
<section anchor="mikey_symmetric" title="Pre-shared key protected distribution">
<t> 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 (proof of possession of the pre-shared secret) or error signaling.
<figure>
<artwork><![CDATA[
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi],[IDr],
{SP}, KEMAC --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
]]></artwork>
</figure>
</t>
<t> 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 perfect forward secrecy is not provided
and key 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 <xref target="RFC3830"/> this option is mandatory to
implement. </t>
</section>
<!-- === -->
<section anchor="mikey_asymmetric" title="Public Key encrypted key distribution">
<t> 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.
<figure>
<artwork><![CDATA[
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP}, KEMAC, [CHASH],
PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
]]></artwork>
</figure>
</t>
<t> An advantage of this approach is that it allows the usage of self-signed certificates,
which in turn can avoid a full blown PKI. Note that using self-signed certificates
may result in limited scalability and also require additional means for authentication
such as exchange of fingerprints 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. Depending on the initiator role
this scheme may can also be applied in group based communication, where a central server
distributes the group key protected with the public keys of the associated clients.
Note, according to <xref target="RFC3830"/> this option is mandatory to implement. </t>
</section>
<!-- === -->
<section anchor="mikey_dh_sign" title="Diffie-Hellman key agreement protected with digital signatures">
<t> 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.
<figure>
<artwork><![CDATA[
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP}, DHi, SIGNi --->
R_MESSAGE =
<--- HDR, T, [IDr|CERTr],
IDi, DHr, DHi, SIGNr
]]></artwork>
</figure>
</t>
<t> <xref target="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" <xref target="RFC2412"/>. It is also possible to use other Diffie-Hellman
groups within MIKEY. This can be done by defining a new mapping sub-payload and the
associated policy payload according to <xref target="RFC3830"/>. The advantages
of this approach are a fair, mutual key agreement (both parties provide to the key),
and 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 also provides
the option to use self-signed certificates to avoid a PKI deployment. Note that,
depending on the security policy, self-signed certificates may not be suitable for
every use case.</t>
<t> 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.
Note, according to <xref target="RFC3830"/> it is optional to implement this scheme. </t>
</section>
<!-- === -->
<section anchor="mikey_unprotected" title="Unprotected key distribution">
<t> 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 <xref target="mikey_symmetric"/>
but is used with the NULL encryption and the NULL authentication algorithm. It may be
compared with the plain approach in sdescriptions <xref target="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.</t>
<t> Based on the missing cryptographic protection of this method, it is obvious that
perfect forward secrecy is not provided. As it is based on the pre-shared secret mode
only the initiator provides to the key management. The method itself is highly scalable
but again, without proper protection through an underlying security layers it is
not advisable for use.</t>
</section>
<!-- === -->
<section anchor="mikey_dhhmac" title="Diffie-Hellman key agreement protected with pre-shared secrets">
<t> This is an additional option which has been defined in
<xref target="RFC4650"/>. In contrast to the method described
in <xref target="mikey_dh_sign"/> here the Diffie-Hellmann key agreement is
authenticated (and integrity protected) using a pre-shared secret and keyed hash
function.
<figure>
<artwork><![CDATA[
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)
]]></artwork>
</figure>
</t>
<t> For the integrity protection of the Diffie-Hellman key agreement
<xref target="RFC4650"/> mandates the use of HMAC SHA-1.
Regarding Diffie-Hellman groups <xref target="RFC3830"/> is referenced.
Thus, it is mandatory to support the Diffie-Hellman group "OAKLEY5"
<xref target="RFC2412"/>. It is also possible to use other Diffie-Hellman groups
within MIKEY. This can be done by defining a new mapping sub-payload and the associated
policy payload according to RFC3830. 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 compared to MIKEY-DH-SIGN and provides a simple
and straightforward master key provisioning. The establishment of shared secrets and
the lack of support for group keying is a disadvantage. </t>
<t> 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
<xref target="mikey_symmetric"/>, this mode offers perfect forward secrecy as well
as active involvement in the key generation of both parties involved.</t>
</section>
<!-- === -->
<section anchor="mikey_dh_saml" title="SAML assisted DH-key agreement">
<t> There has been a longer discussion during IETF meetings and also on the IETF 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:
<list style="numbers">
<t> Mutual authentication of involved parties</t>
<t> Both parties involved contribute to the session key generation</t>
<t> Provide perfect forward secrecy</t>
<t> Support distribution of group session keys</t>
<t> Provide liveliness tests when involved parties do not have a reliable clock</t>
<t> Support of limited parties involved</t>
</list>
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
User Agents (UA's) SIP server signed element, authenticating the Diffie-Hellman key and
the ID using the SAML (Security Association Markup Language, <xref target="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.
<figure>
<artwork><![CDATA[
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).
]]></artwork>
</figure>
</t>
<t> Additionally the scheme 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.
<figure>
<artwork><![CDATA[
Initiator Responder
I_MESSAGE =
HDR, SIGN(ENC(RAND3)) --->
R_MESSAGE =
<--- SIGN(ENC(RAND4))
]]></artwork>
</figure>
</t>
<t> Note if group keys are to be provided RAND would be substituted by that group key.</t>
<t> 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 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.</t>
<t> Regarding the different criteria discussed in the introduction of this section, the
advantages of this approach are a fair, mutual key agreement (both parties
provide to the key), perfect forward secrecy. Through the second roundtrip,
the dependency on synchronized clocks can be avoided. Moreover, this second roundtrip
enables the distribution of a group key and thus enhances the scalability from mainly
point-to-point to also multiparty conferencing. The usage of SAML assisted DH
may decrease the hidden latency cost through the credential validation necessary to
be done for the signed DH scheme described in <xref target="mikey_dh_sign"/>. If the
UA received its SAML assertion from its domain's SIP server, it is trusting the
server implicitly thus it may extend that trust to relying on it to validate the
other party's SAML assertion. This not only eliminates the hidden validation
latency, but also its computational cost to the UA.</t>
<t> Negatively to remark is that this proposal does have one significant security risk.
The UA's SIP server can cheat and create an extra authentication object for the
UA where it has the Diffie-Hellman private key. With this, the (SIP) server issuing
the SAML assertion can successfully launch a MITM attack against two of its UAs. Also
two SIP servers can collude so that either can successfully launch a MITM attack
against their UAs. A UA can block this attack if its Diffie-Hellman key is
authenticated by a trustworthy third party and this whole object is signed by the
SIP server. Moreover, this approach uses two roundtrips, increasing the necessary
bandwidth and also the setup time, which may be crucial for many scenarios. For
the credential generation usually a seperate component (server) is necessary,
so server less call setup is not supported.</t>
</section>
<!-- === -->
<section anchor="mikey_rsar" title="Asymmetric key distribution with in-band certificate exchange">
<t> This is an additional option which has been defined in
<xref target="RFC4738"/>. It describes the asymmetric key
distribution with optional in-band certificate exchange.
<figure>
<artwork><![CDATA[
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
]]></artwork>
</figure>
</t>
<t> This option has some advantages compared to the asymmetric key distribution
stated in <xref target="mikey_asymmetric"/>. 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. </t>
<t> 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 key material since the key is derived from
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 these scenarios compared
to MIKEY in public key mode. This is due to the fact that the RSA asymmetric
encryption requires less effort compared to the decryption using the private key
(The public key is usually shorter than the private key, hence less performance for
encryption compared to decryption). 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.</t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="mikey_extensions" title="Further MIKEY Extensions">
<t> This section will provide an overview about further MIKEY <xref target="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.</t>
<!-- === -->
<section anchor="mikey_ecc" title="ECC algorithms support">
<t> <xref target="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. </t>
<t> The motivation for supporting ECC within the MIKEY stems from the following
advantages:
<list style="symbols">
<t> ECC modes are more and more added to security protocols</t>
<t> 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.</t>
<t> As stated in <xref target="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. </t>
</list>
These advantages make the usage of ECC especially interesting for embedded devices,
which may have only limited performance and storage capabilities. </t>
<t> <xref target="I-D.ietf-msec-mikey-ecc"/> proposes several ECC based mechanisms to
enhance the MIKEY key distribution schemes, as there are:
<list style="symbols">
<t> Use of ECC methods extending the Diffie-Hellman key exchange:
MIKEY-DHSIGN with ECDSA or ECGDSA</t>
<t> Use of ECC methods extending the Diffie-Hellman key exchange:
MIKEY-DHSIGN with ECDH</t>
<t> Use of Elliptic Curve Integrated Encryption Scheme (MIKEY-ECIES)</t>
<t> Use of Elliptic Curve Scheme Menezes-Qu-Vanstone (MIKEY-ECMQV)</t>
</list>
The following subsections will provide more detailed information about the message
exchanges for MIKEY-ECIES and MIKEY-ECMQV.</t>
<!-- === -->
<section anchor="mikey_ecc_ecies" title="Elliptic Curve Integrated Encryption Scheme application in MIKEY">
<t> The following figure shows the message exchange for the MIKEY-ECIES scheme:
<figure>
<artwork><![CDATA[
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP}, KEMAC,
[CHASH], PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
]]></artwork>
</figure>
</t>
</section>
<!-- === -->
<section anchor="mikey_ecc_mqv" title="Elliptic Curve Menezes-Qu-Vanstone Scheme application in MIKEY">
<t> The following figure shows the message exchange for the MIKEY-ECMQV scheme:
<figure>
<artwork><![CDATA[
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP},
ECCPTi, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
]]></artwork>
</figure>
</t>
</section>
</section>
<!-- === -->
<section anchor="mikey_bootstrapping_tesla" title="New MIKEY Payload for bootstrapping TESLA">
<t>TESLA <xref target="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
<xref target="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.</t>
<t> <xref target="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 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.</t>
</section>
<!-- === -->
<section anchor="mikey_newtype_keyid" title="MBMS extensions to the Key ID information type">
<t> 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.</t>
<t> 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.</t>
<t> <xref target="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.</t>
</section>
<!-- === -->
<section anchor="mikey_gen_payload" title="OMA BCAST MIKEY General Extension Payload Specification">
<t> The document <xref target="RFC4909"/> 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. </t>
</section>
<!-- === -->
<section anchor="mikey_rcc-transform" title="Supporting Integrity Transform carrying the Rollover Counter">
<t> The document <xref target="RFC4771"/> defines a new integrity
transform for SRTP <xref target="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.</t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="mikey_modes_overview" title="Selection and interworking of MIKEY modes">
<t> While MIKEY and its extensions provide a variety 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 and
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. It is outside the scope
of MIKEY or MIKEY extensions if the caching of envelope keys is allowed. This is a matter of
the configuration of the involved components. This local configuration is also outside the
scope of MIKEY. 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.
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.</t>
<t> Forward MIKEY modes, where 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 where 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 32 bits long
and there is a high probability of a two-time pad problem. This is due to the support of
scenarios like forking (see also <xref target="mikey_forking"/>) or retargeting (see also
<xref target="mikey_calltransfer"/>), where a two-time pad occurs if two branches have
the same TEK (based on the MIKEY key establishment) and choose the same 32-bit SSRC
for the SRTP streams and transmit SRTP packets.
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).</t>
<t> The following list gives an idea how the different MIKEY modes may be used
or combined, depending on available key material at the initiator side.
<list style="numbers">
<t> If the Initiator has a PSK with the Responder, it uses the PSK mode.</t>
<t> 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.</t>
<t> 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.</t>
<t> If the Initiator does not expect the receiver to have 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 modes.</t>
<t> 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 modes.</t>
<t> If no PSK or certificate is available at the initiators side (and likewise
at the receivers side) but lower level security (like TLS or IPsec) is in place
the user may use the unprotected mode of MIKEY.It has to obeyed, that this
enables intermediate nodes like proxies to actually get the exchanged
master key in plain. This may not be intended, especially in cases, where
the intermediate node is not trusted.</t>
</list> </t>
<t> Besides the available key material choosing between the different modes of MIKEY
depends strongly on the use case. This section will depict dedicated scenarios to
discuss the feasibility of the different modes in these scenarios. A comparison of
the different modes of operation regarding the influences and requirements to the
deploying infrastructure as well as the cryptographic strength can be found in
<xref target="I-D.ietf-sip-media-security-requirements"/>
The following list provides the most prominent call scenarios and are matter of
further discussion:
<list style="symbols">
<t> Early Media</t>
<t> Forking</t>
<t> Call Transfer/Redirect/Retarget</t>
<t> Shared key conferencing</t>
</list>
</t>
<!-- === -->
<section anchor="mikey_early_media" title="MIKEY and Early Media">
<t> The term early media describes two different scenarios. The first one relates to
the case where media data are received before the actual SDP signaling answer has
been received. This may arise through the different latency on the signaling and
media path. This case is often referred to as media before signaling answer.
The second scenario describes the case were media data are send from the callee
before sending the final SIP 200 OK nessage. This situation appears usually in
call center scenarios, when queueing a waiting loop or when providing personal
ring tones.</t>
<t> 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 (<xref target="mikey_symmetric"/> and
<xref target="mikey_asymmetric"/>), 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 (<xref target="mikey_dh_sign"/>,
<xref target="mikey_dhhmac"/>, and <xref target="mikey_dh_saml"/>) or the
enhanced asymmetric variant (<xref target="mikey_rsar"/>) suffer from the
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. </t>
<t> It is worth mentioning here that security descriptions
<xref target="RFC4568"></xref> has basically the same problem
as the initiating end needs the SDP answer before it can start decrypting SRTP
media.</t>
<t> To cope with the early media problem there are further approaches to describe
security preconditions <xref target="RFC5027"/>,
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. </t>
</section>
<!-- === -->
<section anchor="mikey_forking" title="MIKEY and Forking">
<t> 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 (<xref target="mikey_dh_sign"/> and
<xref target="mikey_rsar"/>) as here the receiver can validate the signature.
There are limitations with the symmetric key encryption as well as the asymmetric
key encryption modes (<xref target="mikey_symmetric"/> and
<xref target="mikey_asymmetric"/>). 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 <xref target="mikey_rsar"></xref> 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.</t>
<t> 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), 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.</t>
<t> 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.</t>
</section>
<!-- === -->
<section anchor="mikey_calltransfer" title="MIKEY and Call Transfer/Redirect/Retarget">
<t> 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. </t>
<t> 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. </t>
<t> 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. </t>
</section>
<!-- === -->
<section anchor="mikey_conferences" title="MIKEY and Shared Key Conferencing">
<t> 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 pair wise 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, MIKEY RSA-R will be initiated by the client, while the
conferencing unit provides the conferencing key based on the received
certificate.</t>
<t> 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 document describing possible use case scenarios is available in
<xref target="RFC4597"/>.</t>
</section>
<!-- === -->
<section anchor="mikey_summary" title="MIKEY Mode Summary">
<t> The following two tables summarize the discussion from the subsections before.
The first table matches the scenarios discussed in this section to the different
MIKEY modes.
<figure>
<artwork><![CDATA[
MIKEY Early Secure Retarget Redirect Shared
mode Media Forking Key Conf
---------------------------------------------------------------------
PSK (3.1) Yes Yes *
RSA (3.2) Yes Yes *
DH-SIGN (3.3) Yes* Yes Yes
Unprotected (3.4) Yes
DH-HMAC (3.5)
RSA-R (3.7) Yes Yes Yes Yes
* = In centralized conferencing the media mixer needs to sent the MIKEY Initiator message
]]></artwork>
</figure>
</t>
<t> The following table maps the MIKEY modes to key management related properties.
<figure>
<artwork><![CDATA[
MIKEY Manual Needs PFS Key Generation
mode Keys PKI Involvement
--------------------------------------------------------------
PSK (3.1) Yes No No Initiator
RSA (3.2) No Yes No Initiator
DH-SIGN (3.3) No Yes Yes Both
Unprotected (3.4) No No No Initiator
DH-HMAC (3.5) Yes No Yes Both
RSA-R (3.7) No Yes No Both*
* = assumed the Initiator provides the (optional) RAND value
]]></artwork>
</figure>
</t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="mikey_transport" title="Transport of MIKEY messages">
<t> 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.</t>
<t> Several IETF defined protocols utilize the Session Description Protocol (SDP,
<xref target="RFC4566"/>) to transport the session parameters. Examples are the
Session Initiation Protocol (SIP, <xref target="RFC3261"/> or the Gateway Control
Protocol (GCP, <xref target="RFC3525"/>). The transport of MIKEY messages as part of
SDP is described in <xref target="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, <xref target="RFC4567"/> also comprises an
integrity protection regarding all supplied key distribution attempts. Thus, bidding
down attacks will be recognized. Regarding RTSP, <xref target="RFC4567"/> defines
header extensions allowing the transport of of MIKEY messages. Here, the initial messages
uses SDP, while the remaining part of the key management is performed using the header
extensions</t>
<t> 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 <xref target="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.
</t>
</section>
<!-- ====================================================================== -->
<section anchor="mikey_alternatives" title="MIKEY alternatives for SRTP security parameter negotiation">
<t> 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 <xref target="mikey_modes_overview"/>.
The following list provides a short summary about possible alternatives:
<list style="symbols">
<t> sdescription - <xref target="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 the SRTP parameter in the initiator to responder direction
is actually sent in the message from the initiator to the responder rather
than vice versa. This may lead to problems in early media scenarios.</t>
<t> sdescription with early media support - <xref target="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.</t>
<t> Encrypted Key Transport for Secure RTP - <xref target="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. </t>
<t> Diffie Hellman support in SDP - <xref target="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.</t>
<t> DTLS-SRTP describing SRTP extensions for DTLS - <xref target="I-D.ietf-avt-dtls-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.</t>
<t> ZRTP - <xref target="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.</t>
</list>
There has been a longer discussion regarding a preferred key management approach in the
IETF coping with the different scenarios and requirements continuously sorting out key
management approaches. During IETF 68 three options were considered: 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
on DTLS-SRTP <xref target="I-D.ietf-avt-dtls-srtp"/>.
Note that MIKEY has already been deployed for setting up SRTP security context and is
also targeted for use in MBMS applications.
</t>
</section>
<!-- ====================================================================== -->
<section anchor="mikey_iana_regs" title="Summary of MIKEY related IANA Registrations">
<t> 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.</t>
<t> The IANA registrations for MIKEY port numbers can be found under
http://www.iana.org/assignments/port-numbers (search for MIKEY).</t>
</section>
<!-- ====================================================================== -->
<section anchor="security" title="Security Considerations">
<t> This document does not define extensions to existing protocols. It rather provides
an overview about the set of MIKEY modes and available extensions and provides information
about the applicability of the different modes in different scenarios to support the
decision making for network architects regarding the appropriate MIKEY scheme or
extension to be used in a dedicated target scenario. Choosing between the different
schemes described in this document strongly influences the security of the target
system as the different schemes provide different level of security and also
require different infrastructure support.</t>
<t> As this document bases on the MIKEY base specification as well as the different
specifications of the extensions the reader is referred to the original documents
for the specific security considerations. </t>
</section>
<!-- ====================================================================== -->
<section title="IANA Considerations">
<t>This document does not require any IANA registration.</t>
</section>
<!-- ====================================================================== -->
<section title="Acknowledgments">
<t>The authors would like to thank Lakshminath Dondeti for his document
reviews and for his guidance.</t>
</section>
</middle>
<!-- ====================================================================== -->
<back>
<references title="Normative References">
&RFC3830;
</references>
<references title="Informative References">
<reference anchor="H.235.7">
<front>
<title>"ITU-T Recommendation H.235.7: Usage of the MIKEY Key Management Protocol for the Secure Real Time Transport Protocol (SRTP) within H.235"
</title>
<author>
<organization/>
</author>
<date year="2005"/>
</front>
</reference>
<reference anchor="SAML_overview">
<front>
<title>"Security Assertion Markup Language (SAML) 2.0 Technical Overview, Working Draft"
</title>
<author initials="J." surname="Huges" fullname="J.Huges">
<organization/>
</author>
<author initials="E." surname="Maler" fullname="E.Maler">
<organization/>
</author>
<date year="2005"/>
</front>
</reference>
<reference anchor="ISO_sec_time">
<front>
<title>"ISO/IEC 18014 Information technology - Security techniques - Time-stamping services, Part 1-3."
</title>
<author>
<organization/>
</author>
<date year="2002"/>
</front>
</reference>
&RFC4568; &RFC4567;
&RFC4566; &RFC3261; &RFC3711; &RFC4082; &RFC1305; &RFC2412;
&RFC3525; &RFC4383; &RFC2119; &RFC4442; &RFC4563; &RFC4650;
&RFC4771; &RFC4738; &RFC4597; &RFC4909; &RFC4949; &RFC5027;
&I-D.ietf-msec-mikey-ecc; &I-D.baugher-mmusic-sdp-dh;
&I-D.ietf-avt-dtls-srtp; &I-D.zimmermann-avt-zrtp;
&I-D.wing-mmusic-sdes-early-media; &I-D.mcgrew-srtp-ekt;
&I-D.ietf-sip-media-security-requirements;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 04:52:59 |