Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2015-10-14
06 (System) Notify list changed from violeta.cakulev@alcatel-lucent.com, ganesh.sundaram@alcatel-lucent.com, draft-cakulev-mikey-ibake@ietf.org to (None)
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Sean Turner
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Adrian Farrel
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2011-06-29
06 Cindy Morgan State changed to RFC Published from RFC Ed Queue.
2011-06-28
06 (System) RFC published
2011-04-14
06 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2011-04-14
06 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2011-04-14
06 (System) IANA Action state changed to In Progress from Waiting on Authors
2011-04-05
06 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-03-29
06 (System) IANA Action state changed to In Progress
2011-03-28
06 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2011-03-28
06 Amy Vezza IESG state changed to Approved-announcement sent
2011-03-28
06 Amy Vezza IESG has approved the document
2011-03-28
06 Amy Vezza Closed "Approve" ballot
2011-03-28
06 Amy Vezza Approval announcement text regenerated
2011-03-28
06 Tim Polk Ballot writeup text changed
2011-03-28
06 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss
2011-03-10
06 (System) New version available: draft-cakulev-mikey-ibake-06.txt
2011-03-08
06 Tim Polk State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2010-12-11
06 Russ Housley [Ballot discuss]
The draft-cakulev-ibake-01 document needs to be a normative reference.
2010-12-11
06 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss
2010-12-09
05 (System) New version available: draft-cakulev-mikey-ibake-05.txt
2010-12-06
06 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2010-11-24
06 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss
2010-11-23
04 (System) New version available: draft-cakulev-mikey-ibake-04.txt
2010-11-22
06 Amanda Baber
IANA understands that, upon approval of this document, IANA is to
complete five IANA Actions.

First, in the Data Type subregistry of the Multimedia Internet …
IANA understands that, upon approval of this document, IANA is to
complete five IANA Actions.

First, in the Data Type subregistry of the Multimedia Internet KEYing
(Mikey) Payload Name Spaces registry located at:

http://www.iana.org/assignments/mikey-payloads

the following registrations are to be added:

Value Data Type Reference

TBD REQUEST_KEY_PSK [RFC-to-be]
TBD REQUEST_KEY_PKE [RFC-to-be]
TBD REQUEST_KEY_RESP [RFC-to-be]
TBD I_MESSAGE_1 [RFC-to-be]
TBD R_MESSAGE_1 [RFC-to-be]
TBD I_MESSAGE_2 [RFC-to-be]
TBD R_MESSAGE_2 [RFC-to-be] |

Second, in the Next Payload subregistry of the Multimedia Internet
KEYing (Mikey) Payload Name Spaces registry located at:

http://www.iana.org/assignments/mikey-payloads

the following registrations are to be added:

Value Next Payload Section in Document Reference

TBD IBAKE Section 6.1.1 [RFC-to-be]
TBD ESK Section 6.1.2 [RFC-to-be]
TBD SK Section 6.1.5 [RFC-to-be]
TBD ECCPT Section 6.1.4 [RFC-to-be]

Third, in the Key Data Type Subregistry of the Key Data payload name
spaces registry located in:

http://www.iana.org/assignments/mikey-payloads

a single, new registration is to be made:

Value Type Reference

TBD K_PR [RFC-to-be]

Fourth, in the Multimedia Internet KEYing (Mikey) Payload Name Spaces
registry located at:

http://www.iana.org/assignments/mikey-payloads

a new registry is to be created. The ECC Curve registry will consist of
values from 0 to 255 inclusive. New values in the range 1-239 have a
registration procedure of Specification Required. Values in the range
240-254 are for Private Use. Values 0 and 255 are Reserved. The initial
registrations in this new registry are:

Value ECC curve
------- ------------------------------------
0 Reserved
1 ECPRGF192Random / P-192 / secp192r1
2 EC2NGF163Random / B-163 / sect163r2
3 EC2NGF163Koblitz / K-163 / sect163k1
4 EC2NGF163Random2 / none / sect163r1
5 ECPRGF224Random / P-224 / secp224r1
6 EC2NGF233Random / B-233 / sect233r1
7 EC2NGF233Koblitz / K-233 / sect233k1
8 ECPRGF256Random / P-256 / secp256r1
9 EC2NGF283Random / B-283 / sect283r1
10 EC2NGF283Koblitz / K-283 / sect283k1
11 ECPRGF384Random / P-384 / secp384r1
12 EC2NGF409Random / B-409 / sect409r1
13 EC2NGF409Koblitz / K-409 / sect409k1
14 ECPRGF521Random / P-521 / secp521r1
15 EC2NGF571Random / B-571 / sect571r1
16 EC2NGF571Koblitz / K-571 / sect571k1
17-239 Unassigned
240-254 Private Use
255 Reserved

