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

Glen Zorn <glenzorn@gmail.com> Thu, 27 September 2012 03:58 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 C52D021F85A3 for <dime@ietfa.amsl.com>; Wed, 26 Sep 2012 20:58:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.435
X-Spam-Level:
X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 cfjtZxrHQ1Wt for <dime@ietfa.amsl.com>; Wed, 26 Sep 2012 20:58:00 -0700 (PDT)
Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13E9921F859E for <dime@ietf.org>; Wed, 26 Sep 2012 20:58:00 -0700 (PDT)
Received: by padfb11 with SMTP id fb11so991109pad.31 for <dime@ietf.org>; Wed, 26 Sep 2012 20:57:59 -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=PA4NSvztjpbxUHzdeDPbcjlpBEyeXqrb7B4myurke9E=; b=d4OF+oGgmBSPETgrJAyB5ixboTsKULprjhc/gntQRuSWqxnceL385JuN8H5ewMl8Si 8XPQH3lSs2X/wxDrn83Jcf3UKRDrSSgUQggJ6/f5oEdRywUOO2hlg6FJjDGULwFE/8XW oM+VFcYTnBlND6s3AHnhHQUvlu7WUlldvDY24yI12/lA5LEuLEMQ/ZHf38gp1vAgKxlj XwKaDcDMw2RBt3jtJtGHrRvpXnw9ff2naHlytIkg66aoXstcGe+wzrZAIWUM5j6GaQST pqpsauXkg4bAW7KR5WhKBdsaHiULEHzKzdjGcrMfm0PUQMeWCKoguDhJIEgMRWA3alcW jgOQ==
Received: by 10.66.83.234 with SMTP id t10mr6236838pay.39.1348718279742; Wed, 26 Sep 2012 20:57:59 -0700 (PDT)
Received: from [192.168.0.102] (ppp-124-120-218-82.revip2.asianet.co.th. [124.120.218.82]) by mx.google.com with ESMTPS id nv2sm1982490pbc.44.2012.09.26.20.57.56 (version=SSLv3 cipher=OTHER); Wed, 26 Sep 2012 20:57:58 -0700 (PDT)
Message-ID: <5063CEC3.9080305@gmail.com>
Date: Thu, 27 Sep 2012 10:57:55 +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>
In-Reply-To: <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: draft-ietf-dime-rfc3588bis <draft-ietf-dime-rfc3588bis@tools.ietf.org>, dime mailing list <dime@ietf.org>, turners <turners@ieca.com>, Stephen Farrell <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: Thu, 27 Sep 2012 03:58:00 -0000

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