MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)
Note: This ballot was opened for revision 05 and is now closed.
(Tim Polk) Yes
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
Comment (2010-05-06 for -** No value found for 'p.get_dochistory.rev' **)
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 firstname.lastname@example.org example. I would change that URI to something like ITemail@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?
(Ralph Droms) No Objection
(Adrian Farrel) (was Discuss, No Objection, Discuss) No Objection
(Russ Housley) (was Discuss) No Objection
(Dan Romascanu) No Objection
(Peter Saint-Andre) No Objection
(Robert Sparks) (was Discuss) No Objection
(Sean Turner) (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 220.127.116.11: 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.