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

Summary

The document shepherd is Lionel Morand. The responsible Area Director is
Stephen Farrell.

If Diameter provides a hop-by-hop security (using TLS, DTLS or IPSec)
between peers, the Diameter base protocol does not provide a mechanism
for end-to-end security.

This document describes a set of requirements for providing Diameter
security at the level of individual Attribute-Value Pairs.

Intended Status: Informational
This document will be used to evaluate future candidate solutions.

This draft is ready to move from this end to the RFC editor's end and
there are no RFC editor notes needed. Please ship it!

Thanks,
S.

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot comment]
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.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dime-e2e-sec-req-04.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-dime-e2e-sec-req@ietf.org, lionel.morand@orange.com, dime@ietf.org, dime-chairs@ietf.org, stephen.farrell@cs.tcd.ie
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Diameter AVP Level Security End-to-End Security: Scenarios and Requirements) to Informational RFC


The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Diameter AVP Level Security End-to-End Security: Scenarios and
  Requirements'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-05-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This specification discusses requirements for providing Diameter
  security at the level of individual Attribute-Value Pairs.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dime-e2e-sec-req/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dime-e2e-sec-req/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

The document shepherd is Lionel Morand. The responsible Area Director is Kathleen Moriarty.

If Diameter provides a hop-by-hop security (using TLS, DTLS or IPSec) between peers, the Diameter base protocol does not provide a mechanism for end-to-end security.
This document describes a set of requirements for providing Diameter security at the level of individual Attribute-Value Pairs.

Intended Status: Informational
This document will be used to evaluate future candidate solutions.

2. Review and Consensus

The document provides a description of various security threats in typical Diameter deployments.
Based on the threat analysis and the deployment scenarios, a set of requirements is given that a solution should fulfil for providing end-to-end protection of Diameter Attribute-Value Pairs (AVPs). 

The document received a large support for adoption when initiated and it has been reviewed multiple times, with detailed comments and corrections. The version -03 addresses the last comments received after the WGLC process. There is a strong WG consensus on the content of this document, with a broad range of people, including key experts.

3. Security Considerations

The entire document is about existing security threats and defining requirements for a solution for securing Diameter AVPs selectively between non-neighboring nodes.

4. IANA considerations

As this document does not define any solution, there is no required IANA action required.

5. Intellectual Property

The author and contributor have confirmed conformance with IETF IPR rules (RFCs 3979, 4879, 3669, and 5378). There are no IPR disclosures on the document.

6. ID Nits

There are small warnings that can be handled with a rev of the document when publishing the document;

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document seems to lack the recommended RFC 2119 boilerplate, even if
    it appears to use RFC 2119 keywords.

    (The document does seem to have the reference to RFC 2119 which the
    ID-Checklist requires).
  -- The document date (January 13, 2016) is 50 days in the past.  Is this
    intentional?

  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  == Outdated reference: A later version (-05) exists of
    draft-ietf-aaa-diameter-cms-sec-04

7. Other points

The document defines a set a security requirements for E2E protection of AVP over Diameter.
The DIME WG is confident in the requirements listed in the document and can use these requirements to define a solution for Diameter.
However, the SEC-DIR should carefully review these security requirements to validate them and see if nothing is missing.