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.
>