Re: [Dime] Ben Campbell's No Objection on draft-ietf-dime-e2e-sec-req-04: (with COMMENT)

Jouni Korhonen <jouni.nospam@gmail.com> Wed, 01 June 2016 18:14 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EFB12D5FB; Wed, 1 Jun 2016 11:14:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPBj64tzaykM; Wed, 1 Jun 2016 11:14:38 -0700 (PDT)
Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F063B12D1AF; Wed, 1 Jun 2016 11:14:37 -0700 (PDT)
Received: by mail-pf0-x243.google.com with SMTP id b124so4822538pfb.0; Wed, 01 Jun 2016 11:14:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=bUVEwjdkSU2W0onAdljP9w4DtthsPOY+GPE/0AofYB8=; b=NzC/ArArIOFXJ9hNfFW77mo8S2qqsMkU+L+O5YJaMHrbFtw6jttIFaZrop1M/OSyP5 ARvKNf4dcAcw8mMd0CcWG3mtqDobwo9KRi8lH0e4CkvDs6P2l2pAbzyH9fsAhO4Ynl2y 74IezEhmLzgwZZDZpEPR9KrOBVUYPKUpzkGn5AXumc1mFG9caThwec7xMChad+6YIQOO 6RL6JIiOZjTwPYyzvGoc2yTnGmkTDnXPVMmkRDxQs7hjtSB2O+6mkad6xpU+8fJFaWCF G88k2zvTfTowu6bkm9cAcfK9xNKM1Lj3oCY0OI0O6QZttq2usnI4ju/mMSps7aSlZjrQ SxHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=bUVEwjdkSU2W0onAdljP9w4DtthsPOY+GPE/0AofYB8=; b=WdjZHA0wQynrTXxEY+RjQB4Z61NVOywbQTHkcVCtJ8k107W5PGwCUOucHIdNtcJySG Z4T0Ifahrh/1AEXGW8hvrFxcJHFKwzo1yyUxmFe8X+f6L+j0zFV+hPhprJUz1ALhpjG/ MAxpXlYZ/sd8mEPFkXzjEdYg0/WQgfaNSlZtZk8bbotamvmm+POQxZMTqxEWWiDTlsAG 44H0Ver1SRYQ3DXr2kZCaAbwRJaxTpl5W/mBcKZ+JDPVLB62ruVhE3SKWCiMmoavwGqq eje+0kWX9brBsak6Ru3+dbmQlfLS+9NBAb0T5Kxf7KVLJP+Ue03+PX4ywe2BWo1pUINB W4sQ==
X-Gm-Message-State: ALyK8tINL3MxY7uARZeFWxqzn4symwZRzDFGRljFhgvH7QdrhW4dxTDu8ZBSDjsVWnQJ1A==
X-Received: by 10.98.64.21 with SMTP id n21mr11204747pfa.161.1464804877388; Wed, 01 Jun 2016 11:14:37 -0700 (PDT)
Received: from [10.16.65.15] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id bm8sm34158144pad.10.2016.06.01.11.14.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 11:14:36 -0700 (PDT)
References: <20160601152314.16196.25416.idtracker@ietfa.amsl.com>
To: Ben Campbell <ben@nostrum.com>, The IESG <iesg@ietf.org>
From: Jouni Korhonen <jouni.nospam@gmail.com>
Message-ID: <e4f3422d-50ed-cdd0-aed4-00d4cdf14e40@gmail.com>
Date: Wed, 1 Jun 2016 11:14:34 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <20160601152314.16196.25416.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/CyIPzP-hntlxgP3MnwEPhX-fOHg>
Cc: draft-ietf-dime-e2e-sec-req@ietf.org, dime@ietf.org, dime-chairs@ietf.org
Subject: Re: [Dime] Ben Campbell's No Objection on draft-ietf-dime-e2e-sec-req-04: (with COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: jouni.nospam@gmail.com
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2016 18:14:41 -0000

Ben,

Thanks for the review. See my comments inline.

