Re: [Dime] I-D Action: draft-ietf-dime-e2e-sec-req-02.txt
"Ben Campbell" <ben@nostrum.com> Wed, 01 April 2015 22:57 UTC
Return-Path: <ben@nostrum.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944161A92F8 for <dime@ietfa.amsl.com>; Wed, 1 Apr 2015 15:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level:
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_56=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SrQXVAabouc for <dime@ietfa.amsl.com>; Wed, 1 Apr 2015 15:57:44 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC2921A1A45 for <dime@ietf.org>; Wed, 1 Apr 2015 15:57:43 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t31MvVgF063182 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2015 17:57:41 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
From: Ben Campbell <ben@nostrum.com>
To: Steve Donovan <srdonovan@usdonovans.com>
Date: Wed, 01 Apr 2015 17:57:30 -0500
Message-ID: <84E3B758-DD12-4BC1-A124-5E60C5813841@nostrum.com>
In-Reply-To: <551C3AEB.3030008@usdonovans.com>
References: <20150126150303.15610.1562.idtracker@ietfa.amsl.com> <5511D1AA.40804@usdonovans.com> <55138C07.2070007@gmail.com> <5515AAF0.8020502@usdonovans.com> <40F74E87-BC08-4822-A29E-3D2BE026BF6C@gmail.com> <551B3E18.1020907@usdonovans.com> <551B7D90.7040109@gmail.com> <551C3AEB.3030008@usdonovans.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.1r5083)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/Ws7AldGX1POoynE2MPlg3fFpUl8>
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] I-D Action: draft-ietf-dime-e2e-sec-req-02.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 01 Apr 2015 22:57:45 -0000
Is "in the clear" the real requirement? I suggest "visible to Diameter agents that need to act on them." Sending them in clear-text would be one way to accomplish that, but there might be others. /Ben On 1 Apr 2015, at 13:37, Steve Donovan wrote: > Jouni, > > I agree with your points on integrity protection. My concern is > encryption of headers used in making routing decisions. > > Steve > > On 4/1/15 12:09 AM, Jouni Korhonen wrote: >> Steve, >> >> Inline. >> >> 3/31/2015, 5:38 PM, Steve Donovan kirjoitti: >>> inline >>> >>> On 3/27/15 4:40 PM, Jouni.nosmap wrote: >>>> Hi Steve, >>>> >>>> Inline.. >>>> >>>> Sent from a smart phone.. Mind the typos.. >>>> >>>>> Steve Donovan <srdonovan@usdonovans.com> kirjoitti 27.3.2015 kello >>>>> 14.09: >>>>> >>>>> >>>>> >>>>>> On 3/25/15 11:33 PM, Jouni Korhonen wrote: >>>>>> Steve, >>>>>> >>>>>> See inline.. >>>>>> >>>>>> 3/24/2015, 2:05 PM, Steve Donovan kirjoitti: >>>>>>> A few comments on this document. >>>>>>> >>>>>>> I would suggest adding the following requirement -- The solution >>>>>>> MUST >>>>>>> ensure that routing AVPs are always sent in the clear. >>>>>> By routing AVPs you refer to Router-Record and Proxy-Info as per >>>>>> RFC6733, right? In that case I do not see a reason for the "are >>>>>> always sent in the clear". >>>>> SRD> No, I mean Destination-Host, Destination-Realm, Origin-Host >>>>> and >>>>> Origin-Realm. >>>> Ok. Makes sense. However, integrity protecting above AVP should >>>> still >>>> be fine and allowed. At least the Origin-* AVPs. >>> SRD2> Origin-Host and Origin-Realm are also used for making routing >>> decisions. What is the value in integrity protecting these AVPs? >>> Any >>> agent based scenario would require that all agents in the path be >>> able >>> to decrypt the AVPs to make routing decisions. Why isn't it better >>> to >>> just say that these AVPs MUST NOT be integrity protected? >> >> Integrity protection does not hide the content from intermediates. It >> only makes the end points to detect if those AVPs have been altered. >> I do want to know if someone tampered my AVPs that I care about (what >> those AVPs are depends on the policy). >> >>>> >>>>>>> Requirement 5 does indicate that not all AVPs are covered by the >>>>>>> " >>>>>>> cryptographic protection". I think it would be better to be >>>>>>> clear >>>>>>> that >>>>>>> there is a set of AVPs that MUST NOT be encrypted. >>>>>> OK. >>>>>> >>>>>>> In addition, the following requirement might be useful -- The >>>>>>> solution >>>>>>> MUST support the ability to identify other non routing AVPs that >>>>>>> must >>>>>>> always be sent in the clear. >>>>>> I would assume the knowledge which AVPs are ciphered is up to a >>>>>> local policy. If the policy is wrong, the receiver or >>>>>> intermediates >>>>>> will reply with an error. >>>>> SRD> That makes sense. My reason for bringing this up is to make >>>>> sure that the solution allows for these AVPs being sent in the >>>>> clear. It won't work to arbitrarily encrypt all AVPs or even >>>>> chunks >>>>> of AVPs. >>>> That was never the intention. We better clarify it if the text was >>>> not >>>> clear about that... Or there was no such text at all. >>> SRD2> The text does say that a subset of the AVPs can be integrity >>> protected. I'm suggesting that we need wording that any solution >>> MUST >>> NOT assume/require integrity protecting the entire message. >> >> That is OK. >> >> - Jouni >> >> >>>> >>>> - jouni >>>> >>>> >>>>>> - Jouni >>>>>> >>>>>>> This would be to cover overload, load, message priority and >>>>>>> other AVPs >>>>>>> that need to be accessible by all nodes in the path of a >>>>>>> transaction. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>>> On 1/26/15 9:03 AM, internet-drafts@ietf.org wrote: >>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>> Internet-Drafts >>>>>>>> directories. >>>>>>>> This draft is a work item of the Diameter Maintenance and >>>>>>>> Extensions Working Group of the IETF. >>>>>>>> >>>>>>>> Title : Diameter AVP Level Security End-to-End >>>>>>>> Security: Scenarios and Requirements >>>>>>>> Authors : Hannes Tschofenig >>>>>>>> Jouni Korhonen >>>>>>>> Glen Zorn >>>>>>>> Kervin Pillay >>>>>>>> Filename : draft-ietf-dime-e2e-sec-req-02.txt >>>>>>>> Pages : 9 >>>>>>>> Date : 2015-01-26 >>>>>>>> >>>>>>>> Abstract: >>>>>>>> This specification discusses requirements for providing >>>>>>>> Diameter >>>>>>>> security at the level of individual Attribute Value Pairs. >>>>>>>> >>>>>>>> >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-e2e-sec-req/ >>>>>>>> >>>>>>>> There's also a htmlized version available at: >>>>>>>> http://tools.ietf.org/html/draft-ietf-dime-e2e-sec-req-02 >>>>>>>> >>>>>>>> A diff from the previous version is available at: >>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-e2e-sec-req-02 >>>>>>>> >>>>>>>> >>>>>>>> Please note that it may take a couple of minutes from the time >>>>>>>> of >>>>>>>> submission >>>>>>>> until the htmlized version and diff are available at >>>>>>>> tools.ietf.org. >>>>>>>> >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> DiME mailing list >>>>>>>> DiME@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>> >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime
- Re: [Dime] I-D Action: draft-ietf-dime-e2e-sec-re… Steve Donovan
- Re: [Dime] I-D Action: draft-ietf-dime-e2e-sec-re… Jouni Korhonen
- Re: [Dime] I-D Action: draft-ietf-dime-e2e-sec-re… Steve Donovan
- Re: [Dime] I-D Action: draft-ietf-dime-e2e-sec-re… Jouni.nosmap
- Re: [Dime] I-D Action: draft-ietf-dime-e2e-sec-re… Steve Donovan
- Re: [Dime] I-D Action: draft-ietf-dime-e2e-sec-re… Jouni Korhonen
- Re: [Dime] I-D Action: draft-ietf-dime-e2e-sec-re… Steve Donovan
- Re: [Dime] I-D Action: draft-ietf-dime-e2e-sec-re… Ben Campbell
- [Dime] I-D Action: draft-ietf-dime-e2e-sec-req-02… internet-drafts