All of these initial registrations have a reference of [RFC-to-be].

Fifth, in the Multimedia Internet KEYing (Mikey) Payload Name Spaces
registry located at:

http://www.iana.org/assignments/mikey-payloads

a new registry is to be created. The SK sub-payload registry defines a
Type field with values from 0 to 15 inclusive. Values in the range 2-15
use a registration procedure of Specification Required. The value 0 is
reserved. The initial contents of the new registry are as follows:

Value Type
------- ---------------
0 Reserved
1 Secret Key (SK)
2-15 Unassigned

All of these initial registrations have a reference of [RFC-to-be].

IANA understands that these five actions are the only ones required upon
approval of this document.
2010-11-08
06 Amy Vezza Last call sent
2010-11-08
06 Amy Vezza State changed to In Last Call from Last Call Requested by Amy Vezza
2010-11-08
06 Tim Polk Last Call was requested by Tim Polk
2010-11-08
06 Tim Polk State changed to Last Call Requested from IESG Evaluation::AD Followup by Tim Polk
2010-10-19
06 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss by Alexey Melnikov
2010-10-18
06 Adrian Farrel
[Ballot discuss]
Discuss updated after new revision.

Thanks to the authors for the work to address all the issues in their remit.

The remaining two …
[Ballot discuss]
Discuss updated after new revision.

Thanks to the authors for the work to address all the issues in their remit.

The remaining two issues need resolution by the responsible AD.

---

I don't see the IPR disclosure (1359) referenced during the IETF last
call. Does this require a second IETF last call?

---

Can someone please clarify for me why this is an Informational
specification? It has the look and feel of a standards track
specification since it defines the behavior of compliant
implementations, uses 2119 language, defines protocol elements, and has
a non-null IANA section.

There *are* possible good reasons for this; I would just like to know
which one applies, and to discuss how this should be recorded in the
document.
2010-10-18
06 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss by Sean Turner
2010-10-18
06 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-10-18
03 (System) New version available: draft-cakulev-mikey-ibake-03.txt
2010-09-25
06 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Glen Zorn.
2010-09-23
06 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation::External Party by Cindy Morgan
2010-09-23
06 Robert Sparks
[Ballot comment]
Support Jari's discuss and Adrian's discuss on whether this should be an Informational document.

Should this (and its related documents) be going through …
[Ballot comment]
Support Jari's discuss and Adrian's discuss on whether this should be an Informational document.

Should this (and its related documents) be going through a working group instead?
2010-09-23
06 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2010-09-23
06 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo
2010-09-09
06 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded by Peter Saint-Andre
2010-09-09
06 Jari Arkko
[Ballot discuss]
The document explains that the inclusion of the date in the identity virtually eliminates the need for key revocation. The document also explains …
[Ballot discuss]
The document explains that the inclusion of the date in the identity virtually eliminates the need for key revocation. The document also explains that in typical usage, there is a need to contact the key management server only occasionally, such as once a month. I may be dense or missing something, but I have a very difficult time understanding how key revocation would work in this context. If the key management server gives you daily keys for the next month, your peer gets his daily keys for the month, and you two communicate directly, then these communications will succeed no matter what someone else may have decided about key revocation. This is a similar situation to any secret or public key system without online key revocation checks. Perhaps the document should have said that it cannot support key revocation at all, unless a real-time always-available key management server can be assumed? (And even so, such check roundtrip should be specified.)

The document also leaves something to desire in terms of explaining the overall architecture and assumptions. Some of the base IBC documents talk about mandatory TLS to the key management server. I assume that this is not required by the architecture specified here, and instead you assume MIKEY shared secrets between the hosts and the key management server? Assumptions like this should be clearly described at the beginning of the document. Also, the IBC public parameters concept is mentioned for the first time on page 10, and it would have been nice to know early on that the key management server delivers those. It would also be useful to know when such parameters can change (or can they?).

>  For the description of IDR payload as well
>  as for the definition of additional PRF functions and encryption
>  algorithms not defined in [RFC3830], see [I-D.mattsson-mikey-ticket].

That needs to be a normative reference.

