Skip to main content

MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)
draft-ietf-msec-mikey-rsa-r-07

Yes

(Russ Housley)

No Objection

(Bill Fenner)
(Brian Carpenter)
(Dan Romascanu)
(David Kessens)
(Jari Arkko)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Ross Callon)
(Sam Hartman)
(Ted Hardie)

Note: This ballot was opened for revision 07 and is now closed.

Russ Housley Former IESG member
Yes
Yes () Unknown

                            
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
Brian Carpenter Former IESG member
No Objection
No Objection () Unknown

                            
Cullen Jennings Former IESG member
(was Discuss) No Objection
No Objection (2006-06-08) Unknown
I did not fully understand how this worked in group mode - I believe it works. It just the description could use a bit more overview that made it easier to understand. 

The document would be better with an example that could be used as test vector.
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection (2006-06-06) Unknown
Section 1.1., paragraph 0:

>    The MIKEY protocol [RFC3830] has three different methods for key
>    transport or exchange: a pre-shared key mode (PSK), a public-key
>    (RSA) mode, and an optional Diffie-Hellman exchange (DHE) mode.  In
>    addition, there is also an optional DH-HMAC mode [I-D.ietf-msec-
>    mikey-dhhmac], bringing the total number of modes to four.  The
>    primary motivation for the MIKEY protocol design is low-latency
>    requirements of real-time communication, and thus all the exchanges
>    finish in one-half to 1 round-trip; note that this offers no room for
>    security parameter negotiation of the key management protocol itself.
>    In this document, we note that the MIKEY modes defined in RFC3830
>    [RFC3830] and [I-D.ietf-msec-mikey-dhhmac] are insufficient to
>    address some deployment scenarious and common use cases, and propose
>    a new mode called MIKEY-RSA in Reverse mode, or simply as
>    MIKEY-RSA-R.  This document updates RFC 3830 with the addition of
>    this new mode to that specification.

        NIT: s/scenarious/scenarios/
 

Section 3.7.3., paragraph 2:

>          Type      | Value | Comment
>          -------------------------------------------------------
>          Vendor ID |     0 | Vendor specific byte string
>          SDP IDs   |     1 | List of SDP key mgmt IDs
>                    |       |   (allocated for use in [KMASDP])
>          CSB-ID    |     3 | Responder's modified CSB-ID (group mode)

        Missing Reference: [KMASDP]
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Sam Hartman Former IESG member
No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection () Unknown