MIKEY: Multimedia Internet KEYing

Arkko, Jari; Carrara, Elisabetta; Lindholm, Fredrik; Norrman, Karl; Näslund, Mats

doi:10.17487/rfc3830

Cited by 174 publications

(214 citation statements)

References 0 publications

Supporting

Mentioning

212

Contrasting

Unclassified

Order By: Relevance

“…Note that in [RFC3830], there is defined both a V payload (carrying the authentication tag) and a V flag in the HDR payload (indicating whether or not a response message is expected).…”

Section: Solid Arrows (----->) Indicate Mandatory Messages Dashed Armentioning

confidence: 99%

“…The pre-shared key method and the public-key encryption method defined in [RFC3830] are examples of systems based on pre-distribution of user credentials. The DiffieHellman method [RFC3830] is an example of a system based on negotiation and exchange directly between peers.…”

Section: Design Considerationsmentioning

confidence: 99%

“…To prevent any form of eavesdropping, only the endpoint that answers should get access to the session keys. The naive application of [RFC3830] where all endpoints share the same pre-shared/private key is not secure when it comes to forking, as all endpoints get access to the session keys. Conversely, having per-user unique pre-shared keys/ certificates creates more fundamental problems with forking, as the initiator does not know which pre-shared key/certificate to use at session initiation.…”

Section: Design Considerationsmentioning

confidence: 99%

“…The modes described in the Multimedia Internet KEYing (MIKEY) specification [RFC3830] and its extensions [RFC4650] [RFC4738] are all variants of the first two alternatives.…”

mentioning

confidence: 99%

See 3 more Smart Citations

MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)

Tian¹,

Mattsson²

2011

View full text Add to dashboard Cite

The Multimedia Internet KEYing (MIKEY) specification describes a key management scheme for real-time applications. In this document, we note that the currently defined MIKEY modes are insufficient to address deployment scenarios built around a centralized key management service. Interest in such deployments is increasing. Therefore, a set of new MIKEY modes that work well in such scenarios are defined. The new modes use a trusted key management service and a ticket concept, similar to that in Kerberos. The new modes also support features used by many existing applications, where the exact identity of the other endpoint may not be known at the start of the communication session.

show abstract

“…Note that in [RFC3830], there is defined both a V payload (carrying the authentication tag) and a V flag in the HDR payload (indicating whether or not a response message is expected).…”

Section: Solid Arrows (----->) Indicate Mandatory Messages Dashed Armentioning

confidence: 99%

Section: Design Considerationsmentioning

confidence: 99%

Section: Design Considerationsmentioning

confidence: 99%

“…The modes described in the Multimedia Internet KEYing (MIKEY) specification [RFC3830] and its extensions [RFC4650] [RFC4738] are all variants of the first two alternatives.…”

mentioning

confidence: 99%

See 2 more Smart Citations

MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)

Tian¹,

Mattsson²

2011

View full text Add to dashboard Cite

show abstract

“…However, the establishment of multicast security associations (phase 2b) typically does not involve EAP and needs to be handled by a group key management protocol such as Group Domain of Interpretation (GDOI) [RFC3547], Group Secure Association Key Management Protocol (GSAKMP) [RFC4535], Multimedia Internet KEYing (MIKEY) [RFC3830], or Group Key Distribution Protocol (GKDP) [GKDP]. Several mechanisms have been proposed for the discovery of IPsec security gateways.…”

Section: Ikev2mentioning

confidence: 99%

Extensible Authentication Protocol (EAP) Key Management Framework

Aboba¹,

Simon²,

Eronen³

2008

122

102

View full text Add to dashboard Cite

IMS security

Anderlind

Faucher

Grosse³

et al. 2006

Bell Labs Tech. J.

View full text Add to dashboard Cite

deployments of NGNs and must provide equivalent or better security than existing network solutions. In order to accomplish this goal, IMS security needs to be addressed in a comprehensive way to ensure that security needs are understood, standardized solutions are implemented, and security processes are in place to continually advance security as IMS evolves. ITU Telecommunications Standardization Sector (ITU-T) Recommendation X.805, "Security Architecture for Systems Providing End-to-End Communications," is an essential tool in understanding the security required for IMS. In this paper we examine IMS security standards and the use of ITU-T Recommendation X.805 in understanding the key aspects of IMS security that are essential for secure IMS deployments.We begin with a brief overview of the IMS architecture to serve as a reference point for our IMS

show abstract

MIKEY: Multimedia Internet KEYing

Cited by 174 publications

References 0 publications

MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)

MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)

Extensible Authentication Protocol (EAP) Key Management Framework

IMS security

Contact Info

Product

Resources

About