MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)
draft-cakulev-mikey-ibake-06

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.

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

[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?

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

[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?

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

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

[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?).

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

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

[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?

[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?

[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

[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?

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?