Network Working Group V. Cakulev
Internet-Draft G. Sundaram
Intended status: Standards Track Alcatel Lucent
Expires: April 17, 2010 October 14, 2009
MIKEY-IBAKE: Identity-Based Mode of Key Distribution in Multimedia
Internet KEYing (MIKEY)
draft-cakulev-mikey-ibake-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 17, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Cakulev & Sundaram Expires April 17, 2010 [Page 1]
Internet-Draft MIKEY-IBAKE October 2009
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Cakulev & Sundaram Expires April 17, 2010 [Page 2]
Internet-Draft MIKEY-IBAKE October 2009
Abstract
This document describes a key management protocol variant for the
multimedia Internet keying (MIKEY) protocol which relies on trusted
key management service. In particular, this variant utilizes
Identity Based Authenticated Key Exchange framework which allows the
participating clients to perform mutual authentication and derive a
session key in an 'asymmetric identity based encryption' framework.
This framework, in addition to providing mutual authentication,
eliminates the key escrow problem that is common in standard Identity
Based Encryption while simultaneously providing perfect forward and
backwards secrecy.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 6
2.1. Definitions and Notation . . . . . . . . . . . . . . . . . 6
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Retargeting . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Deferred Delivery . . . . . . . . . . . . . . . . . . . . 9
4. MIKEY-IBAKE Protocol Description . . . . . . . . . . . . . . . 10
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Message Exchanges and Processing . . . . . . . . . . . . . 12
4.2.1. REQUEST_KEY_INIT/REQUEST_KEY_RESP Message Exchange . . 12
4.2.2. I_MESSAGE/R_MESSAGE Message Exchanges . . . . . . . . 14
5. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Generating Keys from the Session Key . . . . . . . . . . . 19
5.2. Generating Keys for MIKEY Messages . . . . . . . . . . . . 19
5.3. CSB Update . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4. Generating MAC and Verification Message . . . . . . . . . 20
6. Payload Encoding . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Common Header Payload (HDR) . . . . . . . . . . . . . . . 21
6.1.1. IBAKE Payload . . . . . . . . . . . . . . . . . . . . 22
6.1.2. Encrypted Secret Key (ESK) Payload . . . . . . . . . . 23
6.1.3. Key Data Sub-Payload . . . . . . . . . . . . . . . . . 23
6.1.4. EC Diffie-Hellman Sub-Payload . . . . . . . . . . . . 24
6.1.5. Secret Key Sub-Payload . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Normative References . . . . . . . . . . . . . . . . . . . 31
9.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Cakulev & Sundaram Expires April 17, 2010 [Page 3]
Internet-Draft MIKEY-IBAKE October 2009
1. Introduction
Multimedia Internet Keying (MIKEY) [RFC3830] specification describes
several modes of key distribution solution that address multimedia
scenarios using pre-shared keys, public keys, and optionally a
Diffie-Hellman key exchange. Following MIKEY specification, multiple
extensions of MIKEY have been specified.
Recently, it has been noted that the currently defined MIKEY modes
are insufficient to address deployment scenarios in which security
systems serve a large number of users. In these scenarios, a key
management service is often preferred. With such a service in place,
it would be possible for a user to request credentials for any other
user when they are needed. Some proposed solutions rely on Key
Management Services (KMS) in the network that create, distribute, and
manage keys in a real time. Due to this broad functionality, key
management services will have to be online, maintain high
availability, and have to be networked across operator boundaries.
In some applications, this architecture creates a huge burden on
operators to install, and manage these boxes. Moreover, since the
keys are created and distributed by the KMS, these servers are de-
facto escrow points leading to increased vulnerability and
operational discomfort on the part of end-users. In fact, this
feature is a violation of the "end-to-end security" design goals in
Section 2.2 of [RFC3830].
Here, a solution is described in which KMS's are offline servers that
communicate with end-user clients periodically (e.g., once a month)
to create a secure identity-based encryption framework, while the on-
line transactions between the end-user clients (for media plane
security) are based on an Identity Based Authenticated Key Exchange
framework which allows the participating clients to perform mutual
authentication and derive a session key in an 'asymmetric identity
based encryption' framework. This framework, in addition to
eliminating passive escrow, allows for end-user clients to mutually
authenticate each other (at the IMS media plane layer) and provides
perfect forwards and backwards secrecy. Observe that the KMS to
client exchange is used sparingly (e.g., once a month) - hence the
KMS is no longer required to be a high availability server, and in
particular different KMS's don't have to communicate with each other
(across operator boundaries). Moreover, given asymmetric identity-
based encryption framework is used, the need for costly Public Key
Infrastructure (PKI) and all the operational costs of certificate
management and revocation is eliminated. This is achieved by
concatenating public keys with a date field, thereby ensuring
corresponding private keys change with the date and more importantly
limiting the damage due to loss of a private key to just that date.
The granularity in the date field, is a matter of security policy and
Cakulev & Sundaram Expires April 17, 2010 [Page 4]
Internet-Draft MIKEY-IBAKE October 2009
deployment scenario. For instance, an operator may choose to use one
key per day and hence the KMS may issue private keys for a whole
month (more generally subscription cycle) at the beginning of a
subscription cycle.
Additionally, various IMS media plane features are securely supported
- this includes secure forking, retargeting, deferred delivery and
pre-encoded content.
Cakulev & Sundaram Expires April 17, 2010 [Page 5]
Internet-Draft MIKEY-IBAKE October 2009
2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.1. Definitions and Notation
IBE Encryption: Identity-based encryption (IBE) is a public-key
encryption technology that allows a public key to be calculated from
an identity, and the corresponding private key to be calculated from
the public key. IBE framework is defined in [RFC5091], [RFC5408] and
[RFC5409].
(Media) session: The communication session intended to be secured by
the MIKEY-IBAKE provided key(s).
E(k, x) Encryption of x with the key k
K_PUBx Public Key of x
[x] x is optional
{x} Zero or more occurrences of x
(x) One or more occurrences of x
|| Concatenation
| OR (selection operator)
2.2. Abbreviations
EC Elliptic Curve
ESK: Encrypted Secret Key
IBE: Identity Based Encryption
I: Initiator
IBAKE: Identity Based Authenticated Key Exchange
IDi: Initiator's Identity
IDr: Responder's Identity
KMS: Key Management Service
K_PR: Private Key
Cakulev & Sundaram Expires April 17, 2010 [Page 6]
Internet-Draft MIKEY-IBAKE October 2009
K_PUB: Public Key
MAC: Message Authentication Code
MIKEY: Multimedia Internet KEYing
PKI: Public Key Infrastructure
R: Responder
SK: Secret Key
Cakulev & Sundaram Expires April 17, 2010 [Page 7]
Internet-Draft MIKEY-IBAKE October 2009
3. Use Case Scenarios
This section describes some of the use case scenarios supported by
MIKEY-IBAKE.
3.1. Forking
Forking is the delivery of a request (e.g., SIP INVITE message) to
multiple locations. This happens when a single user is registered
more than once. An example of forking is when a user has a desk
phone, PC client, and mobile handset all registered with the same
public identity.
+---+ +-------+ +---+ +---+
| A | | PROXY | | B | | C |
+---+ +-------+ +---+ +---+
Request
-------------------->
Request
-------------------->
Request
------------------------------------->
Figure 1: Forking
3.2. Retargeting
Retargeting is a scenario in which a functional element decides to
redirect the call to a different destination. This decision to
redirect a session may be made for different reasons by a number of
different functional elements, and at different points in the
establishment of the session.
There are two basic scenarios of session redirection. In scenario
one, a functional element (e.g., Proxy) decides to redirect the
session by passing the new destination information to the originator.
As a result the originator initiates a new session to the redirected
destination provided by the Proxy. For the case of MIKEY-IBAKE this
means that the originator will initiate a new session with the
identity of the redirected destination. This scenario is depicted in
Figure 2 below.
Cakulev & Sundaram Expires April 17, 2010 [Page 8]
Internet-Draft MIKEY-IBAKE October 2009
+---+ +-------+ +---+ +---+
| A | | PROXY | | B | | C |
+---+ +-------+ +---+ +---+
Request
-------------------->
Request
-------------------->
Redirect
<--------------------
Redirect
<-------------------
Request
---------------------------------------------------------->
Figure 2: Retargeting
In the second scenario, a proxy decides to redirect the session
without informing the originator. A common scenario in IMS
applications is one in which the S-CSCF of the destination user
determines that the session is to be redirected. The user profile
information obtained from the HSS by the 'Cx-pull' during
registration may contain complex logic and triggers causing session
redirection.
3.3. Deferred Delivery
Deferred delivery is a type of service such that the session content
cannot be delivered to the destination at the time that it is being
sent (e.g., the destination user is not currently online).
Nevertheless, the sender expects the network to deliver the message
as soon as the recipient becomes available. A typical example of
deferred delivery is voicemail.
Cakulev & Sundaram Expires April 17, 2010 [Page 9]
Internet-Draft MIKEY-IBAKE October 2009
4. MIKEY-IBAKE Protocol Description
4.1. Overview
Most of the previously defined MIKEY modes consist of a single (or
half) roundtrip between two peers. MIKEY-IBAKE consists of up to
three roundtrips. In the first roundtrip, users (Initiators and
Responders) obtain their Private Key(s) (K_PR) from the KMS. This
roundtrip can be performed at anytime, and as explained earlier takes
place for example once a month (or once per subscription cycle). The
second and the third roundtrip are between the Initiator and the
Responder. Observe that the Key Management Service is only involved
in the first roundtrip. In Figure 3, a conceptual signaling diagram
for the MIKEY-IBAKE mode is depicted.
+---+ +------+ +------+ +---+
| I | | KMS1 | | KMS2 | | R |
+---+ +------+ +------+ +---+
REQUEST_KEY_INIT REQUEST_KEY_INIT
------------------> <----------------------
REQUEST_KEY_RESP REQUEST_KEY_RESP
<------------------ ---------------------->
I_MESSAGE_1
----------------------------------------------------------->
R_MESSAGE_1
<-----------------------------------------------------------
I_MESSAGE_2
----------------------------------------------------------->
R_MESSAGE_2
<-----------------------------------------------------------
Figure 3: Example Message Exchange
The Initiator (I) wants to establish a secure media session with the
Responder (R). The Initiator and the Responder trust a third party,
the Key Management Services (KMS), with which they both have, or can
establish, shared credentials. Rather than a single KMS, several
different KMSs may be involved, e.g. one for the Initiator and one
for the Responder as shown in Figure 3 above. The Initiator and the
Responder do not share any credentials, however the Initiator knows
Responder's public identity.
The Initiator obtains Private Key(s) from the KMS by sending a
REQUEST_KEY_INIT message. The REQUEST_KEY_INIT message includes
Initiator's public identity(s) (if the Initiator has more than one
public identity it may request an Private Key for every identity
Cakulev & Sundaram Expires April 17, 2010 [Page 10]
Internet-Draft MIKEY-IBAKE October 2009
registered) and is protected via a MAC based on a pre-shared key or
via a signature (similar to the MIKEY-PSK and MIKEY-RSA modes). If
the Initiator is authorized to make the request, the KMS generates
the requested keys, encodes them, and returns them in a
REQUEST_KEY_RESP message. The KMS can also select a set of IBE
public parameters to use in the subsequent steps in accordance with
its local security policy and include them in the same message. This
exchange takes place periodically and does not need to be performed
every time an Initiator needs to establish a secure connection with a
Responder.
The Initiator next chooses a random x and computes xP (i.e. adds P to
itself x times), where P is a point on elliptic curve E known to all
users. The Initiator uses the Responder's public identity to
generate Responder's public key (e.g., K_PUBr=H1(IDr)||date), where
Hi is hash function known to all users, and the granularity in date
is a matter of security policy and known publicly). The Initiator
then uses this generated public key to encrypt xP, IDi and IDr and
includes this encrypted information in a I_MESSAGE_1 message, which
is sent to the Responder. The encryption is Identity Based
Encryption (IBE) as specified in [RFC5091] and [RFC5408]. The
Responder in turn IBE-decrypts the received message using its private
key for that date, chooses random y and computes yP. Next, the
Responder uses Initiator's public identity to generate Initiator's
public key (e.g., K_PUBi=H1(IDi)||date) and IBE-encrypts (IDi, IDr,
xP, yP) using K_PUBi, and includes it in R_MESSAGE_1 message sent to
the Initiator. At this point the Responder is able to generate the
session key as xyP. This session key is then used to generate TGK as
specified in Section 5.1.
The Initiator upon receiving and IBE-decrypting R_MESSAGE_1 message
sends I_MESSAGE_2 message to the Responder, including IBE-encrypted
IDi, IDr and yP. At this point the Initiator is able to generate the
same session key as xyP. The Responder sends a R_MESSAGE_2 message
to the Initiator as verification.
The above described is the most typical use case; in Section 3, some
alternative use cases are discussed.
MIKEY-IBAKE is based on [RFC3830], therefore the same terminology,
processing and considerations still apply unless otherwise stated.
Diffie-Hellman values and keys exchanged in I_MESSAGE/R_MESSAGE are
IBE encrypted as specified in [RFC5091] and [RFC5408], while the keys
exchanged in KEY_REQUES_INIT/KEY_REQUEST_RESPONSE are encrypted as
specified in [RFC3830]. In all exchanges encryption is only applied
to the keys and key components and not to the entire messages.
Cakulev & Sundaram Expires April 17, 2010 [Page 11]
Internet-Draft MIKEY-IBAKE October 2009
4.2. Message Exchanges and Processing
4.2.1. REQUEST_KEY_INIT/REQUEST_KEY_RESP Message Exchange
This exchange is used by a user (e.g. Initiator or Responder) to
request private keys from a trusted Key Management Service, with
which the user have pre-shared credentials. A full roundtrip is
required for a user to receive keys. As this message must ensure the
identity of the Initiator to the KMS, it is protected via a MAC based
on a pre-shared key or via a signature. The initiation message
REQUEST_KEY_INIT comes in two variants corresponding to the pre-
shared key (PSK) and public-key encryption (PKE) methods of
[RFC3830]. The response message REQUEST_KEY_RESP is the same for the
two variants and SHALL be protected by using the pre- shared/envelope
key indicated in the REQUEST_KEY_INIT message.
Initiator/Responder KMS
REQUEST_KEY_INIT_PSK = ---->
HDR, T, RAND, (IDi/r),
IDkms, [IDpsk], [KEMAC], V <---- REQUEST_KEY_RESP =
HDR, T, [IDi/r], [IDkms],
KEMAC, V
REQUEST_KEY_INIT_PKE = ---->
HDR, T, RAND, (IDi/r),
{CERTi/r}, IDkms, <---- REQUEST_KEY_RESP =
[KEMAC], [CHASH], HDR, T, [IDi/r], [IDkms],
PKE, SIGNi/r, V KEMAC, V
4.2.1.1. Components of the REQUEST_KEY_INIT Message
The main objective of the REQUEST_KEY_INIT message is for a user to
request one or more Private Keys (K_PR) from the KMS. The user may
request a K_PR for each public identity it possesses.
The REQUEST_KEY_INIT message MUST always include the Header (HDR),
Timestamp (T), and RAND payloads. The user SHALL select a random CSB
ID (Crypto Session Bundle ID) and include it in the CSB ID field of
the Header. 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].
IDi/r contains the identity of the user. Since the user may have
multiple identities, multiple IDi/r fields may appear in the message.
Cakulev & Sundaram Expires April 17, 2010 [Page 12]
Internet-Draft MIKEY-IBAKE October 2009
IDkms SHALL be included.
The KEMAC payload SHOULD be used only when the user needs to use
specific keys. Otherwise, this payload SHALL not be used.
4.2.1.1.1. Components of the REQUEST_KEY_INIT_PSK Message
The IDpsk payload MAY be used to indicate the pre-shared key used.
The last payload SHALL be a Verification payload (V) where the
authentication key (auth_key) is derived from the pre-shared key (see
[RFC3830] Section 4.1.4 for key derivation specification).
4.2.1.1.2. Components of the REQUEST_KEY_INIT_PKE Message
CERTi SHOULD may be included. If a certificate chain is to be
provided, each certificate in the chain MUST be included in a
separate CERT payload.
PKE payload contains the encrypted envelope key: PKE = E(PKkms,
env_key). It is encrypted using the KMS's public key (PKkms). If
the KMS possesses several public keys, the user can indicate the key
used in the CHASH payload.
SIGNi/r is a signature covering the entire MIKEY message, using the
Initiator's signature key.
4.2.1.2. Processing of the REQUEST_KEY_INIT Message
If the KMS can correctly parse the received message, and the user is
authorized to receive the requested Private Key(s), the KMS MUST send
a REQUEST_KEY_RESP message. In case of a REQUEST_KEY_INIT_PKE
message, the KMS MUST ensure that the IDcert is equal to the identity
specified in the certificate.
If the KMS cannot correctly parse the received message, or the user
is not authorized to receive the requested Private Keys, the KMS
SHOULD send an appropriate Error message.
4.2.1.3. Components of the REQUEST_KEY_RESP Message
The Header payload SHOULD be identical to the Header payload in the
REQUEST_KEY_INIT message with the exception of data type, next
payload, and V flag. The V flag can be set to anything as it has no
meaning in this context.
The timestamp type and value SHALL be identical to the one used in
the REQUEST_KEY_INIT message.
Cakulev & Sundaram Expires April 17, 2010 [Page 13]
Internet-Draft MIKEY-IBAKE October 2009
KEMAC = E(encr_key, {ID || K_PR})
The KEMAC payload SHOULD use the NULL authentication algorithm, as a
MAC is included in the V payload. Depending on the type of
REQUEST_KEY_INIT message, either the pre-shared key or the envelope
key SHALL be used to derive the encr_key.
The last payload SHALL be a Verification payload (V). Depending on
the type of REQUEST_KEY_INIT message, either the pre-shared key or
the envelope key SHALL be used to derive the auth_key.
4.2.1.4. Processing of the REQUEST_KEY_RESP Message
If the Initiator/Responder can correctly parse the received message,
the received session information SHOULD be stored. Otherwise the
Initiator/Responder SHOULD silently discard the message and abort the
protocol.
4.2.2. I_MESSAGE/R_MESSAGE Message Exchanges
This exchange is used for Initiator and Responder to mutually
authenticate each other and to exchange ECC Diffie-Hellman values
used to generate TGK. These exchanges are modeled after the pre-
shared key mode , with the exception that the Elliptic Curve Diffie-
Hellman values and Secret Keys (SKs) are encoded in IBAKE and ESK
payloads instead of a KEMAC payload. Two full roundtrips are
required for this exchange to successfully complete. The messages
are preferably included in the session setup signaling (e.g. SIP
INVITE).
Initiator Responder
I_MESSAGE_1 = ---->
HDR, T, RAND, IDi, IDr,
IBAKE, [ESK], V <---- R_MESSAGE_1 =
HDR, T, IDi,
IDr, IBAKE, V
I_MESSAGE_2 = ---->
HDR, T, RAND, IDi, IDr,
IBAKE, [ESK], V <---- R_MESSAGE_2 =
HDR, T, [IDi], [IDr],
[IBAKE], V
Cakulev & Sundaram Expires April 17, 2010 [Page 14]
Internet-Draft MIKEY-IBAKE October 2009
4.2.2.1. Components of the I_MESSAGE_1 Message
The I_MESSAGE_1 message MUST always include the Header (HDR),
Timestamp (T), and RAND payloads. The CSB ID (Crypto Session Bundle
ID) SHALL be randomly selected by the Initiator. As the R_MESSAGE_1
message is mandatory, the Initiator indicates with the V flag that a
verification message is expected.
The IDi and IDr payloads SHALL be included.
The IBAKE payload contains Initiator's Identity and EC Diffie-Hellman
values (ECCPTi), and Responder's Identity all encrypted using
Responder's public key (i.e. encr_key = K_PUBr) as follows:
IBAKE = E(encr_key, IDi || ECCPTi || IDr)
Optionally, Encrypted Secret Key (ESK) payload MAY be included. If
included, ESK contains an identity and a Secret Key (SK) encrypted
using intended Responder's Public Key (i.e. encr_key = K_PUBr).
ESK = E(encr_key, ID || SK)
The last payload SHALL be a Verification payload (V) where the
authentication key (auth_key) is derived as specified in Section 5.2.
4.2.2.2. Processing of the I_MESSAGE_1 Message
The parsing of I_MESSAGE_1 message SHALL be done as in [RFC3830]. If
the received message is correctly parsed, the Responder shall use the
Private Key (K_PRr) corresponding to the received IDr to decrypt the
IBAKE payload. If the message contains encrypted ESK payload, the
Responder SHALL decrypt the SK and use it to decrypt the received
IBAKE payload. Otherwise, if the Responder is not able to decrypt
the IBAKE payload, the Responder SHALL indicate it to the Initiator
by including only its own EC Diffie-Hellman value (ECCPTr) in the
next message it sends to the Initiator.
If the received message cannot be correctly parsed, the Responder
SHOULD silently discard the message and abort the protocol.
4.2.2.3. Components of the R_MESSAGE_1 Message
The Header payload SHOULD be identical to the Header payload in the
I_MESSAGE_1 message with the exception that the V flag can be set to
anything as it has no meaning in this context.
Cakulev & Sundaram Expires April 17, 2010 [Page 15]
Internet-Draft MIKEY-IBAKE October 2009
The timestamp type and value SHALL be identical to the one used in
the I_MESSAGE_1 message.
The IDi and IDr payloads SHALL be included.
The Responder's IBAKE payload contains the Initiator's EC Diffie-
Hellman value (ECCPTi) received in I_MESSAGE_1 (if successfully
decrypted), and Initiator's EC Diffie-Hellman value generated by
Responder (ECCPTr), as well as corresponding Initiator and
Responder's identities. If the responder is unable to decrypt the
IBAKE payload received in I_MESSAGE_1, the Responder SHALL include
only its own EC Diffie-Hellman value (ECCPTr). The IBAKE payload in
R_MESSAGE_1 is encrypted using Initiator's public key (i.e. encr_key
= P_PUBi) as follows:
IBAKE = E(encr_key, IDi || {ECCPTi} || IDr || ECCPTr)
The last payload SHALL be a Verification payload (V) where the
authentication key (auth_key) is derived as specified in Section 5.2.
4.2.2.4. Processing of the R_MESSAGE_1 Message
The parsing of R_MESSAGE_1 message SHALL be done as in [RFC3830]. If
the received message is correctly parsed, the Initiator shall use the
Private Key corresponding to the received IDi to decrypt the IBAKE
payload. If the ECCPTi sent in I_MESSAGE_1 is not present in the
received IBAKE payload (e.g., the Responder is currently offline and
the R_MESSAGE_1 is received from Responder's mailbox), it SHALL be
included again in the next message, I_MESSAGE_2. In this case
I_MESSAGE_2 SHALL also contain a ESK payload encrypted using
Responder's K_PUB.
If the received message cannot be correctly parsed, the Initiator
SHOULD silently discard the message and abort the protocol.
4.2.2.5. Components of the I_MESSAGE_2 Message
The I_MESSAGE_2 message MUST always include the Header (HDR),
Timestamp (T), and RANDi payloads. The CSB ID (Crypto Session Bundle
ID) and RAND payloads SHALL be the same is in the corresponding
I_MESSAGE_1. As the R_MESSAGE_2 message is mandatory, the Initiator
indicates with the V flag that a verification message is expected.
The IDi and IDr payloads SHALL be included. The IDr payload SHALL be
the same as the IDr payload received in the R_MESSAGE_1.
The Initiator's IBAKE payload SHALL contain Initiator's EC Diffie-
Cakulev & Sundaram Expires April 17, 2010 [Page 16]
Internet-Draft MIKEY-IBAKE October 2009
Hellman value (ECCPTi) is the ECCPTi was not received in R_MESSAGE_1.
Otherwise ECCPTi SHALL NOT be included. The IBAKE payload in
I_MESSAGE_2 SHALL contain the Initiator's and Responder's identities
as well as Responder's EC Diffie-Hellman value received in message
R_MESSAGE_1. IBAKE payload SHALL be encrypted using Responder's
public key (i.e. encr_key = K_PUBr) as follows:
IBAKE = E(encr_key, IDi || {ECCPTi} || IDr || ECCPTr)
Optionally, Encrypted Secret Key (ESK) payload can be included. ESK
SHALL be included in case of deferred delivery. If included, it
contains an identity and Initiator generated Secret Key (SK)
encrypted using intended recipient Public Key (PK) (i.e. encr_key =
P_PUB) as follows:
ESK = E(encr_key, ID || SK)
The last payload SHALL be a Verification payload (V) where the
authentication key (auth_key) is derived as specified in Section 5.2.
4.2.2.6. Processing of the I_MESSAGE_2 Message
The parsing of I_MESSAGE_2 message SHALL be done as in [RFC3830]. If
the received message is correctly parsed, the Responder shall use the
K_PRr corresponding to the received IDr to decrypt the IBAKE payload.
If ESK is received, the responder SHALL store it for the future use.
If the received message cannot be correctly parsed, the Responder
SHOULD silently discard the message and abort the protocol.
4.2.2.7. Components of the R_MESSAGE_2 Message
The Header payload SHOULD be identical to the Header payload in the
I_MESSAGE_2 message with the exception that the V flag can be set to
anything as it has no meaning in this context.
The timestamp type and value SHALL be identical to the one used in
the I_MESSAGE_2 message.
The IDi and IDr payloads SHOULD be included.
Optionally, the Responder's IBAKE payload MAY be included. The IBAKE
payload is included in the case of deferred delivery. If included,
it contains Initiator's EC Diffie-Hellman value (ECCPTi), and the
Initiator's identity, encrypted using Initiator's public key (i.e.
encr_key = K_PUBi) as follows:
Cakulev & Sundaram Expires April 17, 2010 [Page 17]
Internet-Draft MIKEY-IBAKE October 2009
IBAKE = E(encr_key, IDi || ECCPTi)
The last payload SHALL be a Verification payload (V) where the
authentication key (auth_key) is derived as specified in Section 5.2.
4.2.2.8. Processing of the R_MESSAGE_2 Message
The parsing of R_MESSAGE_2 message SHALL be done as in [RFC3830]. If
the received message is correctly parsed, the Responder shall use the
K_PRr corresponding to the received IDr to decrypt the IBAKE payload.
If the received message cannot be correctly parsed, the Initiator
SHOULD silently discard the message and abort the protocol.
Cakulev & Sundaram Expires April 17, 2010 [Page 18]
Internet-Draft MIKEY-IBAKE October 2009
5. Key Derivation
The keys used in REQUEST_KEY_INIT/REQUEST_KEY_RESP exchange are
derived from the pre-shared key or the envelope key as specified in
[RFC3830]. As crypto sessions are not handled in this exchange,
further keying material (i.e TEKs) for this message exchanges SHALL
NOT be derived.
5.1. Generating Keys from the Session Key
As stated above, the session key xyP is generated using exchanged key
components, where x and y are randomly chosen by Initiator and
Responder. The session key as a point on an elliptic curve is then
converted into octet string as specified in [SEC1]. This octet
string is used as TGK. Finally, the keys (e.g., TEK) are generated
from TGK as specified in [RFC3830].
5.2. Generating Keys for MIKEY Messages
The keys for MIKEY messages are used to protect the MIKEY messages
exchanged between the Initiator and Responder (i.e., I_MESSAGE and
R_MESSAGE). In the REQUEST_KEY_INIT/REQUEST_KEY_RESP exchange, the
key derivation SHALL be done exactly as in [RFC3830].
The initiator and Responder SHALL convert their respective EC Diffie-
Hellman values (i.e., ECCPTi and ECCPTr) to obtain the MIKEY
Protection Key (MPK) and then use this MPK to derive keys to protect
I_MESSAGE and R_MESSAGE messages.
inkey : MPK
inkey_len : bit length of the MPK
label : constant || 0xFF || csb_id || RAND
outkey_len : desired bit length of the output key
where the constants are as defined in [RFC3830].
5.3. CSB Update
Similar to [RFC3830], MIKEY-IBAKE provides means for updating the CSB
(Crypto Session Bundle), e.g. transporting new EC Diffe-Hellman
values or adding new crypto sessions. The CSB updating is done by
executing the exchange of I_MESSAGE_1/R_MESSAGE_1. The CSB updating
MAY be started by either the Initiator or the Responder.
Cakulev & Sundaram Expires April 17, 2010 [Page 19]
Internet-Draft MIKEY-IBAKE October 2009
Initiator Responder
I_MESSAGE_1 = ---->
HDR, T, [IDi], [IDr],
[IBAKE], V <---- R_MESSAGE_1 =
HDR, T, [IDi], [IDr], V
Responder Initiator
I_MESSAGE_1 = ---->
HDR, T, [IDr], [IDi],
[IBAKE], V <---- R_MESSAGE_1 =
HDR, T, [IDi], V
The new message exchange MUST use the same CSB ID as the initial
exchange, but MUST use a new timestamp. Other payloads that were
provided in the initial exchange SHOULD NOT be included. New RANDs
MUST NOT be included in the message exchange (the RANDs will only
have effect in the initial exchange).
IBAKE payload with new EC Diffie-Hellman values SHOULD be included.
If new EC Diffie-Hellman values are being exchanged during CSB
updating, both messages SHALL be protected with keys derived from EC
Diffie-Hellman values exchanged as specified in Section 5.2.
Otherwise, if new EC Diffie-Hellman values are not being exchanged
during CSB update exchange, both messages SHALL be protected with the
keys that protected the I_MESSAGE/R_MESSAGE messages in the initial
exchange.
5.4. Generating MAC and Verification Message
Authentication tag in all MIKEY-IBAKE messages is generated as
described in [RFC3830]. The MPK as described above is used to derive
the auth_key. The MAC/Signature in the V/SIGN payloads covers the
entire MIKEY message, except the MAC/Signature field itself. The
identities (not whole payloads) of the involved parties MUST directly
follow the MIKEY message in the Verification MAC/Signature
calculation. Note that in the I_MESSAGE/R_MESSAGE exchange, ID_r in
R_MESSAGE_1 MAY not be the same as that appearing in I_MESSAGE_1.
Cakulev & Sundaram Expires April 17, 2010 [Page 20]
Internet-Draft MIKEY-IBAKE October 2009
6. Payload Encoding
This section does not describe all the payloads that are used in the
new message types. It describes in detail the new IBAKE and ESK
payloads and in less detail the payloads for which changes has been
made compared to [RFC3830]. For a detailed description of the MIKEY
payloads, see [RFC3830].
6.1. Common Header Payload (HDR)
For the Common Header Payload, new values are added to the data type
and the next payload name spaces.
o Data type (8 bits): describes the type of message.
+------------------+-------+-----------------------------------+
| Data Type | Value | Comment |
+------------------+-------+-----------------------------------+
| REQUEST_KEY_PSK | TBD1 | Secret Keys request message (PSK) |
| | | |
| REQUEST_KEY_PKE | TBD2 | Secret Keys request message (PKE) |
| | | |
| REQUEST_KEY_RESP | TBD3 | Secret Keys response message |
| | | |
| I_MESSAGE_1 | TBD4 | First Initiator's message |
| | | |
| R_MESSAGE_1 | TBD5 | First Responder's message |
| | | |
| I_MESSAGE_2 | TBD6 | Second Initiator's message |
| | | |
| R_MESSAGE_2 | TBD7 | Second Responder's message |
+------------------+-------+-----------------------------------+
Table 1: Data type (Additions)
o Next payload (8 bits): identifies the payload that is added after
this payload.
Cakulev & Sundaram Expires April 17, 2010 [Page 21]
Internet-Draft MIKEY-IBAKE October 2009
+--------------+-------+---------------+
| Next Payload | Value | Section |
+--------------+-------+---------------+
| IBAKE | TBD8 | Section 6.1.1 |
| | | |
| ESK | TBD9 | Section 6.1.2 |
| | | |
| SK | TBD10 | Section 6.1.5 |
+--------------+-------+---------------+
Table 2: Next Payload (Additions)
o V (1 bits): flag to indicate whether a response message is
expected or not (this only has meaning when it is set in an
initiation message). If a response is required, the V flag SHALL
always be set to 1 in the initiation messages and the receiver of
the initiation message (Responder or KMS) SHALL ignore it.
o #CS (8 bits): indicates the number of crypto sessions that will be
handled within the CBS. It SHALL be set to 0 in the Request Key
exchange, as crypto sessions SHALL NOT be handled.
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.
6.1.1. IBAKE Payload
The IBAKE payload contains IBE encrypted (see [RFC5091]) and
[RFC5408]) for details about IBE encryption) Initiator and
Responder's Identities and EC Diffie-Hellman sub-payloads (see
Section 6.1.4 for the definition of EC Diffie-Hellman sub-payload).
It may contain one or more EC Diffie-Hellman sub-payloads and its
associated identities. The last EC Diffie-Hellman or Identity sub-
payload has its Next payload field set to Last payload.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Encr data len ! Encr data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Encr data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cakulev & Sundaram Expires April 17, 2010 [Page 22]
Internet-Draft MIKEY-IBAKE October 2009
o Next payload (8 bits): identifies the payload that is added after
this payload.
o Encr data len (16 bits): length of Encr data (in bytes).
o Encr data (variable length): the encrypted EC Diffie-Hellman sub-
payloads (see Section 6.1.4).
6.1.2. Encrypted Secret Key (ESK) Payload
The Encrypted Secret Key payload contains IBE encrypted (see
[RFC5091]) and [RFC5408]) for details about IBE encryption) Secret
Key sub-payload and its associated identity (see Section 6.1.5 for
the definition of the Secret Key sub-payload).
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Encr data len ! Encr data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Encr data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Next payload (8 bits): identifies the payload that is added after
this payload.
o Encr data len (16 bits): length of Encr data (in bytes).
o Encr data (variable length): the encrypted secret key sub-payloads
(see Section 6.1.5).
6.1.3. Key Data Sub-Payload
For the key data sub-payload, a new type of key is defined. The
Private Key (K_PR) is used to decrypt the content encrypted using the
corresponding Public Key (K_PUB). KEMAC in the REQUEST_KEY_RESP
SHALL contain one or more Private Keys.
o Type (4 bits): indicates the type of key included in the payload.
+------+-------+-------------+
| Type | Value | Comments |
+------+-------+-------------+
| K_PR | TBD11 | Private Key |
+------+-------+-------------+
Table 3: Key Data Type (Additions)
Cakulev & Sundaram Expires April 17, 2010 [Page 23]
Internet-Draft MIKEY-IBAKE October 2009
6.1.4. EC Diffie-Hellman Sub-Payload
The EC Diffie-Hellman Sub-Payload uses the same format as ECC Point
Payload (ECCPT) defined in [I-D.ietf-msec-mikey-ecc]. However, ECCPT
in MIKEY-IBAKE is never included in clear, but as an encrypted part
of the IBAKE payload. The payload identifier is 22.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! ECC Curve ! ECC Point ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Auth alg ! TGK len ! Reserv! KV !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Next payload (8 bits): identifies the payload that is added after
this payload. See Section 6.1 of [RFC3830] for values.
o ECC curve (8 bits): identifies the ECC curve used.
o ECC point (variable length): ECC point data, padded to end on a
32-bit boundary, encoded in octet string representation.
o Auth alg (8 bits): specifies the MAC algorithm used for the
verification message. For MIKEY-IBAKE this field is ignored.
o TGK len (16 bits): the length of the TGK (in bytes). For MIKEY-
IBAKE this field is ignored.
o KV (4 bits): indicates the type of key validity period specified.
This may be done by using an SPI (alternatively an MKI in SRTP) or
by providing an interval in which the key is valid (e.g., in the
latter case, for SRTP this will be the index range where the key
is valid). See Section 6.13 of [RFC3830] for pre-defined values.
o KV data (variable length): This includes either the SPI/MKI or an
interval (see Section 6.14 of [RFC3830]). If KV is NULL, this
field is not included.
6.1.5. Secret Key Sub-Payload
Secret Key payload is included as a sub-payload in Encrypted Secret
Key payload. Similar to EC Diffie-Hellman sub-payload, it is never
included in clear, but as an encrypted part of the ESK payload.
Cakulev & Sundaram Expires April 17, 2010 [Page 24]
Internet-Draft MIKEY-IBAKE October 2009
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Type ! KV ! Key data len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Next payload (8 bits): identifies the payload that is added after
this payload.
o Type (4 bits): indicates the type of the key included in the
payload.
+------+-------+
| Type | Value |
+------+-------+
| SK | 0 |
+------+-------+
Table 4: Secret Key Types
o KV (4 bits): indicates the type of key validity period specified.
This may be done by using an SPI (or MKI in the case of [RFC3711])
or by providing an interval in which the key is valid (e.g., in
the latter case, for SRTP this will be the index range where the
key is valid). KV values are the same as in Section 6.13 of
[RFC3830]
o Key data len (16 bits): the length of the Key data field (in
bytes).
o Key data (variable length): The SK data.
o KV data (variable length): This includes either the SPI or an
interval. If KV is NULL, this field is not included.
Cakulev & Sundaram Expires April 17, 2010 [Page 25]
Internet-Draft MIKEY-IBAKE October 2009
7. Security Considerations
This draft is based on the basic Identity Based Encryption protocol,
as specified in [RFC5091]), [RFC5408] and [RFC5409], and as such
inherits some properties of that protocol. For instance, by
concatenating the "date" with the identity (to derive the public
key), the need for any key revocation mechanisms is virtually
eliminated. Moreover, by allowing the participants to acquire
multiple private keys (e.g., for duration of contract) the
availability requirements on the KMS are also reduced without any
reduction in security.
Some additional security considerations are outlined below:
o Attacks on the cryptographic algorithms used in Identity Based
Encryption are outside the scope of this document. It is assumed
that any administrator will pay attention to the desired strengths
of the relevant cryptographic algorithms based on an up to date
understanding of the strength of these algorithms from published
literature as well as known attacks.
o It is assumed that the Key Management Services are secure, not
compromised, trusted, and will not engage in launching active
attacks independently or in a collaborative environment.
o However, any malicious insider could potentially launch passive
attacks (by decryption of one or more message exchanges offline).
While it is in the best interest of administrators to prevent such
issue, it is hard to eliminate this problem. Hence, it it assumed
that such problems will persist, and hence the protocols are
designed to protect participants from passive adversaries.
o Communication between participants and their respective Key
Management Servers is expected to be secure, and as such outside
the scope of this document. In any implementation of the
protocols described in this document, administrators of any KMS
have to ensure that communication with participants is secure and
not compromised.
o The basic IBAKE protocol from a cryptographic perspective is
secure based on the following considerations.
* In every step Identity Based Encryption (IBE) is used, with the
recipient's public key. This guarantees that only the intended
recipient of the message can decrypt the message.
* Next, the use of identities within the encrypted payload is
intended to eliminate some basic reflection attacks. For
Cakulev & Sundaram Expires April 17, 2010 [Page 26]
Internet-Draft MIKEY-IBAKE October 2009
instance, suppose we did not use identities as part of the
encrypted payload, in the first step of the IBAKE protocol
(i.e., I_message 1 of Figure 3 in Section 4.1).
+ Assume an adversary who has access to the conversation
between initiator and responder and can actively snoop into
packets and drop/modify them before routing them to the
destination.
+ For instance, assume that the IP source address and
destination address can be modified by the adversary.
+ After the first message is sent by the initiator (to the
responder), the adversary can take over and trap the packet.
+ Next the adversary can modify the IP source address to
include adversary's IP address, before routing it onto the
responder.
+ The responder will assume the request for an IBAKE session
came from the adversary, and will execute step 2 of the
IBAKE protocol (i.e., R_message 1 of Figure 3 in
Section 4.1) but encrypt it using the adversary's public
key.
+ The above message can be decrypted by the adversary (and
only by the adversary). In particular, since the second
message includes the challenge sent by the initiator to the
responder, the adversary will now learn the challenge sent
by the initiator.
+ Following this, the adversary can carry on a conversation
with the initiator "pretending" to be the responder.
+ This attack will be eliminated if identities are used as
part of the encrypted payload.
* In summary, at the end of the exchange both initiator and
responder can mutually authenticate each other and agree on a
session key.
* Recall that Identity Based Encryption guarantees that only the
recipient of the message can decrypt the message using the
private key. The caveat being, the KMS which generated the
private key of recipient of message can decrypt the message as
well. However, the KMS cannot learn the session key "xyP"
given "xP" and "yP" based on the Elliptic Curve Diffie-Hellman
problem. This property of resistance to passive key escrow
Cakulev & Sundaram Expires April 17, 2010 [Page 27]
Internet-Draft MIKEY-IBAKE October 2009
from the KMS, is not applicable to the basic IBE protocols
proposed in [RFC5091]), [RFC5408] and [RFC5409].
* Observe that the protocol works even if the initiator and
responder belong to two different Key Management Systems. In
particular, the parameters used for encryption to the responder
and parameters used for encryption to the initiator can be
completely different and independent of each other. Moreover,
the Elliptic Curve used to generate the session key "abP" can
be completely different. If such flexibility is desired, then
it would be advantageous to add optional extra data and/or to
the protocol to exchange the algebraic primitives used in
deriving the session key.
* In addition to mutual authentication, and resistance to passive
escrow, the Diffie-Hellman property of the session key exchange
guarantees perfect secrecy of keys. In others, accidental
leakage of one session key does not compromise of past or
future session keys between the same initiator and responder.
o The security of all additional security features rely on the
security of IBAKE. Moreover each feature has additional security
features. For instance:
* In the Forking feature, given that there are multiple potential
responders, it is important to observe that there is one
'common responder' identity (and corresponding public and
private keys) and each responder has a unique identity (and
corresponding keys). Observe that, in this framework if
responder 2 is the who responds to the invite from the
initiator then the protocol guarantees that responder 1 does
not learn the session key.
* In the Retargeting feature, the forwarding server does not
learn the private key of the intended responder since it is
encrypted using the retargeted responder's public key.
Additionally, the initiator will learn that the retargeted
responder answered the phone (and not the intended responder).
This will allow the initiator to decide whether or not to carry
on the conversation. Finally, the session key cannot be
discovered by intended responder since the random number chosen
by the retargeted responder is secret.
* In the Deferred Delivery feature, the initiator and the
responder's mailbox will mutually authenticate each other
thereby preventing server side "phishing" attacks and
conversely guarantees to the server (and eventually to the
responder) the identity of the initiator. Moreover, the key
Cakulev & Sundaram Expires April 17, 2010 [Page 28]
Internet-Draft MIKEY-IBAKE October 2009
used by initiator to encrypt the contents of the message is
completely independent from the session key derived between the
initiator and the server. Finally, the key used to encrypt the
message is encrypted using the responder's public key by the
initiator which allows the contents of the message to remain
unknown to the mailbox server.
Cakulev & Sundaram Expires April 17, 2010 [Page 29]
Internet-Draft MIKEY-IBAKE October 2009
8. IANA Considerations
This document defines several new values for the namespaces Data
Type, Next Payload, and Key Data Type defined in [RFC3830]. The
following IANA assignments were added to the MIKEY Payload registry
(in bracket is a reference to the table containing the registered
values):
o Data Type (see Table 1)
o Next Payload (see Table 2)
o Key Data Type (see Table 3)
Cakulev & Sundaram Expires April 17, 2010 [Page 30]
Internet-Draft MIKEY-IBAKE October 2009
9. References
9.1. Normative References
[I-D.ietf-msec-mikey-ecc]
Milne, A., "ECC Algorithms for MIKEY",
draft-ietf-msec-mikey-ecc-03 (work in progress),
June 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID
Information Type for the General Extension Payload in
Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006.
[RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography
Standard (IBCS) #1: Supersingular Curve Implementations of
the BF and BB1 Cryptosystems", RFC 5091, December 2007.
[RFC5408] Appenzeller, G., Martin, L., and M. Schertler, "Identity-
Based Encryption Architecture and Supporting Data
Structures", RFC 5408, January 2009.
[RFC5409] Martin, L. and M. Schertler, "Using the Boneh-Franklin and
Boneh-Boyen Identity-Based Encryption Algorithms with the
Cryptographic Message Syntax (CMS)", RFC 5409,
January 2009.
[SEC1] Standards for Efficient Cryptography Group, "Elliptic
Curve Cryptography", September 2000.
9.2. Informative References
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for
Multimedia Internet KEYing (MIKEY)", RFC 4650,
Cakulev & Sundaram Expires April 17, 2010 [Page 31]
Internet-Draft MIKEY-IBAKE October 2009
September 2006.
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-
RSA-R: An Additional Mode of Key Distribution in
Multimedia Internet KEYing (MIKEY)", RFC 4738,
November 2006.
Cakulev & Sundaram Expires April 17, 2010 [Page 32]
Internet-Draft MIKEY-IBAKE October 2009
Authors' Addresses
Violeta Cakulev
Alcatel Lucent
600 Mountain Ave.
3D-517
Murray Hill, NJ 07974
US
Phone: +1 908 582 3207
Email: cakulev@alcatel-lucent.com
Ganapathy Sundaram
Alcatel Lucent
600 Mountain Ave.
3D-517
Murray Hill, NJ 07974
US
Phone: +1 908 582 3209
Email: ganeshs@alcatel-lucent.com
Cakulev & Sundaram Expires April 17, 2010 [Page 33]