Subject: Re: [Dime] I-D Action: draft-ietf-dime-e2e-sec-req-02.txt

From: Steve Donovan <[email-masked]>
Date: Wed, 01 Apr 2015 13:37:31 -0500

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 <[email-masked]> 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, [email-masked] 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
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> DiME mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>
>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 01 Apr 2015 17:57:30 -0500

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:

>> 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 
>>>>>>> This would be to cover overload, load, message priority and 
>>>>>>> other AVPs