Re: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-relay-server-security-04: (with COMMENT)

"Bernie Volz (volz)" <volz@cisco.com> Thu, 13 April 2017 03:39 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A6B124D37; Wed, 12 Apr 2017 20:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 b2w78xn9ntRt; Wed, 12 Apr 2017 20:39:12 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50A07128B91; Wed, 12 Apr 2017 20:39:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9854; q=dns/txt; s=iport; t=1492054752; x=1493264352; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IgvHQreFElA3Lb6XJ/YY4ma0rMH+8Y60MsRVMMcJUJU=; b=iIh63pEtrg0dpJsavki/yJHntTD6a1abRgV2wrHD12jTJPSvsb16tOqC jG5FjZeJNMc5n/aKIf+7MwPuIKLeOZ8/e9S6j7Z3mA0xYWP17sUArSHZ3 KZUkdMAgEGmkzO++7koUcFfKIb7U4PGN4nxn20mWgZJBsQ1HavbdaTIwM U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DEAQAw8u5Y/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHg1+KE5FViBqNP4IPLIV4AhqDaD8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFQEBAQECASMRPgcFBwQCAQgRBAEBAQICIwMCAgIfERQBCAgCBA4FCIl2Aw0ID?= =?us-ascii?q?qlwgiaHMw2DUwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuHI4INgQqCUYFXEQE?= =?us-ascii?q?GLYJvgl8FiSeTKDsBhwGHHIQ6ggiFLooXiwKIfwEfOH0IWxVBhRCBSnUBhnOBI?= =?us-ascii?q?YENAQEB?=
X-IronPort-AV: E=Sophos;i="5.37,193,1488844800"; d="scan'208";a="230483471"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Apr 2017 03:39:11 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v3D3dBbd008792 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Apr 2017 03:39:11 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 12 Apr 2017 22:39:09 -0500
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Wed, 12 Apr 2017 22:39:10 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Ben Campbell <ben@nostrum.com>
CC: The IESG <iesg@ietf.org>, Tomek Mrugalski <tomasz.mrugalski@gmail.com>, "dhc-chairs@ietf.org" <dhc-chairs@ietf.org>, "draft-ietf-dhc-relay-server-security@ietf.org" <draft-ietf-dhc-relay-server-security@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: Ben Campbell's Yes on draft-ietf-dhc-relay-server-security-04: (with COMMENT)
Thread-Index: AQHSs8zyj4ZKg6OMBEaSOILNFPwHs6HCYieAgACMKID//8IdgIAARv8A//+u3dA=
Date: Thu, 13 Apr 2017 03:39:10 +0000
Message-ID: <dcc9978bfd974406a848e771fb70d8ab@XCH-ALN-003.cisco.com>
References: <149202959436.15730.7482173620764260658.idtracker@ietfa.amsl.com> <D4BF03B4-792A-42A9-BDE6-5FA203D4D7F7@cisco.com> <CB02997F-BAE5-4F0D-9BD9-43D5FD4ACDDB@nostrum.com> <7ED92DCC-697F-4877-B6ED-F8076BE1E854@cisco.com> <ACAB925E-1A10-4C88-8F10-36A6E664F1B8@nostrum.com>
In-Reply-To: <ACAB925E-1A10-4C88-8F10-36A6E664F1B8@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.254.59]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/Qqz-yZEDxVLc3RAT2V3GfK68gxc>
Subject: Re: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-relay-server-security-04: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Apr 2017 03:39:15 -0000

Hi:

> That would suggest that the "MUST be secure" assertion in paragraph 4 is redundant with other normative text, and could be restated without the capitalized MUST.

I'm not sure exactly what that reference is to? Paragraph 4 is:

   Relay agents and servers MUST exchange messages securely using the
   IPsec mechanisms described in [RFC4301].  If a client message is
   relayed through multiple relay agents (relay chain), each of the
   relay agents MUST have an established independent, pairwise trust
   relationships.  That is, if messages from client C will be relayed by
   relay agent A to relay agent B and then to the server, relay agents A
   and B MUST be configured to use IPsec for the messages they exchange,
   and relay agent B and the server MUST be configured to use IPsec for
   the messages they exchange.

Perhaps you are referring to the first MUST or all be changed to lower case?

I'm proposing going with:

   Relay agents and servers MUST be able to exchange messages using the
   IPsec mechanisms described in [RFC4301] and with the conditions
   below.  If a client message is relayed through multiple relay agents
   (relay chain), each of the relay agents MUST have an established
   independent, pairwise trust relationships.  That is, if messages from
   client C will be relayed by relay agent A to relay agent B and then
   to the server, relay agents A and B MUST be configured to use IPsec
   for the messages they exchange, and relay agent B and the server MUST
   be configured to use IPsec for the messages they exchange.

