TOC 
Network Working GroupV. Cakulev
Internet-DraftG. Sundaram
Intended status: Standards TrackAlcatel Lucent
Expires: April 17, 2010October 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.

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.

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
2.  Requirements notation
    2.1.  Definitions and Notation
    2.2.  Abbreviations
3.  Use Case Scenarios
    3.1.  Forking
    3.2.  Retargeting
    3.3.  Deferred Delivery
4.  MIKEY-IBAKE Protocol Description
    4.1.  Overview
    4.2.  Message Exchanges and Processing
        4.2.1.  REQUEST_KEY_INIT/REQUEST_KEY_RESP Message Exchange
        4.2.2.  I_MESSAGE/R_MESSAGE Message Exchanges
5.  Key Derivation
    5.1.  Generating Keys from the Session Key
    5.2.  Generating Keys for MIKEY Messages
    5.3.  CSB Update
    5.4.  Generating MAC and Verification Message
6.  Payload Encoding
    6.1.  Common Header Payload (HDR)
        6.1.1.  IBAKE Payload
        6.1.2.  Encrypted Secret Key (ESK) Payload
        6.1.3.  Key Data Sub-Payload
        6.1.4.  EC Diffie-Hellman Sub-Payload
        6.1.5.  Secret Key Sub-Payload
7.  Security Considerations
8.  IANA Considerations
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Authors' Addresses




 TOC 

1.  Introduction

Multimedia Internet Keying (MIKEY) [RFC3830] (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.) 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] (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.).

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 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.



 TOC 

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

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] (Boyen, X. and L. Martin, “Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems,” December 2007.), [RFC5408] (Appenzeller, G., Martin, L., and M. Schertler, “Identity-Based Encryption Architecture and Supporting Data Structures,” January 2009.) and [RFC5409] (Martin, L. and M. Schertler, “Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS),” January 2009.).

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



 TOC 

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
K_PUB:
Public Key
MAC:
Message Authentication Code
MIKEY:
Multimedia Internet KEYing
PKI:
Public Key Infrastructure
R:
Responder
SK:
Secret Key


 TOC 

3.  Use Case Scenarios

This section describes some of the use case scenarios supported by MIKEY-IBAKE.



 TOC 

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 



 TOC 

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 (Retargeting) below.



      +---+             +-------+             +---+             +---+
      | 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.



 TOC 

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.



 TOC 

4.  MIKEY-IBAKE Protocol Description



 TOC 

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 (Example Message Exchange), 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 (Example Message Exchange) 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 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] (Boyen, X. and L. Martin, “Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems,” December 2007.) and [RFC5408] (Appenzeller, G., Martin, L., and M. Schertler, “Identity-Based Encryption Architecture and Supporting Data Structures,” January 2009.). 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 (Generating Keys from the Session Key).

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 (Use Case Scenarios), some alternative use cases are discussed.

MIKEY-IBAKE is based on [RFC3830] (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.), 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] (Boyen, X. and L. Martin, “Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems,” December 2007.) and [RFC5408] (Appenzeller, G., Martin, L., and M. Schertler, “Identity-Based Encryption Architecture and Supporting Data Structures,” January 2009.), while the keys exchanged in KEY_REQUES_INIT/KEY_REQUEST_RESPONSE are encrypted as specified in [RFC3830] (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.). In all exchanges encryption is only applied to the keys and key components and not to the entire messages.



 TOC 

4.2.  Message Exchanges and Processing



 TOC 

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] (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.). 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



 TOC 

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] (Carrara, E., Lehtovirta, V., and K. Norrman, “The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY),” June 2006.).

IDi/r contains the identity of the user. Since the user may have multiple identities, multiple IDi/r fields may appear in the message.

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.



 TOC 

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] (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.) Section 4.1.4 for key derivation specification).



 TOC 

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.



 TOC 

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.



 TOC 

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.

                   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.



 TOC 

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.



 TOC 

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



 TOC 

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 (Generating Keys for MIKEY Messages).



 TOC 

4.2.2.2.  Processing of the I_MESSAGE_1 Message

The parsing of I_MESSAGE_1 message SHALL be done as in [RFC3830] (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.). 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.



 TOC 

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.

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 (Generating Keys for MIKEY Messages).



 TOC 

4.2.2.4.  Processing of the R_MESSAGE_1 Message

The parsing of R_MESSAGE_1 message SHALL be done as in [RFC3830] (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.). 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.



 TOC 

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-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 (Generating Keys for MIKEY Messages).



 TOC 

4.2.2.6.  Processing of the I_MESSAGE_2 Message

