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

From: Steve Donovan <[email-masked]>
Date: Tue, 24 Mar 2015 16:05:46 -0500

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.

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.

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.

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
>

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 25 Mar 2015 21:33:11 -0700

Steve,

See inline..

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

> there is a set of AVPs that MUST NOT be encrypted.

OK.

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

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Fri, 27 Mar 2015 14:09:36 -0500

> RFC6733, right? In that case I do not see a reason for the "are always 
SRD> No, I mean Destination-Host, Destination-Realm, Origin-Host and 
Origin-Realm.
> 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.

---

From: "Jouni.nosmap" <[email-masked]>
Date: Fri, 27 Mar 2015 16:40:21 -0500

Hi Steve,

Inline..

Sent from a smart phone.. Mind the typos..

> Steve Donovan <[email-masked]> kirjoitti 27.3.2015 kello 14.09:
> 
> 
> 
>> 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. 

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

- jouni

---

From: Steve Donovan <[email-masked]>
Date: Tue, 31 Mar 2015 19:38:48 -0500

inline

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

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 31 Mar 2015 22:09:36 -0700

Steve,

Inline.

3/31/2015, 5:38 PM, Steve Donovan kirjoitti:
>>>> RFC6733, right? In that case I do not see a reason for the "are
>>>> always sent in the clear".
>> Ok. Makes sense. However, integrity protecting above AVP should still
>> be fine and allowed. At least the Origin-* AVPs.

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

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

That is OK.

- Jouni