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

<dieter.jacobsohn@telekom.de> Mon, 01 October 2012 08:12 UTC

Return-Path: <dieter.jacobsohn@telekom.de>
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 63AEF21F8608 for <dime@ietfa.amsl.com>; Mon, 1 Oct 2012 01:12:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.835
X-Spam-Level:
X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=1.414, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 PeL9Z3aY2ZRw for <dime@ietfa.amsl.com>; Mon, 1 Oct 2012 01:12:56 -0700 (PDT)
Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 3851B21F8595 for <dime@ietf.org>; Mon, 1 Oct 2012 01:12:55 -0700 (PDT)
Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 01 Oct 2012 10:12:52 +0200
Received: from HE113456.emea1.cds.t-internal.com ([169.254.3.121]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 1 Oct 2012 10:12:52 +0200
From: <dieter.jacobsohn@telekom.de>
To: <stephen.farrell@cs.tcd.ie>, <lionel.morand@orange.com>
Date: Mon, 1 Oct 2012 10:12:51 +0200
Thread-Topic: RE : Re: AW: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis
Thread-Index: Ac2fEj5qIUyjgkHeRN2PlIhMMiVTugAmbTqA
Message-ID: <1836CE1BA4F81F46921CA0334F7E4274583123B37A@HE113456.emea1.cds.t-internal.com>
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> <26184_1349003712_506829C0_26184_9758_1_tTKzDPgZM1TV@TJw0VVKN> <50684D98.8010400@cs.tcd.ie>
In-Reply-To: <50684D98.8010400@cs.tcd.ie>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, Stefan.Schroeder06@telekom.de, dime@ietf.org, turners@ieca.com
Subject: Re: [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: Mon, 01 Oct 2012 08:12:57 -0000

Hello all
if I understood Lionel correctly he proposes and I would clearly support that
 "you MUST NOT send messages with "e2e-sensitive" AVPs without e2e security"

Best regards Dieter 



-----Ursprüngliche Nachricht-----
Von: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] 
Gesendet: Sonntag, 30. September 2012 15:48
An: lionel.morand@orange.com
Cc: Glen Zorn; Jacobsohn, Dieter; dime@ietf.org; draft-ietf-dime-rfc3588bis@tools.ietf.org; turners@ieca.com; Schröder, Stefan
Betreff: Re: RE : Re: AW: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis


Just checking I've got this right. The plan now is to say you MUST NOT send "e2e-sensitive" AVPs without e2e security and to have a list of currently known e2e-sensitive AVPs in 3588bis. If so, that seems like a good thing to me.

Maybe consider an IANA registry listing the e2e-sensitive AVPs that could be updated via expert review for when the current list gets outdated? Could be done later if needed though, so just a suggestion.

S.

On 09/30/2012 12:15 PM, lionel.morand@orange.com wrote:
> 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..."
> 
> Regards,
> 
> Lionel
> -----Message d'origine-----
> De : Glen Zorn
> Envoyé :  29/09/2012, 14:33
> À : MORAND Lionel RD-CORE
> 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
>     document.
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> 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.
>