Re: [secdir] secdir review of draft-cakulev-mikey-ibake-02

["Cakulev, Violeta (Violeta)" <[e-mail]>]

Glen,
Thanks for the comments.
Please see inline ([VC]).

-Violeta

________________________________
From: Glen Zorn [mailto:[e-mail]]
Sent: Wednesday, September 22, 2010 5:27 AM
To: [e-mail]; [e-mail]; Cakulev, Violeta (Violeta); Sundaram, Ganapathy S (Ganesh); 'Tim Polk'
Subject: secdir review of draft-cakulev-mikey-ibake-02


I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the Security Area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.



Editorial Comments


General

*         Articles are missing in a large number of places (too many to specify and correct one-by-one here).  For example, "The REQUEST_KEY_INIT message includes Initiator's public identity" which should, presupposing that "Initiator" is not a proper noun, read  "The REQUEST_KEY_INIT message includes the Initiator's public identity".  Other examples are given below; please correct.

Abstract

*         s/relies on trusted key management service/relies on a trusted key management service/
[VC]  Changed as suggested.

Section 1
Paragraph 1

*         s/Multimedia Internet Keying (MIKEY) [RFC3830] specification/The Multimedia Internet Keying (MIKEY) [RFC3830] specification/

*         The last sentence doesn't make a lot of sense to me; suggest changing "Following MIKEY specification, multiple  extensions of MIKEY have been specified such as [RFC4650] and  [RFC4738]." to "Multiple extensions of MIKEY have been defined, such as HMAC-Authenticated Diffie-Hellman [RFC4650] and MIKEY-RSA-R [RFC4738]."
[VC] Changed as suggested.
Paragraph 2

*         s/key management services will have to be online/such key management services would have to be online/

*         The statement that "In some applications, this architecture creates a huge burden on operators to install, and manage these boxes." seems to be unnecessarily evangelistic; suggest deleting it.

*         I don't know what "operational discomfort on the part of end-users" means.
[VC] Changed as suggested. "operational discomfort on the part of end-users" is deleted.
Paragraph 3

*         Suggest changing the first sentence to read "This document describes a solution in which the KMS are provided by low availability..."

*         s/identity based/identity-based/

*         s/in the date field, is/in the date field is/

*         Suggest changing "for a whole month (more generally subscription cycle) at the beginning of a subscription cycle." to "for a whole subscription cycle at the beginning of the cycle."
[VC] Changed as suggested.


Section 2

*         It's not clear why "Definitions and Notation" and "Abbreviations" are sub-sections of "Requirements notation".   Suggest that Section 2 be re-titled as "Terminology", with "Requirements Language", "Definitions and Notation" and "Abbreviations" as sub-sections.

*         s/IBE framework is defined in/The IBE framework is defined in/

*         I'm continually amazed by the apparent inability of people who presumably work with objects and pointers thereto to distinguish between a reference and the document to which it refers.  [RFC5091] is a pointer; it does not define anything, let alone the IBE framework.

*         s/Identity Based/Identity-based/g

*         Add definitions of TGK and TEK to the list of abbreviations.
[VC] Changed as suggested.

Section 3.2

*         It's not clear that "call" and "session" are the same thing.  Suggest changing "redirect the call to a different destination" to "redirect the session to a different destination" for the sake of clarity and consistency.

*         The acronym "IMS" is used w/o being previously defined; suggest adding an entry for IMS to the "Abbreviations" section.
[VC] Changed as suggested. References to IMS are deleted.

Section 4.1

*         In the second paragraph, "Key Management Services" is plural but seems to generally referred to in the singular.  As an example, how should one read "KMSs"? "Key Management Serviceses"?  Suggest s/Key Management Services/Key Management Service/G

*         Correct grammar: Change "The Initiator and the Responder do not share any credentials, however the Initiator knows Responder's public identity.  Below, description of how private keys are obtained using MIKEY messages is provided.  Alternative way" to "The Initiator and Responder do not share any credentials; however, the Initiator knows the Responder's public identity.  Below, a description of how private keys are obtained using MIKEY messages is provided.  An alternative way"
[VC] Changed as suggested.

Section 4.2.1

*         In the first paragraph, s/the user have pre-shared credentials/the user has pre-shared credentials
[VC] Changed as suggested.

Section 4.2.1.1.1

*         s/[RFC3830] Section 4.1.4/Section 4.1.4 of RFC 3830/
[VC] Changed as suggested.

Section 4.2.1.1.2

*         The first sentence makes no sense.

*         In the second paragraph, s/PKE payload/The PKE payload/
[VC] The first sentence is modified.

Section 4.2.1.2

*         The second sentence of the first paragraph says "In case of a REQUEST_KEY_INIT_PKE message, the KMS MUST ensure that the IDcert is equal to the identity specified in the certificate."  My guess is that IDcert should actually be IDRi here, since IDcert occurs nowhere else in the draft.
[VC] Changes are reflected in the latest version of the I-D.

Section 4.2.2

*         s/key mode ,/key mode,/
[VC] Changed as suggested.


Technical Comments

General

*         The fourth paragraph of Section 4.1 (and elsewhere) says 'If the Initiator is authorized to make the request' but the criteria for this authorization decision don't seem to be specified anywhere in the document.  Since this decision is vital to the successful operation of the protocol, I think it would be nice if the authors gave readers a clue as to how to go about making it.
[VC] Figure 4 is added to clarify trust relation assumed in the I-D. Trust relation between a user and the KMS is pre-established and is out of scope of this document. Modifications are made throughout the text to address this comment elsewhere in the I-D.

Section 4.1

*         The first sentence of paragraph 4 contains rather confusing notation.  It says "The Initiator next chooses a random x and computes xP (i.e. adds P to itself x times), where P is a point on elliptic curve E known to all users."  The notation "xP" is a conventional one for expressing the multiplication of P by x, which is not the same as the addition of P to itself x times.  If the latter interpretation is actually, I think that a better notation should be chosen.
[VC] Currently, , there is no notation that is common across I-Ds and RFCs for elliptic curve point multiplication. Therefore, the intent was to define it in that one sentence. Nevertheless, to clarify the notation and text, point multiplication is denoted as [x]P in the latest version of the I-D, and this notation is added in Section 2.

Section 4.2.1.1

*         The last sentence says "The KEMAC payload SHOULD be used only when the user needs to use specific keys.  Otherwise, this payload SHALL not be used."  This appears to be self-contradictory, since "SHOULD" allows the usage under certain circumstances while "SHALL NOT" (note typo) absolutely forbids it.
[VC] Good point. Fixed in the latest version

Section 4.2.1.2

*         The last paragraph says "If the KMS cannot correctly parse the received message, or the user is not authorized to receive the requested Private Keys, the KMS SHOULD send an appropriate Error message."  I'm assuming that the term "Error message" here is referring to the Error payload defined in section 6.12 of RFC 3830, but I don't see any Error no values therein that seem appropriate for either of the listed conditions.
[VC] Error message here actually refers to error message defined in Section 5.1.2 of RFC 3830. Nevertheless, the text is modified to address the first technical comment.