World Library  
Flag as Inappropriate
Email this Article


Article Id: WHEBN0004342215
Reproduction Date:

Title: Mikey  
Author: World Heritage Encyclopedia
Language: English
Subject: List of RFCs, SDES, SIP URI scheme, Cryptographic protocols, Secure Real-time Transport Protocol
Publisher: World Heritage Encyclopedia


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 1
  • Using MIKEY in practice 2
    • Use Cases 2.1
  • Key Transport and Exchange Methods 3
  • MIKEY Messages 4
    • MIKEY Message Content 4.1
  • See also 5
  • References 6

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:

  • One-to-one communications
  • Conference communications
  • Group Broadcast
  • Call Divert
  • Call Forking
  • Delayed delivery (Voicemail)

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):

  • Pre-Shared Key (MIKEY-PSK): This is the most efficient way to handle the transport of the Common Secret, since only symmetric encryption is used and only a small amount of data has to be exchanged. However, an individual key has to be shared with every single peer, which leads to scalability problems for larger user groups.
  • Public-Key (MIKEY-PK): The Common Secret is exchanged with the help of public key encryption. In larger systems, this requires a PKI to handle the secure distribution of public keys.
  • Diffie-Hellman (MIKEY-DH): A Diffie-Hellman key exchange is used to set up the Common Secret. This method has a higher resource consumption (both computation time and bandwidth) than the previous ones, but has the advantage of providing perfect forward secrecy. Also, it can be used without any PKI.
  • DH-HMAC (MIKEY-DHHMAC) (HMAC-Authenticated Diffie-Hellman): This is a light-weight version of Diffie-Hellman MIKEY: instead of certificates and RSA signatures it uses HMAC to authenticate the two parts to one another. DH-HMAC is defined in RFC 4650.
  • RSA-R (MIKEY-RSA-R) (Reverse RSA): The Common Secret is exchanged with the help of public key encryption in a way that doesn't require any PKI: the initiator sends its public RSA key to the responder, which responds by selecting the Common Secret and then send it back to the initiator encrypted with the initiator's public key. RSA-R is defined in RFC 4738.
  • TICKET (MIKEY-TICKET): Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY). MIKEY-TICKET is defined in RFC 6043.
  • IBAKE (MIKEY-IBAKE): Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY). MIKEY-IBAKE is defined in RFC 6267.
  • SAKKE (MIKEY-SAKKE): Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY). This is an Identity-Based Authenticated Key Exchange method. MIKEY-SAKKE is defined in RFC 6509.

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:

  • A timestamp payload (T) - this contains the time and hence helps protect against replay attacks.
  • Identity Payloads (ID) - this identifies the participants. This payload type can also contain certificates (CERT). This was extended in RFC 6043 to include the 'role' of the user as part of the ID (IDR).
  • A RAND payload (RAND) - this is random data used to salt the post-exchange key derivation.
  • Security Policies (SP) - this contains a limited set of security policies to support the communication.
  • Certificate Hash (CHASH) - a hash indicating a certificate used for public-key encryption.

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

  • Key data transport (KEMAC) - this encapsulating the key by encrypting it using a pre-shared secret. This is extended by RFC 4650 to support authenticated Diffie-Hellman (DHHMAC).
  • Diffie-Hellman (DH) - this contains cryptographic information supporting the Diffie-Hellman protocol.
  • Envelope Data (PKE) - this encapsulates the key using public key encryption. This is extended by RFC 4738 and RFC 6267.
  • Sakai-Kasahara (SAKKE) - this encapsulates the key using the identity-based Sakai-Kasahara protocol. This is defined by RFC 6509.
  • Ticket (TICKET) - provides a cryptographic token to request key material from a external server (KMS). This is defined by RFC 6043.

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

  • Signature (SIGN) - a signature on the MIKEY message.
  • Verification (V) - a MAC sent by the receiver to verify receipt.

See also


  1. ^
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.