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

Glen Zorn <glenzorn@gmail.com> Sat, 29 September 2012 10:20 UTC

Return-Path: <glenzorn@gmail.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 1A16021F853D for <dime@ietfa.amsl.com>; Sat, 29 Sep 2012 03:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 OLwmvMfvASPl for <dime@ietfa.amsl.com>; Sat, 29 Sep 2012 03:19:58 -0700 (PDT)
Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id A348D21F8522 for <dime@ietf.org>; Sat, 29 Sep 2012 03:19:58 -0700 (PDT)
Received: by danh15 with SMTP id h15so933773dan.31 for <dime@ietf.org>; Sat, 29 Sep 2012 03:19:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=l3F3OPKBgdwUXmuJJAlTBN/jNcQSbyZyss2QYD1KnlE=; b=tuZNW2gBa98n5464pENTnc9yOxAGVXG7GopEEiQAalyBYTZ7ujqRVySucVATi1+MzB yVZyV/0zrSfMSw9BtslPOtpDhIs2kW2Bf/O4lTUe99vXn1whq3yYqrJSgCMl25WlT52+ uOp1laT5WIEfUCaTvXgGt85ew7LxmO4gKqEdhaqybAWOp4AmhMUufgvYOoqB38z/FDJA j/H8/7WAyGZRVbi4oerY5crsyFfSEIf1dFDEyy8yzYOXCbz6pwLhoM0HfcI9ZQGq7W4W AIub47bbL9udpD3e5NNN7RZgOJfrF8O5ICb6GfmiXJ7yyLy/2F5LRghWuEkJovH9iNRb CJEg==
Received: by 10.68.195.226 with SMTP id ih2mr27640347pbc.9.1348913997466; Sat, 29 Sep 2012 03:19:57 -0700 (PDT)
Received: from [192.168.0.102] (ppp-124-121-208-251.revip2.asianet.co.th. [124.121.208.251]) by mx.google.com with ESMTPS id ka4sm7034331pbc.61.2012.09.29.03.19.53 (version=SSLv3 cipher=OTHER); Sat, 29 Sep 2012 03:19:56 -0700 (PDT)
Message-ID: <5066CB47.1070807@gmail.com>
Date: Sat, 29 Sep 2012 17:19:51 +0700
From: Glen Zorn <glenzorn@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120914 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>
In-Reply-To: <20096_1348913297_5066C891_20096_2169_1_6B7134B31289DC4FAF731D844122B36E0758C4@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>, "stephen.farrell@cs.tcd.ie" <stephen.farrell@cs.tcd.ie>
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: Sat, 29 Sep 2012 10:20:00 -0000

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

> Hi Glen,
 >
 > I'm OK with the "MUST NOT... unless" approach that is stronger than
 > "SHOULD NOT... unless". The last part could be slightly modified as
 > follow:
 >
 > 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 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.
 >
 > The "may not be required" indicates that it is a design option and
 > the default rule is "E2E security is required for those AVPs".

This is fine.  I noticed that another important piece of data was lost 
in the shuffle, as well: in RFC 3588, the AVPs considered to contain 
security-sensitive data were marked as such in the AVP tables, but in 
the revision they're not.  This makes the MUST NOT above pretty close to 
useless.  I think that we probably need to list those AVPs in this 
section, as well.

