Document: draft-ietf-msec-mikey-applicability-07.txt
Reviewer: Vijay K. Gurbani
Review Date: 11 Feb 2008
IESG Telechat date: 12 Feb 2008

Summary: This draft is basically ready for publication, but has nits that should be fixed before publication.  Please see below for a list of review items.

- S1, second paragraph:
   s/For MIKEY meanwhile/For MIKEY, meanwhile,/

- S1, page 4:
   You may want to follow established convention and spell out the
   TESLA acronym before first use.

- S1, at the bottom of page 5: suggested rewording as follows:

   OLD:
   The use cases discussed in this document are strongly related
   to dedicated SIP call scenarios providing challenges for key
   management in general, as there are:

   NEW:
   The use cases discussed in this document are inspired by
   specific protocol workings of SIP that have proved to be
   problematic for a general key distribution mechanisms in
   general.  These protocol workings are described in detail
   in Wing et al. [I-D.ietf-sip-media-security-requirements]
   to include the following:

- S2: I would suggest defining key SIP concepts such as forking,
   redirect and re-target in the definitions.  In the same manner
   as rfc3830-specific terms -- TGK, TEK -- are defined for the
   non-cryptographically oriented reader, a list of SIP terms will
   help orient the non-SIP reader.  In particular, I will suggest
   the following definitions:

   Forking: The ability of a SIP proxy to replicate an incoming
    request to multiple outgoing requests in order to efficiently
    find the called party for rendezvous.  SIP forking can be
    done in serial (depth-first search), or in parallel (breadth-
    first search).

   Redirect: The ability of a SIP proxy to send a final response
    that redirects the caller to send a request to an alternate
    location.

   Re-target: The ability of a SIP proxy to re-write the Request-
    URI thereby altering the destination of the request without
    explicitly notifying the user agent client.

- S2: Certain cryptographic terms used in the protocol message
   flows are not defined; more specifically, {SP}, KEMAC, V.  If
   the intention is that the reader should be familiar with these,
   then please feel free to disregard this comment.  Otherwise,
   defining these may help.

- S2, page 9, definition of PFS provisions:
   s/the the property/is the property

- S2, page 9, last bullet item ("Support of group keying"): I
   cannot understand the sentence as written.  Re-wording may help.

- S3.3, page 11, second paragraph:
   s/Moreover, it provides also the/Moreover, it also provides the

- S3.3, page 11, second paragraph: It is stated that -

      The advantages of this approach are a fair, mutual key agreement
      (both parties provide to the key), perfect forward secrecy, and
      the absence of the need to fetch a certificate in advance as
      needed for the MIKEY-RSA method depicted above.  Moreover, it
      provides also the option to use self-signed certificates to
      avoid PKI (would result in limited scalability and more complex
      provisioning).

   What does the "would" in the last fragment above refer to?

   Are you making the statement that using PKI would result in "limited
   scalability and more complex provisioning"?  Or are you making
   a case that using the approach described in this section would
   result in "limited scalability and more complex provisioning"?  I
   cannot figure which one you mean.

- S3.4, last sentence of the section:
   s/advisable to be used./advisable for use.

- S3.6, page 14, last paragraph on that page:
   s/the key), perfect/the key), and perfect/

- S3.7, towards the end of page 16: It is stated that -

      This is due to the fact that the asymmetric encryption
      requires less effort compared to the decryption using
      the private key.

   Do you mean "symmetric" encryption on the first line reproduced
   above?

- S7, first bullet item: you may want to consider re-wording the
   sentence "In contrast to MIKEY ... rather than vice versa."  As
   currently written, it is hard to parse.

- S7, last paragraph: It may help to provide references to the
   DTLS-SRTP set of documents.  Right now, the text simply says
   that "Thus, the reader is pointed to the appropriate resources
   for further information."  it will help the draft considerably
   to provide the "appropriate resources" to the reader as a list
   of references.