Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements
draft-ietf-dime-e2e-sec-req-05
Yes
(Alexey Melnikov)
(Deborah Brungard)
(Mirja Kühlewind)
(Stephen Farrell)
No Objection
(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Joel Jaeggli)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 04 and is now closed.
Alexey Melnikov Former IESG member
Yes
Yes
(for -04)
Unknown
Deborah Brungard Former IESG member
Yes
Yes
(for -04)
Unknown
Mirja Kühlewind Former IESG member
Yes
Yes
(for -04)
Unknown
Stephen Farrell Former IESG member
Yes
Yes
(for -04)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -04)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -04)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -04)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2016-06-01 for -04)
Unknown
Substantive: - I am concerned about the de-emphasis of privacy requirements. While there's a mention of confidentiality in Requirement 2, other text suggests that integrity is more important (implying privacy is less important). There are no privacy considerations. Finally, the {AVP}k convention does not distinguish hinders discussion about how the set of confidentiality-protected AVPs and integrity-protected AVPs might not be the same. [Note: I almost balloted DISCUSS over this point. I did not, because I don't want to force the working group to add requirements it doesn't believe in. But I'd like to see some discussion about this.] - The "middle to *" models may be useful, but they are not end-to-end. Given the focus on those models, I find the title of the draft to border on disinformation. The description in the introduction about protecting AVPs between "non-neighbor" nodes is more accurate. - I find it odd to find 2119 keywords in the "motivation" sections. I suspect that most of those are statements of fact. If some are really requirements, they should be presented as such. - 4: The listed advantages of the middle-middle model (and also middle-to-end and end-to-middle) seem to assume that the number of "middles" is smaller than the number of "ends". While this may be true, especially for clienty ends, it should probably be explicitly stated. -- "firewalling Diameter proxy" needs a definition or reference. - Requirement 1: Does this need discussion on deprecating algorithms when vulnerabilities become known? - Requirement 2: Please elaborate on backwards-compatibiltiy with existing applications. Is this intended to motivate the models with "middles"? - Requirement 7: This (along with some text in the introduction) implies that non-repudiation is a requirement. If so, that should be listed and elaborated as a requirement. Editorial and Nits: - 1, first paragraph: "mechanisms independent of Diameter (e.g., IPsec) is used." s/is/are - Requirement 3: The last sentence seems to ask the reader to draw a conclusion that wall-clock time can be used for anti-replay protection. If that's the intent, please say so explicitly.
Benoît Claise Former IESG member
No Objection
No Objection
(2016-06-02 for -04)
Unknown
Please engage with Qin, who reviewed this document part of the OPS-DIR directorate. This document discusses requirements for providing end to end security to protect Attribute-Value Pairs between non-neighboring Diameter nodes and I think it is almost ready for publication. But I have a few editorial comments as follows: 1. Section 3, 1st paragraph: AAA broker is usually referred to intermediate node that support AAA functionality, I am not sure one network can be labeled as AAA broker. Change AAA broker into AAA broker network? 2. Section 3, 1st bullet on eavesdropping In 1st bullet, it mentions AAA broker network. It will be nice to give a definition of AAA broker and AAA broker network in the terminology section. 3. Section 3, 2nd bullet on Injection and Manipulation s/and inject/manipulate/to inject or manipulate 4. Section 4, the 2nd ,3rd, 4th scenarios How do you prevent man in middle attack by introducing Diameter proxy? How Diameter Proxy establish trust relationship with either Diameter client or Diameter Server? Is there security requirements for this? 5. Section 4, last paragraph It looks these paragraph discusses security consideration and should be moved to section 6. 6. Section 5, requirement 4 Is there any authorization approval before delegate security functionality to another entity?
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
(2016-06-02 for -04)
Unknown
There was a Gen-ART review with some minor but good questions about clarifications. There was no revision or a response previously, but the authors have now responded, and I assume edits will be done. Thanks.
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -04)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2016-05-27 for -04)
Unknown
Radia raised some very good questions in her SecDir review and I don't see a response yet, so I'm guessing you didn't see her message. https://www.ietf.org/mail-archive/web/secdir/current/msg06573.html I'd like to see her questions addressed. Is her second question the result of a typo or does air interface refer to a wireless interface or diameter term? I'll switch to a yes after these are addressed. thanks.
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -04)
Unknown
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -04)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -04)
Unknown