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

Glen Zorn <> Mon, 10 December 2012 08:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3240121F8F88; Mon, 10 Dec 2012 00:07:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.382
X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WuNB-wsegq7E; Mon, 10 Dec 2012 00:07:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 88B2F21F8F87; Mon, 10 Dec 2012 00:07:53 -0800 (PST)
Received: by with SMTP id uo1so1640250pbc.31 for <multiple recipients>; Mon, 10 Dec 2012 00:07:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VNesiRZqKRoJQQ4L6GZGgzulnRBQi2xcSIZOxy4CAg0=; b=R0IS+iBdlUvQ5EcRl1vh61SJHECpoYnJI1hFXUE6FNcesTHUksStTo49Zi6Nn6EzWi we+Dd6TmdiF4sXIaNf+Tiy0fE/kDKBpoIYBVTbg1+V66FR3OMn/ItqY0hD4OCN81MuPm iwGN5bmJ6UCwu7J81ePyd3PBI8kkhIzfIInNuRqHbtWHcmCbrrnyyjvponP+vcWqaO9+ td+C2HSH05nSuuu1ycX8U0DknPEfg9HQAOOIUl+HZh2PJfFImo8mMsl1+hYiIFfQV688 NU9ZOXNTmx8QIZTUtxsiWsuc8Xg6FSG3T5xZOdYVgtYpSI/IzmX2DgDBUBODh0xirHeT imJQ==
Received: by with SMTP id w5mr33906876pax.81.1355126873244; Mon, 10 Dec 2012 00:07:53 -0800 (PST)
Received: from [] ( []) by with ESMTPS id ug6sm11455088pbc.4.2012. (version=SSLv3 cipher=OTHER); Mon, 10 Dec 2012 00:07:52 -0800 (PST)
Message-ID: <>
Date: Mon, 10 Dec 2012 15:07:46 +0700
From: Glen Zorn <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2
MIME-Version: 1.0
To: Vincent Roca <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IESG IESG <>,,
Subject: Re: [secdir] Secdir review of draft-ietf-dime-erp-14
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Dec 2012 08:07:54 -0000

On 11/05/2012 04:55 AM, Vincent Roca wrote:

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

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!


> 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
> wiki: