The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)

Carrara, Elisabetta; Norrman, Karl; Lehtovirta, Vesa

doi:10.17487/rfc4563

Cited by 7 publications

(6 citation statements)

References 6 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The V flag MUST be set to '1' but SHALL be ignored by the KMS as a response is MANDATORY. As crypto sessions SHALL NOT be handled, the #CS MUST be set to '0' and the CS ID map type SHALL be the "Empty map" as defined in [RFC4563].…”

Section: Common Components Of the Resolve_init Messagesmentioning

confidence: 99%

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

Section: Common Components Of the Resolve_init Messagesmentioning

confidence: 99%

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

“…The user SHALL set the #CS field to '0' since CS (Crypto Session(s)) SHALL NOT be handled. The CS ID map type SHALL be the "Empty map" as defined in [RFC4563].…”

Section: Request_key_init/request_key_resp Message Exchangementioning

confidence: 99%

“…o CS ID map type (8 bits): specifies the method of uniquely mapping crypto sessions to the security protocol sessions. In the Request Key exchange, the CS ID map type SHALL be the "Empty map" (defined in [RFC4563]) as crypto sessions SHALL NOT be handled.…”

Section: +------------------+-------+--------------------------------mentioning

confidence: 99%

MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)

Cakulev¹,

Sundaram²

2011

View full text Add to dashboard Cite

This document describes a key management protocol variant for the Multimedia Internet KEYing (MIKEY) protocol that relies on a trusted key management service. In particular, this variant utilizes Identity-Based Authenticated Key Exchange (IBAKE) framework that allows the participating clients to perform mutual authentication and derive a session key in an asymmetric Identity-Based Encryption (IBE) framework. This protocol, in addition to providing mutual authentication, eliminates the key escrow problem that is common in standard IBE and provides perfect forward and backward secrecy. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6267.

show abstract

“…This document relaxes the IANA rules for Multimedia Internet KEYing (MIKEY) [RFC3830]. The IANA rules defined in [RFC3830], [RFC4563], [RFC4909], and [RFC5410] are affected. In addition, the rules specified in [RFC6043] are re-specified here.…”

Section: Introductionmentioning

confidence: 99%

IANA Rules for MIKEY (Multimedia Internet KEYing)

Arkko¹,

Keränen²,

Mattsson³

2011

View full text Add to dashboard Cite

This document clarifies and relaxes the IANA rules for Multimedia Internet KEYing (MIKEY). This document updates RFCs 3830, 4563, 5410, and 6043; it obsoletes RFC 4909. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6309.

show abstract

The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)

Cited by 7 publications

References 6 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)

MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)

IANA Rules for MIKEY (Multimedia Internet KEYing)

Contact Info

Product

Resources

About