[Dime] Benoit Claise's No Objection on draft-ietf-dime-e2e-sec-req-04: (with COMMENT)

"Benoit Claise" <bclaise@cisco.com> Thu, 02 June 2016 13:07 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: dime@ietf.org
Delivered-To: dime@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D419012D190; Thu, 2 Jun 2016 06:07:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Benoit Claise" <bclaise@cisco.com>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160602130721.8789.22144.idtracker@ietfa.amsl.com>
Date: Thu, 02 Jun 2016 06:07:21 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/sFoNvaIlzbA5_sVB68OLmv02tCU>
Cc: draft-ietf-dime-e2e-sec-req@ietf.org, dime@ietf.org, dime-chairs@ietf.org
Subject: [Dime] Benoit Claise's No Objection on draft-ietf-dime-e2e-sec-req-04: (with COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jun 2016 13:07:22 -0000

Benoit Claise has entered the following ballot position for
draft-ietf-dime-e2e-sec-req-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Please engage with Qin, who reviewed this document part of the OPS-DIR

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

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?