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

Glen Zorn <> Sat, 29 September 2012 12:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6402A21F848B for <>; Sat, 29 Sep 2012 05:33:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OaMzjPDNYBjO for <>; Sat, 29 Sep 2012 05:33:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BCA3521F8467 for <>; Sat, 29 Sep 2012 05:33:36 -0700 (PDT)
Received: by pbbro8 with SMTP id ro8so6243010pbb.31 for <>; Sat, 29 Sep 2012 05:33:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=aQXoY77d+M2TTSoOvPtxUQQ7+CHiXt9cC2B9Fttk5YA=; b=iIKX9yFMH8xBNIkEYTrgegjh5FgTDpssSexhX3dsbnAfeCPLbgPLn+ZBXQcFyKhGBX CtBNZqR0INzr/awbtps7oxS/UBIlWh08ZH6NOMB1A5DAI/yyDWYxyKSa3Cwnlkt6K09x /Q2LqwsiI1v23w9LN/H3YWm2CFGy7zEWXTi0SFYGewq+tRmVacouK69ew9A5/QV3cKK8 vE/wJaZ3bED8zDeOmRsohVKboIM3wp02CxWnoEpK84UrEutGCsQvXclJP1T5BaGX/WA8 y3Mo4TGUqApK30PzSlUngupSv23bM9o9XOHb8tOCvn4McmZfJBhGcGDjkJl2nWBk5ucB X1rg==
Received: by with SMTP id mm8mr27527454pbc.146.1348922015465; Sat, 29 Sep 2012 05:33:35 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id my10sm6976184pbc.11.2012. (version=SSLv3 cipher=OTHER); Sat, 29 Sep 2012 05:33:34 -0700 (PDT)
Message-ID: <>
Date: Sat, 29 Sep 2012 19:33:29 +0700
From: Glen Zorn <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120914 Thunderbird/15.0.1
MIME-Version: 1.0
References: <> <27169_1348684002_506348E2_27169_14408_1_6B7134B31289DC4FAF731D844122B36E074A1A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <> <> <> <20096_1348913297_5066C891_20096_2169_1_6B7134B31289DC4FAF731D844122B36E0758C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <> <19603_1348915144_5066CFC8_19603_1305_1_6B7134B31289DC4FAF731D844122B36E0758E2@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <19603_1348915144_5066CFC8_19603_1305_1_6B7134B31289DC4FAF731D844122B36E0758E2@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>, "" <>, "" <>, "" <>, "" <>
Subject: Re: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 29 Sep 2012 12:33:37 -0000

On 09/29/2012 05:39 PM, 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