Re: [dhcwg] Comments on draft-ietf-dhc-relay-server-security-01

Timothy Carlin <tjcarlin@iol.unh.edu> Fri, 09 December 2016 17:04 UTC

Return-Path: <tjcarlin@iol.unh.edu>
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 8CBF31298D3 for <dhcwg@ietfa.amsl.com>; Fri, 9 Dec 2016 09:04:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu
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 e0xmMuzQmcK9 for <dhcwg@ietfa.amsl.com>; Fri, 9 Dec 2016 09:04:54 -0800 (PST)
Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (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 2F46C1298D9 for <dhcwg@ietf.org>; Fri, 9 Dec 2016 09:04:38 -0800 (PST)
Received: by mail-ua0-x233.google.com with SMTP id 51so23223909uai.1 for <dhcwg@ietf.org>; Fri, 09 Dec 2016 09:04:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pu8MTad9HkLunv3YtY1akNsBPuF/7ZUdgW7qSce94Pk=; b=TeGp9zdcEiPGcVgZ57odaKK3/eNdJJRNkaFJNNgO4p+4qwinR3zVDwz7PdClRNc+Lz 5x5kjJpeUloeF43Psjpncq0sJmrlSP/UDe/Jp2uwzlmwYmAzM0JBbeWbMFbF0EZFwf13 MDyzXYMoN8UOMT3t1y6yXfLdfBJjRoo0/KkRY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pu8MTad9HkLunv3YtY1akNsBPuF/7ZUdgW7qSce94Pk=; b=XvW2nHC2XP5LS0Al24MZVhqKTY8Lexvy4M8xwnZ4R9JBpARCLLf/EtgUfir+hiERg8 kh4znbyjH6wtt2gk+LeSbBXVbVxmPkkwl65fwx2Ml89YWq4FNzB14MKJ8FSbFghNghpN xngV209gF9lvjNJH5WQ+sixf/7/xDH3z8zSpJ0BJuW1d9D8t07P68pBu5mTG5q6IuS8r 1blxZtpydyNKPI8BGZpRMaVjl3O/wQ4bX/FtYfvwitx1Nb0QQi022q7E20ISXwiq20sq SJ574RuH40CRnrR7cDrsRbrb3s0rLVoSupYRPkRiScE5FJGTbcyfvuy5VHRYVsn1Pu4j Fhvg==
X-Gm-Message-State: AKaTC03uwYGbRx5Up74Diee6ymg/cZwikiOyr/cNLgM+Q/wVNz2nauTdpShuRS9GYpP/6Jah/vrgoZi80o6TSamk
X-Received: by 10.176.85.24 with SMTP id t24mr65797951uaa.21.1481303077243; Fri, 09 Dec 2016 09:04:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.7.102 with HTTP; Fri, 9 Dec 2016 09:03:56 -0800 (PST)
In-Reply-To: <0fa0546d1f0e4a2f951db3f7ed9c992b@XCH-ALN-003.cisco.com>
References: <147671242179.4527.12337010225582460227.idtracker@ietfa.amsl.com> <7e03afc26a08461e8308d5bdf985bed9@XCH-ALN-003.cisco.com> <ccbfe561da43469e8f894e2235c4b429@XCH15-06-08.nw.nos.boeing.com> <6a8f5646aedb44b5af85d7a45039eb02@XCH-ALN-003.cisco.com> <ed09c191c9a24989b38ec3db233e04d1@XCH15-06-08.nw.nos.boeing.com> <CA+dB4X4edhyJa+FR8phiJvQqi1wPU+eqsZ4=b4WHL7mFj-Dkgw@mail.gmail.com> <6c57d13d-7f48-67b5-fdad-4f230f46553f@gmail.com> <82f50590-1a44-a19d-3cb1-8ca2ce44f5d0@gmail.com> <0fa0546d1f0e4a2f951db3f7ed9c992b@XCH-ALN-003.cisco.com>
From: Timothy Carlin <tjcarlin@iol.unh.edu>
Date: Fri, 09 Dec 2016 12:03:56 -0500
Message-ID: <CAB-aFv8NuZ+9DLZNQ6nJNB2-OFHJQZk7u=nVR7nY7mk=WK17bg@mail.gmail.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
Content-Type: multipart/alternative; boundary="f403045dd960b9799a05433cbfa5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/CWUordFnMollJ48dpAnDLxrhQ1A>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, "Yogendra Pal (yogpal)" <yogpal@cisco.com>
Subject: Re: [dhcwg] Comments on draft-ietf-dhc-relay-server-security-01
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 09 Dec 2016 17:04:57 -0000

Hello all,

I have done a brief review of this draft and I have some additional
thoughts.

Regarding the use of Manual Keys, ipsecme is currently having a discussion
about phasing out the use of Manual Keys.  See this thread for full context
(Subject: [IPsec] RFC4301, rfc7321bis and Manual keys):
https://mailarchive.ietf.org/arch/search/?email_list=ipsec&gbt=1&index=cMBLIx_ZzQVWP7lX1l-clgGdtvU

The document also recommends combined mode algorithms, such as AES-GCM, or
AES-GMAC.  These algorithms, and similar, generally disallow the use of
manual keys for security purposes.  For example, according to RFC4543,
Section 2, implementations MUST use automated key management (e.g. IKEv2),
as manual keying does not guarantee that a nonce and key is not reused and
therefore makes these algorithms insecure.

Best Regards,
Tim Carlin, UNH-IOL

On Fri, Dec 9, 2016 at 11:27 AM, Bernie Volz (volz) <volz@cisco.com> wrote:

> I discussed some of these issues with Tomek a bit.
>
> Regarding the non-normative language issue, we have a proposal as follows:
> - We will move the existing (non-normative language) into
> draft-ietf-dhc-rfc3315bis as it is best we don't require (but recommend)
> IPsec for DHCPv6. This would also correct the open issue we have in the
> draft-ietf-dhc-rfc3315bis document regarding the algorithms to use.
> - We will reword this draft (in the 02) to use the normative (i.e., MUST)
> language. That way, if a vendor claims to be in compliance with this
> (future) RFC, they would have to fully support IPsec for the relay to
> server communication.
>
> > idnits report some issues with references. The text cites RFC2409, but
> it was obsoleted by RFC4306.
>
> I could be wrong, but my understanding is that RFC 2409 documents IKEv1.
> This was indeed obsoleted by IKEv2 (which is actually specified in RFC 7296
> now -- 4306 was obsoleted by 5996 which was obsoleted by 7296). The reason
> we have both here is that we are referencing IKEv1 and IKEv2. I'm not so
> sure if there is any value in specifying IKEv1 anymore given that this us
> now almost 20 years old. I think the best move might be to change "
> Accordingly, IKE [RFC2409] / IKE2 [RFC7296] with preshared..." to just be "
> Accordingly, IKE2 [RFC7296] with preshared ..." and drop RFC 2409
> altogether.
>
> > idnits also complains about a disclaimer for pre-RFC5378 work. I think
> this is ok, because you're providing an updated text from RFC3315.
>
> Correct.
>
> >The document is very specific as to what is updated in RFC3315 (section
> 21.1), but it's blurry regarding RFC1542 update. Is there any specific text
> that is being updated? If there is, please clearly state so. If there
> isn't, maybe this draft doesn't update RFC1542?
>
> For 1542, it really "extends" it since that document was silent about
> IPsec ... so we can remove this.
>
> And, I wonder if we should even say it updates 3315 as that might imply it
> is "required" -- and we'll be updating draft-ietf-dhc-rfc3315bis already,
> as mentioned above. Thus I propose to just remove that (in the meta data
> and in the text).
>
> I'll wait a few days to see if anyone has any comments to this thread
> before publishing the -02 revision.
>
> - Bernie
>
> -----Original Message-----
> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski
> Sent: Friday, December 09, 2016 9:58 AM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Comments on draft-ietf-dhc-relay-server-security-01
>
> Hi,
>
> There are my review of the draft. Apologies for sending it up so late, but
> I was travelling a lot recently. Finally got back home and catching up on
> my IETF duties.
>
> Section 3 uses non-normative language like "it is highly recommended"
> and "relay agents A and B must be configured to use IPsec". This is a
> standards track document, so why not normative language? I would very much
> prefer to have a normative text. When a vendor claims "my solution supports
> this RFC", what would it mean in its current form? The text is not
> normative, so technically someone could claim compliance and not do any of
> the IPsec at all.
>
> The text in section 3 is also a bit conflicting. One part says "highly
> recommended" and the next sentence says "must". This should be consistent.
> My preferred way would be to go with "implementations conformant to this
> document MUST ...". This wording does not enforce vendors to implement it,
> but if they want to claim compliance, they really need to be able to do
> IPsec.
>
> idnits report some issues with references. The text cites RFC2409, but it
> was obsoleted by RFC4306. If you have specific reasons why you reference
> the old text, please state it in the text explicitly.
> Otherwise, just update the references.
>
> idnits also complains about a disclaimer for pre-RFC5378 work. I think
> this is ok, because you're providing an updated text from RFC3315.
>
> When you upload the next rev, make sure you bump up reference to
> sedhcpv6 to -18.
>
> The document is very specific as to what is updated in RFC3315 (section
> 21.1), but it's blurry regarding RFC1542 update. Is there any specific text
> that is being updated? If there is, please clearly state so. If there
> isn't, maybe this draft doesn't update RFC1542?
>
> Other than the normative text clarification and 1542 update clarification,
> I think the draft is in very good shape. With my co-chair hat off, I
> support this work. With one more rev it should be ready to go.
>
> Tomek
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>