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

["Glen Zorn" <[e-mail]>]

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.