Section 2.2 talks about IDr/i and Section 4.2.1 about IDRr/i. Are these the same or different?

> Attacks on the cryptographic algorithms used in Identity Based
> Encryption are outside the scope of this document.

Some pointer(s) to the security considerations of the algorithms would still seem useful, and have traditionally appeared in RFCs of this sort.

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

According to http://www.ecrypt.eu.org/documents/D.SPA.13.pdf Section 12.2.1 key length selection in these systems is still pretty unexplored for the cryptographic community let alone a sysadmin; it would be useful for this document to provide some guidance.
2010-09-09
06 Tim Polk Telechat date was changed to 2010-09-23 from 2010-09-09 by Tim Polk
2010-09-09
06 Alexey Melnikov
[Ballot discuss]
I haven't performed a very thorough review of this document, but I didn't find answers to the following questions:

I don't see where …
[Ballot discuss]
I haven't performed a very thorough review of this document, but I didn't find answers to the following questions:

I don't see where the format of the timestamp (T) field is defined.

Does the protocol require time synchronization between the Initiator and the Responder?
2010-09-09
06 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov
2010-09-09
06 Jari Arkko
[Ballot comment]
The document needs to define and expand terms that it uses, for instance there are many IMS related terms that are used without …
[Ballot comment]
The document needs to define and expand terms that it uses, for instance there are many IMS related terms that are used without introduction (IMS, CSCF).

> a huge burden

I would just say "a burden", for better style in these types of documents

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

I am the last person on this planet to argue in favor of legal interception, but I did find it odd that the document talks about public voice communication systems such as IMS that have government requirements for legal interception. And at the same time argues that somehow the specified solution is less vulnerable to escrow/interception. Either the specified system is capable of such interception as well, or it isn't. If the authors want to make a claim that there is no way to provide legal interception in their system then the argument seems fair, otherwise... I would just delete it.
2010-09-09
06 Jari Arkko
[Ballot discuss]
The document explains that the inclusion of the date in the identity virtually eliminates the need for key revocation. The document also explains …
[Ballot discuss]
The document explains that the inclusion of the date in the identity virtually eliminates the need for key revocation. The document also explains that in typical usage, there is a need to contact the key management server only occasionally, such as once a month. I may be dense or missing something, but I have a very difficult time understanding how key revocation would work in this context. If the key management server gives you daily keys for the next month, your peer gets his daily keys for the month, and you two communicate directly, then these communications will succeed no matter what someone else may have decided about key revocation. This is a similar situation to any secret or public key system without online key revocation checks. Perhaps the document should have said that it cannot support key revocation at all, unless a real-time always-available key management server can be assumed? (And even so, such check roundtrip should be specified.)

The document also leaves something to desire in terms of explaining the overall architecture and assumptions. Some of the base IBC documents talk about mandatory TLS to the key management server. I assume that this is not required by the architecture specified here, and instead you assume MIKEY shared secrets between the hosts and the key management server? Assumptions like this should be clearly described at the beginning of the document. Also, the IBC public parameters concept is mentioned for the first time on page 10, and it would have been nice to know early on that the key management server delivers those. It would also be useful to know when such parameters can change (or can they?).

>  For the description of IDR payload as well
>  as for the definition of additional PRF functions and encryption
>  algorithms not defined in [RFC3830], see [I-D.mattsson-mikey-ticket].

That needs to be a normative reference.
2010-09-09
06 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2010-09-09
06 Jari Arkko
[Ballot discuss]
The document explains that the inclusion of the date in the identity virtually eliminates the need for key revocation. The document also explains …
[Ballot discuss]
The document explains that the inclusion of the date in the identity virtually eliminates the need for key revocation. The document also explains that in typical usage, there is a need to contact the key management server only occasionally, such as once a month. I may be dense or missing something, but I have a very difficult time understanding how key revocation would work in this context. If the key management server gives you daily keys for the next month, your peer gets his daily keys for the month, and you two communicate directly, then these communications will succeed no matter what someone else may have decided about key revocation. This is a similar situation to any secret or public key system without online key revocation checks. Perhaps the document should have said that it cannot support key revocation at all, unless a real-time always-available key management server can be assumed? (And even so, such check roundtrip should be specified.)

