Subject: [secdir] Secdir review of draft-ietf-dime-erp-16

From: Vincent Roca <[email-masked]>
Date: Wed, 23 Jan 2013 08:59:29 +0100

Hello,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

--

Since the security section has not really been updated since version 14, the comments I made at
that time are still valid. Basically:

The security section of this document only refers to the security section of 4 related documents.
This is all the more annoying as draft-ietf-dime-erp introduces new mechanisms (and potentially
new threats and issues). What should I understand? Is the proposal guaranteed to be secure, have
all the potential weaknesses been already addressed in the 4 related documents? I can not
conclude after reading the security section.

One more point. In introduction, the authors say:
"  Security considerations for this key distribution are detailed in Salowey, et al. [RFC5295]."
This reference is not mentioned in the Security Section!

Cheers,

    Vincent

---

From: Benoit Claise <[email-masked]>
Date: Wed, 23 Jan 2013 09:19:40 +0100

Dear draft-ietf-dime-erp authors,

Please address the concerns below.

Regards, Benoit

---

From: Glen Zorn <[email-masked]>
Date: Sat, 26 Jan 2013 19:50:53 +0700

> Please address the concerns below.

I responded to Vincent's original review some time ago (see below); I am 
interested in hearing my co-authors' opinion.

>> On 11/05/2012 04:55 AM, Vincent Roca wrote:
>>
>>> Hello,
>>>
>> Thank you for taking the time to review the draft.
>>
>>>
>>> -- 
>>>
>>> The security section of this document is pretty simple as it refers to
>>> the security section of 4 related documents and that's all. On the
>>> opposite, each of these 4 documents includes a very detailed security
>>> analysis.  The contrast is extremely important!
>>
>> Why?
>>
>>>
>>> This is all the more annoying as draft-ietf-dime-erp-14 introduces new
>>> mechanisms, and thereby new potential threats and issues (it's usually
>>> the case).
>>
>> From a Diameter POV, a Diameter ERP "server" is actually just a form 
>> of Diameter agent and the Diameter ERP client is just a standard 
>> Diameter client; a new application is only required to ensure the 
>> correct routing of Diameter messages.  So I'm not sure what the new 
>> mechanisms you refer to are; perhaps you can elucidate?
>>
>>>
>>> What should I understand? Is the proposal guaranteed to be secure?
>>
>> There are no guarantees in life, let alone security .
>>
>>> Or have all the potential weaknesses been already addressed in the
>>> 4 related documents?
>>
>> It would seem that that is the very strong implication.
>>
>>> I can not conclude after reading this security section
>>> and this is a problem.
>>
>> It seems as if the big problem is that the draft doesn't tell you 
>> what to think about the security properties of the protocol but I 
>> don't think that is really a problem with the document.  As I 
>> mentioned above, it appears to me that the authors believe that 
>> security-related issues are dealt with in the Security Considerations 
>> sections of RFCs 4072, 6696, 6733 and 6734.  Is that the case?  If 
>> not, please point out a security problem with this protocol that is 
>> not covered by those texts.
>>
>>>
>>> So, I'd like that the authors clarify this, and if need be, I'd like 
>>> the authors
>>> explicitly mention which items in each of the 4 related documents 
>>> apply.
>>> It would be helpful IMHO.
>>
>> Only if you believe our conclusions .
>>
>>>
>>>
>>> Cheers,
>>>
>>>    Vincent
>>>
>>>
>>> _______________________________________________
>>> secdir mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/secdir
>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>
>

---

From: Vincent Roca <[email-masked]>
Date: Mon, 28 Jan 2013 14:57:08 +0100

Hi Glen and others,

> I responded to Vincent's original review some time ago (see below); I am interested in hearing my co-authors' opinion.

Oups, I've just found it. Sorry. So let me answer.

[...]
>>> This reference is not mentioned in the Security Section!

I  don't think you've answered here.

[...]
>>> From a Diameter POV, a Diameter ERP "server" is actually just a form of Diameter agent and the Diameter ERP client is just a standard Diameter client; a new application is only required to ensure the correct routing of Diameter messages.  So I'm not sure what the new mechanisms you refer to are; perhaps you can elucidate?

I'm not an expert and didn't hear about ERP before this. I must admit I
have no clue on how all these things work, and I cannot judge whether
there are security issues or not.

But when I read the abstract, I understand that a certain number of
things are introduced: 
	- extensions to EAP, 
	- a new Diameter ERP application,
	- a set of new AVPs.
This is what I mean by "new mechanisms". 
If you say that it's more a  specialization of existing components (if I understand
correctly) than new mechanisms, then I believe you.

>>> It seems as if the big problem is that the draft doesn't tell you what to think about the security properties of the protocol but I don't think that is really a problem with the document.  As I mentioned above, it appears to me that the authors believe that security-related issues are dealt with in the Security Considerations sections of RFCs 4072, 6696, 6733 and 6734.  Is that the case?  If not, please point out a security problem with this protocol that is not covered by those texts.

You got my point. 

You introduce new things (I called them mechanisms, but it's perhaps 
inappropriate) without telling me **explicitly** whether or not you believe
they introduce new risks. And it's not obvious to me whether the security
sections of these 4 RFCs also encompass the new things introduced here.

If you add a sentence saying that the authors believe that all security aspects
are already dealt with the above 4 RFCs, plus another sentence explaining why
you believe so, then I'll be happy. That's the kind of things to discuss in a security
section.

Does it make sense? In any case, I don't want to annoy anybody. I'm just trying
to provide a complementary view.

Cheers,

   Vincent