Skip to main content

MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)
draft-mattsson-mikey-ticket-05

Yes

(Tim Polk)

No Objection

(Adrian Farrel)
(Dan Romascanu)
(Peter Saint-Andre)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)

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

(Tim Polk; former steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) (was Discuss, No Objection, Discuss) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection (2010-05-06)
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

No Objection ()

                            

(Ralph Droms; former steering group member) No Objection

No Objection ()

                            

(Robert Sparks; former steering group member) (was Discuss) No Objection

No Objection (2010-08-30)

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection (2010-04-22)
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

No Objection ()