I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
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.
That's it.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: [EMAIL PROTECTED],bell-labs.com,acm.org}
WWW: http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Gen-art mailing list
[email protected]
http://www.ietf.org/mailman/listinfo/gen-art
