Re: [Dime] RE : Re: AW: unexpected consequence of deprecating E2E security in RFC 3588 bis
Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 30 September 2012 13:48 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
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 B5F1621F84A6 for <dime@ietfa.amsl.com>; Sun, 30 Sep 2012 06:48:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.537
X-Spam-Level:
X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 bx25zuP5UVjk for <dime@ietfa.amsl.com>; Sun, 30 Sep 2012 06:48:16 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A159621F847F for <dime@ietf.org>; Sun, 30 Sep 2012 06:48:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 141311714A7; Sun, 30 Sep 2012 14:48:16 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1349012895; bh=kE3L99iBfP4RbP HneYYXzan4mmkALBnNmBdLuvBghOM=; b=oO/juYs/r7oUyZYsZ9p2VPW5gQkKF8 aTc/s6BPeXCE3hC3IzZwyRPf7g7bN0BHZ5LNRpcnAypu+Dh7alcxPr3fToLM71ri z3ckc4pfA6fwFnPmX3Bwimdx+pn99/V/NhGV8lQgJDJIiM+4iqWZWtruSqu+IqfU zl6D9OJTH6flz+Mxgtm4Pm0LlxA999JAoRwMt/KdqZKlpOD1yeFYjjL9uMEwPxME 0s6KLwzOH1ugzy5gYbOogfha13qNha4Djvk7J+33rkVmXC81j2k096HLsGNG56uZ ohZNMFULetkAkB7UBUkUMjjFYnLmfaaLEer5SfxeBBwPeZSAco7LqX2Q==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 1Hnvc5VZXeHz; Sun, 30 Sep 2012 14:48:15 +0100 (IST)
Received: from [10.87.48.7] (unknown [86.41.14.47]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0D6241714A6; Sun, 30 Sep 2012 14:48:09 +0100 (IST)
Message-ID: <50684D98.8010400@cs.tcd.ie>
Date: Sun, 30 Sep 2012 14:48:08 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: lionel.morand@orange.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>
In-Reply-To: <26184_1349003712_506829C0_26184_9758_1_tTKzDPgZM1TV@TJw0VVKN>
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
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>
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: Sun, 30 Sep 2012 13:48:17 -0000
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. >
- [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