>
 > Regards,
 >
 > Lionel
 >
 > -----Message d'origine----- De : Glen Zorn
 > [mailto:glenzorn@gmail.com] Envoyé : jeudi 27 septembre 2012 13:04 À
 > : dieter.jacobsohn@telekom.de Cc : glenzorn@gmail.com; MORAND Lionel
 > RD-CORE; 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/27/2012 05:01 PM, dieter.jacobsohn@telekom.de wrote:
 >>
 >> Hello Glen After discussing it also with some security people I
 >> think that the existing text is more accurate and should stay. The
 >> existing text refers to "intermediary is known to be operated as
 >> part of the same administrative domain as the endpoints", which is
 >> fine.
 >
 > The current text assumes that exactly the same security measures are
 > applied to the endpoints and any intermediates. I think that this
 > assumption is basically groundless.
 >
 >> We don't have end-to-end security in 3588bis, true. But 13.3
 >> offers exactly this party1-to-party2 security as almost equivalent
 >> to e2e security.
 >
 > AFAICT, it offers the assertion that "Our network is secure." and
 > basically nothing else.
 >
 >>
 >> The new proposed text would allow other alternatives beyond that,
 >> based on "locally trusted configuration". But what does that mean
 >> in practice? I think such a statement would allow just anything and
 >> move away from any tangible technical security.
 >
 > Unless bare assertions constitute technical security, it doesn't move
 > away from anything. Be that as it may, the current text says "In
 > addition, those messages SHOULD NOT be sent via intermediate nodes
 > that would expose the sensitive data at those nodes". As I
 > understand it, "SHOULD NOT" means "don't do it unless you have a good
 > reason to", but the definition of "good reason" is pretty much up in
 > the air. Is the simple assertion of security a "good reason"?
 > Sounds like it. By contrast, RFC 3588 says that messages containing
 > sensitive AVPs MUST NOT be sent through untrusted intermediaries;
 > that is the part I want to see remain. Admittedly, it's a small
 > thing, but it's something; I'm sure that people are going to do
 > whatever they like anyway, but at least they might stop and think a
 > bit more when they see a MUST. "Blindly trust every host in this
 > domain because I say so" could still be the policy, but it would need
 > to be configured as such (which I suspect is actually the issue
 > here).
 >
 >>
 >> Best Regards Dieter Jacobsohn
 >>
 >>
 >> Deutsche Telekom AG Group Technology Dieter Jacobsohn
 >> Landgrabenweg 151, 53227 Bonn +49 228 936-18445 (Tel.) +49 391 5801
 >> 46624 (Fax) +49 171 2088 710 (Mobil) E-Mail:
 >> dieter.jacobsohn@telekom.de www.telekom.com
 >>
 >> Erleben, was verbindet.
 >>
 >> Deutsche Telekom AG Aufsichtsrat: Prof. Dr. Ulrich Lehner
 >> (Vorsitzender) Vorstand: René Obermann (Vorsitzender), Dr. Manfred
 >> Balz, Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges,
 >> Claudia Nemat, Prof. Dr. Marion Schick Handelsregister:
 >> Amtsgericht Bonn HRB 6794 Sitz der Gesellschaft Bonn USt-IdNr. DE
 >> 123475223
 >>
 >> Große Veränderungen fangen klein an - Ressourcen schonen und nicht
 >> jede E-Mail drucken.
 >>
 >>
 >> -----Ursprüngliche Nachricht----- Von: dime-bounces@ietf.org
 >> [mailto:dime-bounces@ietf.org] Im Auftrag von Glen Zorn Gesendet:
 >> Donnerstag, 27. September 2012 05:58 An: lionel.morand@orange.com
 >> Cc: draft-ietf-dime-rfc3588bis; dime mailing list; turners;
 >> Stephen Farrell Betreff: Re: [Dime] unexpected consequence of
 >> deprecating E2E security in RFC 3588 bis
 >>
 >> On 09/27/2012 01:26 AM, lionel.morand@orange.com wrote:
 >>
 >> Copying the Security ADs.
 >>
 >>> 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"?
 >>
 >> I think that something should be done since as it stands the
 >> language is weaker in bis than in RFC 3588; the protocol is
 >> actually less secure :-(. I would suggest changing Section 13.3
 >> (quoted above) to say some thing like this:
 >>
 >> 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 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, 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). Note, however, that no end-to-end security mechanism is
 >> specified in this document.
 >>
 >> However, I don't really want to delay publication any more than I
 >> already have ;-), so if that change would trigger a whole new IESG
 >> review (or worse, another IETF LC) I would rather handle it in an
 >> erratum later.
 >>
 >>>
 >>>
 >>> 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 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.
 >