MIKEY

For other meanings, see Mikey (disambiguation).

Multimedia Internet KEYing (MIKEY) is a key management protocol that is intended for use with real-time applications. It can specifically be used to set up encryption keys for multimedia sessions that are secured using SRTP, the security protocol commonly used for securing real-time communications such as VoIP.

MIKEY was first defined in RFC 3830. Additional MIKEY modes have been defined in RFC 4650, RFC 4738, RFC 6043, RFC 6267 and RFC 6509.

Purpose of MIKEY

As described in RFC 3830, the MIKEY protocol is intended to provide end-to-end security between users to support a communication. To do this, it shares a session key, known as the Traffic Encryption Key (TEK), between the participants of a communication session. The MIKEY protocol may also authenticate the participants of the communication.

MIKEY provides many methods to share the session key and authenticate participants.

Using MIKEY in practice

MIKEY is used to perform key management for securing a multimedia communication protocol. As such, MIKEY exchanges generally occur within the signalling protocol which supports the communication.

A common setup is for MIKEY to support Secure VoIP by providing the key management mechanism for the VoIP protocol (SRTP). Key management is performed by including MIKEY messages within the SDP content of SIP signalling messages.[1]

Use cases

MIKEY considers how to secure the following use cases:

Not all MIKEY methods support each use case. Each MIKEY method also has its own advantages and disadvantages in terms of feature support, computational complexity and latency of communication setup.

Key transport and exchange methods

MIKEY supports eight different methods to set up a common secret (to be used as e.g. a session key or a session KEK):

MIKEY Messages

The majority of MIKEY methods requires the initiator to send a message to participants (the I_MESSAGE), and the receivers to respond with another message (the R_MESSAGE). Once this exchange has completed, the session key can be generated by the participants. MIKEY-SAKKE does not require an R_MESSAGE.

MIKEY Message Content

MIKEY messages are made up of a number of payloads. Each payload describes the next payload in the MIKEY message. In this way the MIKEY protocol has shown it is flexible to being extended and adapted.

The first payload is always the Common Header (HDR). This identifies the version of the MIKEY protocol, the method used (data type), whether a response is required and it identifies the cryptographic session that will be established via the exchange.

Further payloads are defined by the MIKEY method in use. Frequently these will include information payloads such as:

In addition to this, the MIKEY message will contain at least one payload which encapsulates key material. These include:

Finally, the MIKEY message may contain an authentication payload. These include:

See also

References

This article is issued from Wikipedia - version of the Sunday, May 01, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.