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

Glen Zorn <glenzorn@gmail.com> Sat, 26 January 2013 12:51 UTC

Return-Path: <glenzorn@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0611B21F871D; Sat, 26 Jan 2013 04:51:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxsvfQ-1exK0; Sat, 26 Jan 2013 04:50:59 -0800 (PST)
Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id 27DE621F8718; Sat, 26 Jan 2013 04:50:59 -0800 (PST)
Received: by mail-pb0-f42.google.com with SMTP id rp2so685647pbb.15 for <multiple recipients>; Sat, 26 Jan 2013 04:50:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pOKAK6Dnb2zQaFMyOSwQJpZzA23hny7yngWb/+NO5eA=; b=VAX78SGn4b8Z5Cjrbq0shzkgrSrWekC1jjJSLieCY30OkgQVOGVBacqjVgJWWI6jRl Xhp8dZswkqK6fjNwm3CbDqEhxfJPtmXdT0ZFi+x72TBMSXWhL65S0c0OXA1eWQHhoEqY 6s1m1gBQRJvpno68GkZcb8v+q9o2mb390Yg8JDsPNt+voPSBrTqUr25CnXfpcwodJoS6 q9f58n1oKVFUG/X8RSXn2uOWG186Ex/FYxugLsXS0B9oVHwlFMg+Cmf0ET0nFl8MbIaC NCmyvZBqK68ZoMLOzXCxcIIs3ojpK0dKcX2rdFqs1x8j3bYu1aIWlXQAcYXPutGD7Nby jfWQ==
X-Received: by 10.68.242.225 with SMTP id wt1mr21989465pbc.65.1359204658907; Sat, 26 Jan 2013 04:50:58 -0800 (PST)
Received: from [192.168.0.102] (ppp-124-120-221-204.revip2.asianet.co.th. [124.120.221.204]) by mx.google.com with ESMTPS id uh9sm2538439pbc.65.2013.01.26.04.50.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Jan 2013 04:50:57 -0800 (PST)
Message-ID: <5103D12D.8060906@gmail.com>
Date: Sat, 26 Jan 2013 19:50:53 +0700
From: Glen Zorn <glenzorn@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>
References: <939DADEE-28DB-4A4B-AD0D-057AEB863250@inria.fr> <50FF9D1C.9070501@cisco.com>
In-Reply-To: <50FF9D1C.9070501@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IESG IESG <iesg@ietf.org>, draft-ietf-dime-erp.all@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-dime-erp-16
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Jan 2013 12:51:00 -0000

On 01/23/2013 03:19 PM, Benoit Claise wrote:
> Dear draft-ietf-dime-erp authors,
>
> 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.

>
> Regards, Benoit
>> 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
>>
>>
>> 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!
>>
>> 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
>>> secdir@ietf.org
>>> https://www.ietf.org/mailman/listinfo/secdir
>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>
>