The parsing of I_MESSAGE_2 message SHALL be done as in [RFC3830] (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.). 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.



 TOC 

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:

                 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 (Generating Keys for MIKEY Messages).



 TOC 

4.2.2.8.  Processing of the R_MESSAGE_2 Message

The parsing of R_MESSAGE_2 message SHALL be done as in [RFC3830] (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.). 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.



 TOC 

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] (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.). As crypto sessions are not handled in this exchange, further keying material (i.e TEKs) for this message exchanges SHALL NOT be derived.



 TOC 

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] (Standards for Efficient Cryptography Group, “Elliptic Curve Cryptography,” September 2000.). This octet string is used as TGK. Finally, the keys (e.g., TEK) are generated from TGK as specified in [RFC3830] (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.).



 TOC 

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] (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.).

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] (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.).



 TOC 

5.3.  CSB Update

Similar to [RFC3830] (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.), 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.

   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 (Generating Keys for MIKEY Messages). 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.



 TOC 

5.4.  Generating MAC and Verification Message

Authentication tag in all MIKEY-IBAKE messages is generated as described in [RFC3830] (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.). 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.



 TOC 

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] (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.). For a detailed description of the MIKEY payloads, see [RFC3830] (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.).



 TOC 

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.



Data TypeValueComment
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) 



Next PayloadValueSection
IBAKE TBD8 Section 6.1.1 (IBAKE Payload)
ESK TBD9 Section 6.1.2 (Encrypted Secret Key (ESK) Payload)
SK TBD10 Section 6.1.5 (Secret Key Sub-Payload)

 Table 2: Next Payload (Additions) 



 TOC 

6.1.1.  IBAKE Payload

The IBAKE payload contains IBE encrypted (see [RFC5091] (Boyen, X. and L. Martin, “Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems,” December 2007.)) and [RFC5408] (Appenzeller, G., Martin, L., and M. Schertler, “Identity-Based Encryption Architecture and Supporting Data Structures,” January 2009.)) for details about IBE encryption) Initiator and Responder's Identities and EC Diffie-Hellman sub-payloads (see Section 6.1.4 (EC Diffie-Hellman Sub-Payload) 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                              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



 TOC 

6.1.2.  Encrypted Secret Key (ESK) Payload

The Encrypted Secret Key payload contains IBE encrypted (see [RFC5091] (Boyen, X. and L. Martin, “Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems,” December 2007.)) and [RFC5408] (Appenzeller, G., Martin, L., and M. Schertler, “Identity-Based Encryption Architecture and Supporting Data Structures,” January 2009.)) for details about IBE encryption) Secret Key sub-payload and its associated identity (see Section 6.1.5 (Secret Key Sub-Payload) 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                              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



 TOC 

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.



TypeValueComments
K_PR TBD11 Private Key

 Table 3: Key Data Type (Additions) 



 TOC 

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] (Milne, A., “ECC Algorithms for MIKEY,” June 2007.). 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)                                            ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



 TOC 

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.

                        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)                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



TypeValue
SK 0

 Table 4: Secret Key Types 



 TOC 

7.  Security Considerations

This draft is based on the basic Identity Based Encryption protocol, as specified in [RFC5091] (Boyen, X. and L. Martin, “Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems,” December 2007.)), [RFC5408] (Appenzeller, G., Martin, L., and M. Schertler, “Identity-Based Encryption Architecture and Supporting Data Structures,” January 2009.) and [RFC5409] (Martin, L. and M. Schertler, “Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS),” January 2009.), 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:



 TOC 

8.  IANA Considerations

This document defines several new values for the namespaces Data Type, Next Payload, and Key Data Type defined in [RFC3830] (Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” August 2004.). The following IANA assignments were added to the MIKEY Payload registry (in bracket is a reference to the table containing the registered values):



 TOC 

9.  References



 TOC 

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 (TXT).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, “MIKEY: Multimedia Internet KEYing,” RFC 3830, August 2004 (TXT).
[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 (TXT).
[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 (TXT).
[RFC5408] Appenzeller, G., Martin, L., and M. Schertler, “Identity-Based Encryption Architecture and Supporting Data Structures,” RFC 5408, January 2009 (TXT).
[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 (TXT).
[SEC1] Standards for Efficient Cryptography Group, “Elliptic Curve Cryptography,” September 2000.


 TOC 

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 (TXT).
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, “The Kerberos Network Authentication Service (V5),” RFC 4120, July 2005 (TXT).
[RFC4650] Euchner, M., “HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY),” RFC 4650, September 2006 (TXT).
[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 (TXT).


 TOC 

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