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/   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].” 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. 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.”   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.   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.   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”   Section 4.2.1 ·          In the first paragraph, s/the user have pre-shared credentials/the user has pre-shared credentials   Section 4.2.1.1.1 ·          s/[RFC3830] Section 4.1.4/Section 4.1.4 of RFC 3830/   Section 4.2.1.1.2 ·          The first sentence makes no sense. ·          In the second paragraph, s/PKE payload/The PKE payload/   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.   Section 4.2.2 ·          s/key mode ,/key mode,/     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.    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.   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.   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.