6/1/2016, 8:23 AM, Ben Campbell kirjoitti:
> Ben Campbell has entered the following ballot position for
> draft-ietf-dime-e2e-sec-req-04: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dime-e2e-sec-req/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Substantive:
>
> - I am concerned about the de-emphasis of privacy requirements. While
> there's a mention of confidentiality in Requirement 2, other text
> suggests that integrity is more important (implying privacy is less
> important). There are no privacy considerations. Finally, the  {AVP}k
> convention does not distinguish  hinders discussion about how the set of
> confidentiality-protected AVPs and integrity-protected AVPs might not be
> the same. [Note: I almost balloted DISCUSS over this point. I did not,
> because I don't want to force the working group to add requirements it
> doesn't believe in. But I'd like to see some discussion about this.]

First the convention {AVP}k.. it is used in the example figures that lay 
out the possible deployment models and scenarios. There the important 
thing is to illustrate where AVPs are protected.. somehow. I do not see 
any value going into details in those examples whether the AVPs (or some 
set of them) are confidentiality or integrity protected.

Second the privacy. I do not buy the de-amphasis argument. My belief and 
assumption so far has been that indiovidual user privacy needs to be 
addressed at a different level. You do not need confidentiality 
protection for that. That was, for example, how we did it in RADIUs 
(i.e., Chargeable-User-Identity). You system and used subscriber 
identities are already designed in a way that they provide privacy.

> - The "middle to *" models may be useful, but they are not end-to-end.
> Given the focus on those models, I find the title of the draft to border
> on disinformation. The description in the introduction about protecting
> AVPs between "non-neighbor" nodes is more accurate.

Right. I recall we had a discussion about this earlier. AFAIR we kind of 
agreed that we cannot really say where the e2e ends and what are the 
real endpoints. So it was "e2e" between two Diameter nodes given any 
topology between the two.

> - I find it odd to find 2119 keywords in the "motivation" sections. I
> suspect that most of those are statements of fact. If some are really
> requirements, they should be presented as such.

Ack. Should clean those away.


> - 4: The listed advantages of the middle-middle model (and also
> middle-to-end and end-to-middle) seem to assume that the number of
> "middles" is smaller than the number of "ends". While this may be true,
> especially for clienty ends, it should probably be explicitly stated.

Hmm.. okay.

> -- "firewalling Diameter proxy" needs a definition or reference.

Ack. We'll add a definition. Proposing the text below into Terminology 
Section:

    Diameter Firewall: a Diameter firewall is a proxy (or a relay) agent
      that acts similarly to conventional IP traffic firewalls but only
      at the Diameter AVP and command level. A Diameter firewall may,
      for example, discard security policy offending AVPs from
      traversing through it. The Diameter firewall may even discard
      entire Diameter messages based on the security policy.

> - Requirement 1: Does this need discussion on deprecating algorithms when
> vulnerabilities become known?

I don't think so. Deprecating an algorithm in my view in this case is 
more of an administrative decision to turn of certain deprecated 
algorithms in a given deployment.

>
> - Requirement 2: Please elaborate on backwards-compatibiltiy with
> existing applications. Is this intended to motivate the models with
> "middles"?

Motivating "middles" is one thing. The other thing is that it is 
valuable if the integrity protection can be turned on without requiring 
to update intermediate nodes between "e2e endpoints".

The requirement probably say here that the "backward-compatibilty" 
implies travesing non-updated proxy & relay agents.

> - Requirement 7: This (along with some text in the introduction) implies
> that non-repudiation is a requirement. If so, that should be listed and
> elaborated as a requirement.

I believe tnon-repudiation is already covered by the requirement #2, 
which says "..integrity, and data-origin authentication."

>
> Editorial and Nits:
>
>
> - 1, first paragraph: "mechanisms independent of Diameter (e.g., IPsec)
>    is used."
>
> s/is/are

Ack.

>
> - Requirement 3: The last sentence seems to ask the reader to draw a
> conclusion that wall-clock time can be used for anti-replay protection.
> If that's the intent, please say so explicitly.

Ack. Different nodes should have the same view of time, however, I am 
not sure whether that is a requirement for anti-replay.. it can also 
implemented using counters and such. I would simplify the whole 
requirement as:

    Requirement #3:  The solution MUST support replay protection.

Then we do not make any assumption what is the used mechanism.. counter, 
sequence number, token, time, or whatever.

- Jouni

>
>