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