Last Call Review of draft-ietf-dime-e2e-sec-req-04
review-ietf-dime-e2e-sec-req-04-secdir-lc-perlman-2016-05-19-00
| Request | Review of | draft-ietf-dime-e2e-sec-req |
|---|---|---|
| Requested revision | No specific revision (document currently at 05) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2016-05-12 | |
| Requested | 2016-05-05 | |
| Authors | Hannes Tschofenig , Jouni Korhonen , Glen Zorn , Kervin Pillay | |
| Draft last updated | 2016-05-19 | |
| Completed reviews |
Genart Last Call review of -04
by
Christer Holmberg
(diff)
Secdir Last Call review of -04 by Radia Perlman (diff) Opsdir Last Call review of -04 by Qin Wu (diff) |
|
| Assignment | Reviewer | Radia Perlman |
| State | Completed | |
| Review |
review-ietf-dime-e2e-sec-req-04-secdir-lc-perlman-2016-05-19
|
|
| Reviewed revision | 04 (document currently at 05) | |
| Result | Has Issues | |
| Completed | 2016-05-19 |
review-ietf-dime-e2e-sec-req-04-secdir-lc-perlman-2016-05-19-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.
The document is readable, though a pass through for simple grammar would be
helpful. However, a more important editorial comment is that AVP should be
defined under terminology and not wait until section 3 to expand the acronym.
-----------
Some things are confusing to me. For instance,
Requirement #7: The solution MUST support symmetric keys and
asymmetric keys.
Motivation: Symmetric and asymmetric cryptographic algorithms
provide different security services. Asymmetric algorithms,
for example, allow non-repudiation services to be offered.
I'm not sure what the motivation was for putting this in. Why would diameter
need nonrepudiation? And if it's using asymmetric, because it wants
nonrepudiation, why would it also need symmetric keys? Indeed, usually
protocols that use asymmetric keys also use symmetric. Or is it saying that
preshared secret keys, or Kerberos must be supported even if a public key
scheme is fully deployed? Why would that be?
--------
I found this sentence confusing:
As an example, consider the Diameter EAP
application [4] that allows the transport of keying material
between the Diameter server to the Diameter client (using the EAP-
Master-Session-Key AVP) for the protection of air interface
between the end device and the network access server.
What is "air interface"? Do you mean the wireless link? Is the "diameter
client" the same as the "end device"? What is the "network access server"?
None of these things are in the diagram.
------------
Also,
{AVP}k refers to an AVP that
experiences security protection (using key "k") without further
distinguishing between integrity and confidentiality protection.
I think it's a good idea to have different notation for confidentiality and
integrity, because sometimes things need one, and sometimes they need both.
---------
Radia