MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)
draft-mattsson-mikey-ticket-05
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
(Tim Polk; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss, No Objection, Discuss) No Objection
(Dan Romascanu; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
draft-mattsson-mikey-ticket-03.txt In the Abstract: OLD: ...required by many existing applications, e.g. so called forking where the... NEW: ...used by many existing applications (e.g., forking) where the... Introduction: You may want to split the following sentence into two: "A high level outline of MIKEY-TICKET as defined herein is that the Initiator requests keys and a ticket from the KMS and sends the ticket containing a reference to the keys, or the enveloped keys, to the Responder." Section 3 describes SIP forking and explains some of its associated problems. Section 12.4 contains the same description. This description could be expanded and clarified a bit because there are really several problems here. One scenario is when an INVITE sent to a user reaches that user on multiple devices, all of which are owned by that user. A different problem appears when mixing forking and retargeting. The INVITE will be delivered to different users. Section 4.2 of RFC 5479 describes these two scenarios. Of course, the security implications are different depending on the scenario. A third scenario is the one covered in the current text with the somebody@company.example example. I would change that URI to something like IT-support@example.com instead so that it is clearer what type of service we are talking about. Note that I am OK with the conclusion that the respondents should not share the same private key. I am just suggesting to describe the issues related to SIP forking properly. Also, it may be good to mention up front in Section 3 that in addition to being able to meet the requirement just described, the mechanism specified in this document also supports group key management. Section 7 says: "If SDP or RTSP is not used, it has to be defined how MIKEY is transported over the transport protocol in question (e.g. HTTP)." What does this mean? Who has to define that?
(Peter Saint-Andre; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) (was Discuss) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Sean Turner; former steering group member) (was Discuss) No Objection
1) Sec 2.2 & 3: According to RFC 5280: CA should be Certification Authority not Certificate Authority 2) Sec 4.1: r/The Ticket Request exchange is optional/The Ticket Request exchange is OPTIONAL 3) Sec 4.1: r/The Ticket Resolve exchange is optional/The Ticket Resolve exchange is OPTIONAL 4) Sec 4.2.3.1: Does the trust anchor also get distributed in a cert payload? 5) Sec 5.2: What happens if a KEYMAC payload is included when the Ticket Policy flag says it shouldn't be? 6) Sec 6.3: I'm not sure it's appropriate to have a requirement in a NOTE. Can this just be made a new paragraph? 7) Sec 7: r/If SDP or RTSP is not used, it has to be defined how MIKEY is transported over the transport protocol in question (e.g. HTTP)./If SDP or RTSP is not used, the transport protocol (e.g. HTTP) needs to be defined.
(Stewart Bryant; former steering group member) No Objection