MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)
RFC 6043

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' **)
No email
send info
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?

(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

Comment (2010-04-22)
No email
send info
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.