The document also leaves something to desire in terms of explaining the overall architecture and assumptions. Some of the base IBC documents talk about mandatory TLS to the key management server. I assume that this is not required by the architecture specified here, and instead you assume MIKEY shared secrets between the hosts and the key management server? Assumptions like this should be clearly described at the beginning of the document. Also, the IBC public parameters concept is mentioned for the first time on page 10, and it would have been nice to know early on that the key management server delivers those. It would also be useful to know when such parameters can change (or can they?).
2010-09-09
06 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2010-09-09
06 Adrian Farrel
[Ballot comment]
Agree with Russ that [I-D.cakulev-ibake] should be a Normative
reference.

---

Section 6.1.4

I would like to caution against both this …
[Ballot comment]
Agree with Russ that [I-D.cakulev-ibake] should be a Normative
reference.

---

Section 6.1.4

I would like to caution against both this document and
draft-ietf-msec-mikey-ecc defining the same format. It is best to have
just one definition, and let the other document make a normative
reference.
2010-09-09
06 Adrian Farrel
[Ballot discuss]
I have a few small issues that I would like to Discuss before consenting to the publiscaiton of this document.

idnits (http://tools.ietf.org/tools/idnits/ …
[Ballot discuss]
I have a few small issues that I would like to Discuss before consenting to the publiscaiton of this document.

idnits (http://tools.ietf.org/tools/idnits/) is a useful tool that
helps you catch issues that need to be fixed before the document can
proceed.

It gives the following pointers...

    The KEMAC payload SHOULD be used only when the user needs to use
    specific keys.  Otherwise, this payload SHALL not be used.

s/SHALL not/SHALL NOT/

--

  -- The document has a disclaimer for pre-RFC5378 work, but was first
    submitted on or after 10 November 2008.  Does it really need the
    disclaimer?

--

  == Unused Reference: 'RFC4120' is defined on line 1298, but no
    explicit reference was found in the text

---

I don't see the IPR disclosure (1359) referenced during the IETF last
call.

---

Can someone please clarify for me why this is an Informational
specification? It has the look and feel of a standards track
specification since it defines the behavior of compliant
implementations, uses 2119 language, defines protocol elements, and has
a non-null IANA section.

There *are* possible good reasons for this; I would just like to know
which one applies, and to discuss how this should be recorded in the
document.

---

I am worried about the reference to draft-ietf-msec-mikey-ecc.
Taht document expired in June 2007 and it would appear that the WG
has given up on it.

---

The way that Section 6 uses draft-mattsson-mikey-ticket makes it
look like a Normative reference to me.
2010-09-09
06 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded by Adrian Farrel
2010-09-08
06 Sean Turner
[Ballot discuss]
1) In Sec 6.1, the data type values (from Table 2), I think, are already assigned by IANA (http://www.iana.org/assignments/mikey-payloads).  I think …
[Ballot discuss]
1) In Sec 6.1, the data type values (from Table 2), I think, are already assigned by IANA (http://www.iana.org/assignments/mikey-payloads).  I think they #s need to start at 19 and go up.

2) In Sec 6.1, the next payload values are taken from unassigned #, but I'm curious why the #s didn't come from 27 and higher?  Was there  a reason mattsson-mikey-ticket-05 didn't come from 13-19?
2010-09-08
06 Russ Housley [Ballot discuss]
The draft-cakulev-ibake-01 document needs to be a normative reference.
2010-09-08
06 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2010-09-08
06 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2010-09-08
06 Sean Turner
[Ballot discuss]
1) In Sec 6.1, the data type values (from Table), I think, are already assigned by IANA (http://www.iana.org/assignments/mikey-payloads).  I think they …
[Ballot discuss]
1) In Sec 6.1, the data type values (from Table), I think, are already assigned by IANA (http://www.iana.org/assignments/mikey-payloads).  I think they #s need to start at 19 and go up.

2) In Sec 6.1, the next payload values are taken from unassigned #, but I'm curious why the #s didn't come from 27 and higher?  Was there  a reason mattsson-mikey-ticket-05 didn't come from 13-19?
2010-09-08
06 Sean Turner
[Ballot comment]
1) Sec 4.2.1.1: r/Otherwise, this payload SHALL not be used./Otherwise, this payload SHALL NOT be used.  ?

2) Sec 4.2.2.2: r/ If
  …
[Ballot comment]
1) Sec 4.2.1.1: r/Otherwise, this payload SHALL not be used./Otherwise, this payload SHALL NOT be used.  ?

2) Sec 4.2.2.2: r/ If
  the received message is correctly parsed, the Responder shall use / If
  the received message is correctly parsed, the Responder SHALL use
