Document: draft-ietf-msec-mikey-dhhmac-09.txt Review: Mary Barnes Date: 2 mars 2005 Assignment: ----------- HMAC-authenticated Diffie-Hellman for MIKEY (Proposed Standard) - 2 of 13 draft-ietf-msec-mikey-dhhmac-09.txt Token: Russ Housley Reviewer: Mary Barnes Summary: -------- Document should be ready for publication as a Proposed Standard following some editorial clean-up. There are some sections that just aren't necessary, and should either be removed or put in an appendix and the document is a bit difficult to read, so I have suggested some re-wordings for the most difficult parts I encountered. Editorial clean-up: ------------------- - page 1: I don't think the IPR statement needs to be in a separate section. It should be the first paragraph of the "Status of this Memo" section. - section 1, page 3, 2nd/3rd paragraphs. There's a formatting problem with the paragraph break - section 1, page 4, first bullet after the paragraph beginning "However, it is known [7].." is a bit unclear: " The symmetric key distribution protocol (MIKEY-PS) is simple to implement but does not nicely scale in any larger configuration of potential peer entities due to the need of mutually pre-assigned shared master secrets." Per the MIKEY spec, it's not indended to scale to large configurations, so I would suggest rewording something like: " The symmetric key distribution protocol (MIKEY-PS) is simple to implement, however, was not intended to scale to support any configurations beyond peer-to-peer, simple one-to-many, and small-size (interactive) groups, due to the need for mutually pre-assigned shared master secrets." - section 1, page 5: At a minimum, the following paragraph needs some grammatical separators: " As in the previous method, this introduces the dependency upon a public-key infrastructure with its strength on scalability but also the limitations on computational costs in performing the asymmetric long-integer operations and the potential need for additional communication for verification of the digital certificates." I would suggest rewording something like the following, which I think still captures all the concepts that were in that one long sentence [I don't think you need to bring the scalability of the public-key infrastructure into this sentence as it's much more clear in the previous section]: " As in the previous method, this introduces a dependency upon a public-key infrastructure and potential limitations due to computational costs in performing the asymmetric long-integer operations. In addition, there is the potential need for additional communication for verification of the digital certificates." or just even more simply state: " This approach has the same advantages and deficiencies as described in the previous section in terms of a public-key infrastructure." - section 1, page 6, 2nd paragraph, 1st sentence needs some grammatical separators and/or minor rewording (it's not clear which protocol is "that"): " The idea of that protocol is to apply the Diffie-Hellman key agreement but instead of deploying a digital signature for authenticity of the exchanged keying material rather uses a keyed-hash upon using symmetrically pre-assigned shared secrets." I would suggest changing to something like: " The idea of the protocol in this document is to apply the Diffie-Hellman key agreement, but rather than deploying a digital signature for authenticity of the exchanged keying material, instead use a keyed-hash upon using symmetrically pre-assigned shared secrets." - section 1.1, 1st sentence: change " ...see [3] and [3] sections 1.3-1.4." to "...see [3], sections 1.3 and 1.4." - section 2, 3rd paragraph: "..it's peer..." should be "...its peer..." - section 2, 4th paragraph: based on comment on 5th paragraph, I think this paragraph should be clarified that MIKEY is based on having "at least" "loosely synchronized clocks" as I initially read id as MIKEY is based only on "loosely synchronized clocks" until I checked 3830. I would suggest changing from: " As is the case for the other three MIKEY key management protocol, DHHMAC assumes loosely synchronized clocks among the entities in the small group." to something like: " As is the case for the other three MIKEY key management protocol, DHHMAC assumes, at least, loosely synchronized clocks among the entities in the small group." - section 2, 5th paragraph: I don't think the "Note:" is necessary (and I don't think should be used for normative "RECOMMENDS", which I'm assuming this is. It's also not entirely clear from reading that note that the synchronization is required for this protocol (until later in the doc) from reading this paragraph. I would suggest rewording that paragraph from: " Note: To synchronize the clocks in a secure manner, some operational or procedural means are recommended. However, MIKEY-DHHMAC does not describe any secure time synchronization measures and leaves such tasks to the discretion of the implementation. The reader is referred to [3] section 5.4 and [3] section 9.3 that give guidance on clock synchronization and timestamps. " to: " To synchronize the clocks in a secure manner, some operational or procedural means are recommended. MIKEY-DHHMAC does not define any secure time synchronization measures, however, sections 5.4 and 9.3 of [3] provide implementation guidance on clock synchronization and timestamps." - section 2.1, page 9, 1st paragraph: suggest minor rewording from: " MIKEY-DHHMAC as well as the other MIKEY key management protocols are optimized and targeted for the purpose of multimedia applications with application-level key management needs under real-time session setup and session management constraints." to something like: " MIKEY-DHHMAC, as well as the other MIKEY key management protocols, is intended for application-level key management and is optimized for multimedia applications with real-time session setup and session management constraints." - section 2.1, page 9, bullet a): reference [5] is really in the wrong place, as it appears that should be the SIP or SDP reference, but it's the MMUSIC MIKEY draft, thus [5] really refers to the whole of bullet a). I also think that the SDP offer/answer draft should be explicitly referenced as it's key to how this works (i.e. I think that draft is a more important reference for this document than RFC3261): " a) SIP/SDP (see [5]) where the encoded MIKEY messages are encapsulated and transported in SDP containers of the SDP offer/answer handshake," I would suggest changing that bullet to: " a) SIP/SDP where the encoded MIKEY messages are encapsulated and transported in SDP containers of the SDP offer/answer [RFC3264] handshake, as described in [5]," - section 2.1, page 9,last paragraph: I think you meant "particular" rather than "peculiar"? - section 2.1.1, page 9: I don't understand why this section is in here. I would think this would be in an Appendix (referenced in bullet b), not here at all, have a parallel section for SIP or be a SIP section rather than H.323. - section 3, page 12, 2nd paragraph: "OAKELEY" should be "OAKLEY" - section 3, page 12, 5th paragraph: It's not clear who is "It" in the 2nd of the following two sentences: " This approach is less expensive than digitally signed Diffie-Hellman. It requires first of all, that both sides compute one exponentiation and one HMAC, then one HMAC verification and finally another Diffie-Hellman exponentiation." It could either be interpreted to be referring to "Diffe-Hellman", but it could also be interpreted to be "This approach" in the previous sentence, which I think is what you intended? - section 4.2, page 16, last sentence in the paragraph before table 4.2.a: "...within MAC field." should be "...within the MAC field." - section 5.2, page 17, 1st para, 1st sentence: "cover" should at least be "covers", but would propose to change for readability and grammatical correctness from: " The threat model that this document adheres to cover the issues of end-to-end security in the Internet generally; without ruling out the possibility that MIKEY DHHMAC be deployed in a corporate, closed IP environment. " to something like: " The threat model, to which this document adheres, covers the issues of end-to-end security in the Internet generally, withiout ruling out the possibility that MIKEY DHHMAC be deployed in a corporate, closed IP environment." - section 5.2, page 17, 1st bullet: For consistency with other bullets, replace the "." with ":" after the 1st sentence. - section 5.2, page 17, 2nd bullet: Propose to change the sentence: " Rather, by the Diffie-Hellman "encryption" operation, that conceals the secret (pseudo) random values, only partial information (i.e. the DH- half key) for construction of the TGK is transmitted." to something like: " Instead, by using the Diffie-Hellman "encryption" operation, which conceals the secret (pseudo) random values, only partial information (i.e. the DH- half key) for construction of the TGK is transmitted." - section 5.2, page 18/19, 1st bullet: propose to change: " Under certain reasonable assumptions (see 5.4 below) it is widely believed that DHHMAC is sufficiently secure and that such attacks be infeasible although the possibility of a successful attack cannot be ruled out completely." to: " Under certain reasonable assumptions (see 5.4 below) it is widely believed that DHHMAC is sufficiently secure and that such attacks are infeasible, although the possibility of a successful attack cannot be completely ruled out." - section 5.2, page 19, 2nd bullet: phrase "...of this environment..." isn't clear. Should tihs be "...in this environment..." or perhaps " ...within the context of DHHMAC..."? - section 5.2, page 19, Identity protection bullet. It mentions that SIP does not currently have end-to-end Identify protection, but there is ongoing work in the SIP WG for Identity protection, thus I would suggest just removing the sentence: " On the other hand, it is expected that MIKEY-DHHMAC is typically being deployed within SDP/SIP ([20], [5]); both those protocols do not provide end-to-end identity protection either. " - section 5.3, page 20, Cryptographic integrity check bullet. "countermeasure" should be "countermeasures" - section 5.3, page 21, Cryptographic integrity check bullet. "timely" should be "on time" or "in a timely manner" - section 5.3, page 22, Perfect Forward secrecy bullet. Change: " As such, DHHMAC but also digitally signed DH provides a far superior security level over the pre-shared or public-key based key distribution protocol in that respect." to: " As such, DHHMAC, as well as digitally signed DH, provides a far superior security level over the pre-shared or public-key based key distribution protocol in that respect." - section 5.3, page 23, Security Infrastructure bullet, 2nd sentence, clarify the phrase by changing from: "...and thus is believed..." as "....and thus DHHMAC is believed..." - section 5.5, page 25, 2nd paragraph: reword the sentence from: "The mathematical and cryptographic assumptions upon the properties of the PRF, the Diffie-Hellman algorithm (discrete log-assumption), the HMAC and SHA1 algorithms have not been proved yet nor have they been disproved by the time of this writing. " to: " The mathematical and cryptographic assumptions of the properties of the PRF, the Diffie-Hellman algorithm (discrete log-assumption), the HMAC algorithm and SHA1 algorithms have been neither proven nor disproven at this time." - section 5.5, page 25, 6th paragraph (or 5th - there's a formatting problem either way), 1st sentence: "...and thus very computational intensive..." should be "...and thus very computationally intensive..." - section 5.5, page 25, 6th paragraph (or 5th - there's a formatting problem either way), 2nd sentence: "....and providing even significant permformance benefits..." should be "....and providing even more significant permformance benefits..." or "....and providing significant permformance benefits... - Conclusions, page 26. Delete this section. It really doesn't add value and I think most of that material is covered by abstract and intro. - Section 7, IANA considerations, page 27. I would think you would want to include the necessary details from table 4.1.a in this section to faciliate the process.