MIKEY: Multimedia Internet KEYing
draft-ietf-msec-mikey-08

[Ballot comment]
My no objection is a no further objection - I support Jon's review completely, and would like to suggest that the section on KMASDP should not be present in this document - it makes too tight a coupling.

[Ballot discuss]
General issues:

Is MIKEY a stand-alone protocol, a protocol that assumes it is piggy-backed over some sort of separate session establishment protocol, or both? I was actually surprised to read the directive in the first paragraph of the IANA Considerations that a new port be assigned for stand-alone use of MIKEY for UDP, TCP and SCTP - nothing I'd read in the document up until that point led me to believe that MIKEY was intended for stand-alone use. I think there needs to be more text about possible stand-alone usage. I'd note that throughout the document (for example, in the Security Considerations), some possible threats against MIKEY or necessary elements of functionality are deferred to a session establishment protocol. The text in 5.5 about the use of MIKEY over unreliable transports also strikes me as pretty underspecified.

The capability discovery and error handling text in 5.1 (and 5.3) does not differentiate one-to-many cases from peer-to-peer cases. Surely there is some difference in the guidance that should be offered to responders. For example, looking at the last bullet in 5.3, it seems somewhat surprising that Responders that parse a MIKEY message are expected to send a vertification/reponse message to the initiator in a massively one-to-many case. The text in Section 8 doesn't really address this.

I'm a little confused by the replication of material from [KMASDP] into this draft (in Section 7), especially given that this document contains normative directives for the use of MIKEY within SDP. Is there any reason why the [KMASDP] material was not totally decoupled? Given the normative dependency on [KMASDP] (which is current a work-in-progress), isn't there some chance that normative statements in this document might conflict with [KMASDP]?

-----

1.1 - The "existing solutions", considering the emphasis of this document on applicability to SDP, should mention the k= line from RFC2327 and say why the k= line is inadequate.

2.2 - For the "tunneling" design goal, shouldn't one say that MIKEY aspires to be integrated into SDP, not SIP? (acknowledging that RTSP might not use SDP, and thus MIKEY might be used in an RTSP header)

3 - In the discussion of pre-shared secret vs. PKI vs. DH, it is surprising that no mention of the limitations of DH (especially MitMs) is made, given that pre-shared secrets and PKI are both severely critiqued. From Section 3, I might think that the only disadvantage to DH is that it is computationally expensive.

4.2.9 - "in a companion RFC" - does that mean a standards-track RFC, or will an Informational suffice? Either would be fine, but it should be specific.

Nit: 4.4 2nd paragraph - "RECOMMENDED that the MIKEY implementation supports" should be "support"

Nit: 4.5 3rd paragraph - "(the RAND will only have affect" should be "effect"

Nit: 5.4 1st paragraph - "for replay handling instead" should be "for replay handling; instead" or have some similar punctuation

Nit: 5.3 1st paragraph - "replay cache only contain messages that has" should be "contains messages that have"

Nit 5.3 1st bullet - "Each host have" should be "Each host has"

Nit 6.10.1 - Bad char in table, should be apostrophe:
        9 | senderÆs FEC order
Same in Fig 7.1, and elsewhere in Section 7.

Given the recommendation in 7.2 that the same identity be used in MIKEY and SIP, I think that a more detailed description of the syntax of the MIKEY identity payload is justified earlier in the document.

9.4 - I think that by "identity protection" 9.4 is referring to "privacy"? It might be nice to list "privacy" as a synonym for "identity protection" here, if so.

Nit 11, 1st sentence "Work for... applications have started" should be "applications has started"

[Ballot comment]
NITS:
- citation in abstract not allowed

- page 32: figure has "Encr data len" while legend has "Encr len"

- missing IPR statement

- $ /bin/checkpage.awk <drafts/draft-ietf-msec-mikey-07.txt
  Bad chars at 2230
  Bad chars at 2568
  Bad chars at 2602
  Bad chars at 3262
  Bad chars at 3298
  -: 5 lines containing non-US-ASCII characters

- RFC2119 should probably be added to normative references and
  be cited in ect 1.2

[Ballot discuss]
4.1.3 says "let n = inkey_len / 512, rounded up to the nearest integer".
Is it rounded up, or to the nearest integer? If the division yields an
integral result, is it bumped by 1? The same comment applies to m.

Explain what relevance 512 has to SHA1, which externally takes messages
of any size. Are you referring to SHA1 internals? What should be used
for hash functions that don't have SHA1's internal 512-bit structure?
I suggest that you require than any new PRF be defined by its own RFC,
rather than trying to give guidance here.

4.2.2: what parameters corresponding to 512 and 160 should be used for
SHA-256, -384, or -512?

