Skip to main content

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

Yes

(Tim Polk)

No Objection

(Adrian Farrel)
(Alexey Melnikov)
(Dan Romascanu)
(Gonzalo Camarillo)
(Peter Saint-Andre)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)

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

Tim Polk Former IESG member
Yes
Yes ()

                            
Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2010-10-18)

                            
Alexey Melnikov Former IESG member
(was Discuss) No Objection
No Objection ()

                            
Dan Romascanu Former IESG member
No Objection
No Objection ()

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection ()

                            
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection (2010-09-09)
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.
Peter Saint-Andre Former IESG member
No Objection
No Objection ()

                            
Robert Sparks Former IESG member
No Objection
No Objection (2010-09-23)
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?
Ron Bonica Former IESG member
No Objection
No Objection ()

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection ()

                            
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2010-09-08)
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 
Stewart Bryant Former IESG member
No Objection
No Objection ()