We do want to make it clear that an implementation that conforms to the to-be-RFC needs to support IPsec with those conditions.

- Bernie

-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.com] 
Sent: Wednesday, April 12, 2017 11:26 PM
To: Bernie Volz (volz) <volz@cisco.com>
Cc: The IESG <iesg@ietf.org>rg>; Tomek Mrugalski <tomasz.mrugalski@gmail.com>om>; dhc-chairs@ietf.org; draft-ietf-dhc-relay-server-security@ietf.org; dhcwg@ietf.org
Subject: Re: Ben Campbell's Yes on draft-ietf-dhc-relay-server-security-04: (with COMMENT)

On 12 Apr 2017, at 22:11, Bernie Volz (volz) wrote:

> Hi:
>
> OK, I’ll use conditions.
>
>>    Is ESP with null encryption allowed?
>
> No. That was what RFC3315 had but this document changes that.

That would suggest that the "MUST be secure" assertion in paragraph 4 is redundant with other normative text, and could be restated without the capitalized MUST.

Ben.

>
> RFC 3315:
>
>       Mode             Relay agents and servers use transport mode and
>                        ESP. The information in DHCP messages is not
>                        generally considered confidential, so 
> encryption
>                        need not be used (i.e., NULL encryption can be
>                        used).
>
> This new draft:
>
>    Encryption and authentication algorithms
>                            This document REQUIRES combined mode
>                            algorithms for ESP authenticated 
> encryption,
>                            ESP encryption algorithms, and ESP
>                            authentication algorithms as per Sections
>                            2.1, 2.2, and 2.3 of [RFC7321] 
> respectively.
>                            Encryption is required as relay agents may
>                            forward unencrypted client messages as well
>                            as include additional sensitive 
> information,
>                            such as vendor-specific information (for
>                            example, [CableLabs-DHCP]) and [RFC7839].
>
> - Bernie
>
> On 4/12/17, 10:52 PM, "Ben Campbell" <ben@nostrum.com> wrote:
>
>     On 12 Apr 2017, at 17:31, Bernie Volz (volz) wrote:
>
>     > Hi:
>     >
>     > For:
>     >
>     >     -3, third paragraph: "MUST exchange messages securely"
>     >     "Securely" is too ambiguous for a MUST. What specific 
> protections
>     > are
>     >     required?
>     >
>     > I believe this also was the 4th paragraph?
>
>     Yes
>
>     > I guess there are two choices here:
>     > 1. Drop “securely” as we are just specifying to use IPsec.
>     > 2. Replace “securely” with “encrypted and authenticated”.
>     > Seems to be #1 might be better (as it should be unnecessary 
> given that
>     > is what this document is about).
>
>     Is ESP with null encryption allowed?
>
>     >
>     >
>     >      -3, paragraph 4:
>     >     The list starts with no context. A sentence or paragraph
>     > describing the
>     >     purpose of the list would be helpful.
>     >
>     > RFC 3315 had before this list:
>     >    Relay agents and servers that support secure relay agent to 
> server
>     > or
>     >    relay agent to relay agent communication use IPsec under the
>     >    following conditions:
>     >
>     > But I’m not sure “conditions” is the best word? Not sure if
>     > there is a better word to use to describe these items?
>
>     Rules? Configuration? (But I don't think "conditions" is awful)
>
>     >
>     > Perhaps replacing the first sentence in that 4th paragraph with:
>     >
>     >   Relay agents and servers MUST exchange messages using the
>     >   IPsec mechanisms described in [RFC4301] with the conditions
>     >   as follows:
>     >
>     > And, move the remaining text in that 4th paragraph to the end of
>     > section 4 as a separate paragraph.
>     >
>     > - Bernie
>     >
>     > On 4/12/17, 4:39 PM, "Ben Campbell" <ben@nostrum.com> wrote:
>     >
>     >     Ben Campbell has entered the following ballot position for
>     >     draft-ietf-dhc-relay-server-security-04: Yes
>     >
>     >     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-dhc-relay-server-security/
>     >
>     >
>     >
>     >     
> ----------------------------------------------------------------------
>     >     COMMENT:
>     >     
> ----------------------------------------------------------------------
>     >
>     >     I am balloting "Yes", but I share the curiosity about 
> whether
>     > people will
>     >     really do this.
>     >
>     >     -3, third paragraph: "MUST exchange messages securely"
>     >     "Securely" is too ambiguous for a MUST. What specific 
> protections
>     > are
>     >     required?
>     >
>     >     -3, paragraph 4:
>     >     The list starts with no context. A sentence or paragraph
>     > describing the
>     >     purpose of the list would be helpful.