4.2.9: what process (per rfc 2434) is needed for new parameter
registration? How does this relate to Section 10?

5.4 suggests dropping messages from attacking peers. Of course, until
the message is authenticated you don't know whom it's from, which still
leaves the door open to a CPU DoS attack.

5.5: what is done to avoid congestion?

6.11 Cite RFC 1750? (Also cite it when discussing DH exponents.)

[Ballot discuss]
This is a weak DISCUSS, and I could be pretty easily persuaded to drop it.
Essentially, I'm concerned about section 5.4, which describes the replay
protection mechanisms.  The language in the draft is a bit hard to parse
in places, and there seem to be some assumptions
that we may not be able to meet.  In particular, it cites as an assumption:

"* If the clocks are to be synchronized over the network, a secure
  network clock synchronization protocol is used."

Is there a solution available for this?  NTP v3 is cited in the references (not in this paragraph),
but I don't think that quite fits this bill, and the STIME work doesn't seem to be done.

The Security Considerations Section (9.3) does discuss this briefly, but basically points back
to 5.4 and hints that practical experience with other protocols indicates that manual configuration
may be okay.

This language also seemed strange:


  In a client-server scenario, servers may be the entities that will
  have the highest workload. It is therefore RECOMMENDED that the
  servers are the Initiators of MIKEY. This will result in that the
  servers will not need to manage any significant replay cache as they
  will refuse all incoming messages that are not a response to an
  already (by the server) sent message.

as it seems to imply that the initiation should follow a particular pattern,
regardless of the pattern of the underlying protocol.  In other words,
it sounds like it is recommending that clients wishing to initiate should
instead tell the server to initiate, then respond, so that the server replay
cache would not have to be large.  This wasn't entirely clear, though,
and some tightened language might help.

In general, an editing pass through this section by a native speaker might
be a good idea.

[Ballot discuss]
This is a weak DISCUSS, and I could be pretty easily persuaded to drop it.
Essentially, I'm concerned about section 5.4, which describes the replay
protection mechanisms.  The language in the draft is a bit hard to parse
in places, and there seem to be some assumptions
that we may not be able to meet.  In particular, it cites as an assumption:

"* If the clocks are to be synchronized over the network, a secure
  network clock synchronization protocol is used."

Is there a solution available for this?  NTP v3 is cited in the references (not in this paragraph),
but I don't think that quite fits this bill, and the STIME work doesn't seemt o be done.

The Security Considerations Section (9.3) does discuss this briefly, but basically points back
to 5.4 and hints that practical experience with other protocols indicates that manual configuration
may be okay.

This language also seemed strange:


  In a client-server scenario, servers may be the entities that will
  have the highest workload. It is therefore RECOMMENDED that the
  servers are the Initiators of MIKEY. This will result in that the
  servers will not need to manage any significant replay cache as they
  will refuse all incoming messages that are not a response to an
  already (by the server) sent message.

as it seems to imply that the initiation should follow a particular pattern,
regardless of the pattern of the underlying protocol.  In other words,
it sounds like it is recommending that clients wishing to initiate should
instead tell the server to initiate, then respond, so that the server replay
cache would not have to be large.  This wasn't entirely clear, though,
and some tightened language might help.

In general, an editing pass through this section by a native speaker might
be a good idea.

[Ballot discuss]
This is a weak DISCUSS, and I could be pretty easily persuaded to drop it.  Essentially, I'm concerned about section 5.4, which describes the replay protection mechanisms.  The
language in the draft is a bit hard to parse in places, and there seem to be some assumptions
that we may not be able to meet.  In particular, it cites as an assumption:

"* If the clocks are to be synchronized over the network, a secure
  network clock synchronization protocol is used."

Is there a solution available for this?  NTP v3 is cited in the references (not in this paragraph),
but I don't think that quite fits this bill, and the STIME work doesn't seemt o be done.

The Security Considerations Section (9.3) does discuss this briefly, but basically points back
to 5.4 and hints that practical experience with other protocols indicates that manual configuration
may be okay.

This language also seemed strange:


  In a client-server scenario, servers may be the entities that will
  have the highest workload. It is therefore RECOMMENDED that the
  servers are the Initiators of MIKEY. This will result in that the
  servers will not need to manage any significant replay cache as they
  will refuse all incoming messages that are not a response to an
  already (by the server) sent message.

as it seems to imply that the initiation should follow a particular pattern,
regardless of the pattern of the underlying protocol.  In other words,
it sounds like it is recommending that clients wishing to initiate should
instead tell the server to initiate, then respond, so that the server replay
cache would not have to be large.  This wasn't entirely clear, though,
and some tightened language might help.

In general, an editing pass through this section by a native speaker might
be a good idea.