Last Call Review of draft-cakulev-mikey-ibake-
review-cakulev-mikey-ibake-secdir-lc-zorn-2010-09-25-00

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.