MIKEY

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:

  • 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 an 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.
gollark: Of course, GTech™ apiocomputation tesseracts support memory address resolution with arbitrary recursion depth.
gollark: I think that's back when Rust had a big runtime and such?
gollark: Ah, jabu approaches from the north.
gollark: One Rust program I have is an impressive 80MBish (compiled in debug mode).
gollark: How was that the "smallest possible" one?

See also

References
  1. http://research.ijcaonline.org/volume34/number7/pxc3875930.pdf
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.