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

[Vincent Roca <[e-mail]>]

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.

[...]
>>> 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!

I  don't think you've answered here.


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

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.


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

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