Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements
draft-ietf-dime-e2e-sec-req-05

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.

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?

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.

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.