Re: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis
<lionel.morand@orange.com> Wed, 26 September 2012 18:26 UTC
Return-Path: <lionel.morand@orange.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8334921F8585 for <dime@ietfa.amsl.com>; Wed, 26 Sep 2012 11:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.612
X-Spam-Level:
X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqZC6BGBSmMf for <dime@ietfa.amsl.com>; Wed, 26 Sep 2012 11:26:43 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFD521F8582 for <dime@ietf.org>; Wed, 26 Sep 2012 11:26:43 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 2F88E18C2A2; Wed, 26 Sep 2012 20:26:42 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 14F424C0C4; Wed, 26 Sep 2012 20:26:42 +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; Wed, 26 Sep 2012 20:26:41 +0200
From: lionel.morand@orange.com
To: Glen Zorn <glenzorn@gmail.com>, draft-ietf-dime-rfc3588bis <draft-ietf-dime-rfc3588bis@tools.ietf.org>
Thread-Topic: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis
Thread-Index: AQHNm9Q4eohZSPW+X0ufI8s6t2bgaZec8Crw
Date: Wed, 26 Sep 2012 18:26:41 +0000
Message-ID: <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <5062DD0C.2080300@gmail.com>
In-Reply-To: <5062DD0C.2080300@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.2]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.26.150316
Cc: dime mailing list <dime@ietf.org>
Subject: Re: [Dime] 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: Wed, 26 Sep 2012 18:26:44 -0000
Is it somehow covered in http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-34#section-13.3? Diameter AVPs often contain security-sensitive data; for example, user passwords and location data, network addresses and cryptographic keys. The Diameter messages containing such AVPs MUST only be sent protected via mutually authenticated TLS or IPsec. In addition, those messages SHOULD NOT be sent via intermediate nodes that would expose the sensitive data at those nodes except in cases where an intermediary 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. Do you think that it is needed to add somewhere that "the originator has locally trusted configuration that indicates that end-to-end security is not needed"? Lionel -----Message d'origine----- De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Glen Zorn Envoyé : mercredi 26 septembre 2012 12:47 À : draft-ietf-dime-rfc3588bis Cc : dime mailing list Objet : [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis Section 4.5 of RFC 3588 says: The following table describes the Diameter AVPs defined in the base protocol, their AVP Code values, types, possible flag values and whether the AVP MAY be encrypted. For the originator of a Diameter message, "Encr" (Encryption) means that if a message containing that AVP is to be sent via a Diameter agent (proxy, redirect or relay) then the message MUST NOT be sent unless there is end-to-end security between the originator and the recipient and integrity / confidentiality protection is offered for this AVP OR the originator has locally trusted configuration that indicates that end-to-end security is not needed. Similarly, for the originator of a Diameter message, a "P" in the "MAY" column means that if a message containing that AVP is to be sent via a Diameter agent (proxy, redirect or relay) then the message MUST NOT be sent unless there is end-to-end security between the originator and the recipient or the originator has locally trusted configuration that indicates that end-to-end security is not needed. The corresponding section of 3588bis says: The following table describes the Diameter AVPs defined in the base protocol, their AVP Code values, types, and possible flag values. Considerable information (and normative guidance) seems to have been lost here: in particular, the statements that "the message MUST NOT be sent unless... the originator has locally trusted configuration that indicates that end-to-end security is not needed" would seem to be valid even in the absence of an E2E security solution. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _________________________________________________________________________________________________________________________ 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.
- [Dime] unexpected consequence of deprecating E2E … Glen Zorn
- Re: [Dime] unexpected consequence of deprecating … lionel.morand
- Re: [Dime] unexpected consequence of deprecating … Glen Zorn
- Re: [Dime] unexpected consequence of deprecating … dieter.jacobsohn
- Re: [Dime] unexpected consequence of deprecating … Glen Zorn
- Re: [Dime] unexpected consequence of deprecating … lionel.morand
- Re: [Dime] unexpected consequence of deprecating … Glen Zorn
- Re: [Dime] unexpected consequence of deprecating … lionel.morand
- Re: [Dime] unexpected consequence of deprecating … Glen Zorn
- [Dime] RE : Re: AW: unexpected consequence of dep… lionel.morand
- Re: [Dime] RE : Re: AW: unexpected consequence of… Stephen Farrell
- Re: [Dime] RE : Re: AW: unexpected consequence of… Glen Zorn
- Re: [Dime] RE : Re: AW: unexpected consequence of… Glen Zorn
- Re: [Dime] RE : Re: AW: unexpected consequence of… dieter.jacobsohn
- [Dime] unexpected consequence of deprecating E2E … dieter.jacobsohn
- Re: [Dime] unexpected consequence of deprecating … jouni korhonen