[Dime] RE : Re: AW: unexpected consequence of deprecating E2E security in RFC 3588 bis

<lionel.morand@orange.com> Sun, 30 September 2012 11:15 UTC

Return-Path: <lionel.morand@orange.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E111621F84DD for <dime@ietfa.amsl.com>; Sun, 30 Sep 2012 04:15:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id PCwVGwOVduxJ for <dime@ietfa.amsl.com>; Sun, 30 Sep 2012 04:15:14 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0B17921F84D8 for <dime@ietf.org>; Sun, 30 Sep 2012 04:15:13 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 9C51522C313; Sun, 30 Sep 2012 13:15:12 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown []) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 7543E4C027; Sun, 30 Sep 2012 13:15:12 +0200 (CEST)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Sun, 30 Sep 2012 13:15:11 +0200
From: <lionel.morand@orange.com>
To: Glen Zorn <glenzorn@gmail.com>
Thread-Topic: RE : Re: AW: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis
Thread-Index: AQHNnvzbNXtq6DSorEKrYoYEPqx3gQ==
Date: Sun, 30 Sep 2012 11:15:11 +0000
Message-ID: <26184_1349003712_506829C0_26184_9758_1_tTKzDPgZM1TV@TJw0VVKN>
References: <5062DD0C.2080300@gmail.com> <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5063CEC3.9080305@gmail.com> <1836CE1BA4F81F46921CA0334F7E4274583123AEA0@HE113456.emea1.cds.t-internal.com> <5064329D.40203@gmail.com> <20096_1348913297_5066C891_20096_2169_1_6B7134B31289DC4FAF731D844122B36E0758C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5066CB47.1070807@gmail.com> <19603_1348915144_5066CFC8_19603_1305_1_6B7134B31289DC4FAF731D844122B36E0758E2@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <5066EA99.3020801@gmail.com>
In-Reply-To: <5066EA99.3020801@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2012.9.30.80322
Cc: "draft-ietf-dime-rfc3588bis@tools.ietf.org" <draft-ietf-dime-rfc3588bis@tools.ietf.org>, "Stefan.Schroeder06@telekom.de" <Stefan.Schroeder06@telekom.de>, "dime@ietf.org" <dime@ietf.org>, "turners@ieca.com" <turners@ieca.com>, "stephen.farrell@cs.tcd.ie" <stephen.farrell@cs.tcd.ie>
Subject: [Dime] RE : Re: AW: unexpected consequence of deprecating E2E security in RFC 3588 bis
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: <http://www.ietf.org/mail-archive/web/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: Sun, 30 Sep 2012 11:15:15 -0000

Hi Glen,

After the list of avps, we should say:

"Diameter messages containing these AVPs and any other AVP considered as security-sensitive MUST only be sent..."


-----Message d'origine-----
De : Glen Zorn
Envoyé :  29/09/2012, 14:33
CC : Glen Zorn; dieter.jacobsohn@telekom.de; dime@ietf.org; draft-ietf-dime-rfc3588bis@tools.ietf.org; turners@ieca.com; stephen.farrell@cs.tcd.ie; Stefan.Schroeder06@telekom.de
Objet : Re: AW: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis

On 09/29/2012 05:39 PM, lionel.morand@orange.com wrote:

> It is actually needed if we  don't want to lose info. These AVPs
 > should be listed in a table in these sections with an indication that
 > is a list of AVPs that can be considered as security-sensitive, in
 > order to not start a discussion on which AVP is really sensitive and
 > which not. Anyway, designers will have to decide what they want to do
 > and this list is mainly for information.
OK, this is what I've got now:

13.3.  AVP Considerations

    Diameter AVPs often contain security-sensitive data; for example,
    user passwords and location data, network addresses and cryptographic
    keys.  The following AVPs defined in this document are considered to
    be security-sensitive:

    o  Acct-Interim-Interval

    o  Accounting-Realtime-Required

    o  Acct-Multi-Session-Id

    o  Accounting-Record-Number

    o  Accounting-Record-Type

    o  Accounting-Session-Id

    o  Accounting-Sub-Session-Id

    o  Class

    o  Session-Id

    o  Session-Binding

    o  Session-Server-Failover

    o  User-Name

    Diameter messages containing these AVPs MUST only be sent protected
    via mutually authenticated TLS or IPsec.  In addition, those messages
    MUST NOT be sent via intermediate nodes unless there is end-to-end
    security between the originator and recipient or the originator has
    locally trusted configuration that indicates that end-to-end security
    is not needed.  For example, end-to-end security may not be required
    in the case where an intermediary node is known to be operated as
    part of the same administrative domain as the endpoints so that an
    ability to successfully compromise the intermediary would imply a
    high probability of being able to compromise the endpoints as well.
    Note that no end-to-end security mechanism is specified in this


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.