2010-09-08
06 Sean Turner
[Ballot discuss]
1) In Sec 6.1, the data type values, I think, are already assigned by IANA (http://www.iana.org/assignments/mikey-payloads).  I think they #s need …
[Ballot discuss]
1) In Sec 6.1, the data type values, I think, are already assigned by IANA (http://www.iana.org/assignments/mikey-payloads).  I think they #s need to start at 19 and go up.

2) In Sec 6.1, the next payload values are taken from unassigned #, but I'm curious why the #s didn't come from 27 and higher?
2010-09-08
06 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded by Sean Turner
2010-09-08
06 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant
2010-09-08
06 Tim Polk [Ballot Position Update] New position, Yes, has been recorded for Tim Polk
2010-09-08
06 Tim Polk Ballot has been issued by Tim Polk
2010-09-08
06 Tim Polk Created "Approve" ballot
2010-08-23
06 Tim Polk State Changes to IESG Evaluation::External Party from IESG Evaluation by Tim Polk
2010-08-23
06 Tim Polk Telechat date was changed to 2010-09-09 from 2010-08-26 by Tim Polk
2010-08-23
06 Tim Polk [Note]: 'Requested cryptographic review by CFRG - deadline 9/3/2010' added by Tim Polk
2010-08-17
06 Tim Polk Placed on agenda for telechat - 2010-08-26 by Tim Polk
2010-08-17
06 Tim Polk State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Tim Polk
2010-08-11
02 (System) New version available: draft-cakulev-mikey-ibake-02.txt
2010-07-26
06 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2010-07-22
06 Amanda Baber
IANA questions/comments:

Please see questions below.

Upon approval of this document, IANA will make the following
assignments in the "mikey-payloads" registry located at
http://www.iana.org/assignments/mikey-payloads:

ACTION …
IANA questions/comments:

Please see questions below.

Upon approval of this document, IANA will make the following
assignments in the "mikey-payloads" registry located at
http://www.iana.org/assignments/mikey-payloads:

ACTION 1:

In the sub-registry named "Common Header payload name spaces":

Value Data Type Reference
------- ------------------ ---------
11 REQUEST_KEY_PSK [RFC-cakulev-mikey-ibake-01]
12 REQUEST_KEY_PKE [RFC-cakulev-mikey-ibake-01]
13 REQUEST_KEY_RESP [RFC-cakulev-mikey-ibake-01]
14 I_MESSAGE_1 [RFC-cakulev-mikey-ibake-01]
15 R_MESSAGE_1 [RFC-cakulev-mikey-ibake-01]
16 I_MESSAGE_2 [RFC-cakulev-mikey-ibake-01]
17 R_MESSAGE_2 [RFC-cakulev-mikey-ibake-01]
18-240 Unassigned


ACTION 2:

In the sub-registry named "Next Payload":

Value Next Payload Section in Document Reference
------- ------------ ------------------- ---------
13 IBAKE 6.1.1 [RFC-cakulev-mikey-ibake-01]
14 ESK 6.1.2 [RFC-cakulev-mikey-ibake-01]
15 SK 6.1.5 [RFC-cakulev-mikey-ibake-01]
16-19 Unassigned

QUESTION: Section 6.1.4 mentions "payload identifier" 22. Should this
value be registered?


ACTION 3:

In the sub-registry named "Key Data Type":

Value Type Reference
------- -------------------- ---------
4 K_PR [RFC-cakulev-mikey-ibake-01]
5-16 Unassigned

QUESTION: Should a new sub-registry be created for Table 4?
2010-07-16
(System) Posted related IPR disclosure: Alcatel Lucent's Statement about IPR related to draft-cakulev-mikey-ibake-01
2010-06-29
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Glen Zorn
2010-06-29
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Glen Zorn
2010-06-28
06 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2010-06-25
06 Tim Polk Last Call was requested by Tim Polk
2010-06-25
06 Tim Polk State Changes to Last Call Requested from Publication Requested::External Party by Tim Polk
2010-06-25
06 (System) Ballot writeup text was added
2010-06-25
06 (System) Last call text was added
2010-06-25
06 (System) Ballot approval text was added
2010-05-26
06 Tim Polk Draft Added by Tim Polk in state Publication Requested
2010-05-26
06 Tim Polk [Note]: 'Requested cryptographic review by June 11' added by Tim Polk
2010-04-07
01 (System) New version available: draft-cakulev-mikey-ibake-01.txt
2009-10-14
00 (System) New version available: draft-cakulev-mikey-ibake-00.txt