From weiler+secdir@watson.org Wed Feb 8 07:03:04 2012 Return-Path: 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 355B021F8546 for ; Wed, 8 Feb 2012 07:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[AWL=-0.851, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QqDq0Zph5jU for ; Wed, 8 Feb 2012 07:03:03 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8E94E21F852D for ; Wed, 8 Feb 2012 07:03:03 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q18F32Sw078196 for ; Wed, 8 Feb 2012 10:03:02 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q18F31Uh078180 for ; Wed, 8 Feb 2012 10:03:01 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 8 Feb 2012 10:03:01 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Wed, 08 Feb 2012 10:03:02 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 15:03:04 -0000 It's a quiet time in the world of the secdir. A few docs first assigned two weeks ago (and with IETF LCs that ended earlier this week) are on the 16 February telechat. Four new assignments. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Klaas Wierenga is next in the rotation. For telechat 2012-02-16 Reviewer LC end Draft Dave Cridland T 2012-01-03 draft-os-ietf-sshfp-ecdsa-sha2-07 Warren Kumari T 2012-01-24 draft-ietf-dime-pmip6-lr-07 Russ Mundy T 2012-02-14 draft-ishikawa-yrpunl-ucode-urn-02 Sandy Murphy T 2012-02-06 draft-ietf-dnsext-xnamercode-00 Radia Perlman T 2012-02-07 draft-ietf-hokey-erp-aak-08 Yaron Sheffer T 2012-02-06 draft-ietf-dhc-dhcpv4-bulk-leasequery-05 Ondrej Sury T 2012-02-06 draft-ietf-dhc-forcerenew-nonce-03 For telechat 2012-03-01 Brian Weis T 2012-02-20 draft-ietf-v6ops-v6nd-problems-04 Last calls and special requests: Leif Johansson R2012-02-07 draft-ietf-oauth-v2-23 Julien Laganier 2012-02-13 draft-ietf-marf-redaction-08 Barry Leiba 2012-01-13 draft-ietf-pcn-signaling-requirements-07 Magnus Nystrom 2012-02-07 draft-ietf-dhc-pd-exclude-04 Hilarie Orman 2012-02-07 draft-ietf-dnsext-ecdsa-04 Tim Polk 2012-02-07 draft-ietf-oauth-v2-bearer-16 Eric Rescorla 2012-02-08 draft-ietf-sieve-notify-sip-message-08 Vincent Roca 2012-02-06 draft-ietf-simple-chat-13 Joe Salowey 2012-02-21 draft-snell-atompub-tombstones-14 Tina TSOU 2012-02-20 draft-ietf-behave-64-analysis-05 Carl Wallace 2012-02-21 draft-ietf-netext-pmip-lr-08 Sam Weiler 2012-03-06 draft-george-travel-faq-03 From leifj@sunet.se Wed Feb 8 07:15:29 2012 Return-Path: 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 D8A5221F863E for ; Wed, 8 Feb 2012 07:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRRCMwMGQs34 for ; Wed, 8 Feb 2012 07:15:28 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 26A1121F863B for ; Wed, 8 Feb 2012 07:15:22 -0800 (PST) Received: from [192.36.125.231] (dhcp.pilsnet.sunet.se [192.36.125.231] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q18FFH9V001111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Feb 2012 16:15:21 +0100 (CET) Message-ID: <4F329185.8030002@sunet.se> Date: Wed, 08 Feb 2012 16:15:17 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: secdir@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] Assignments X-BeenThere: secdir@ietf.org 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: Wed, 08 Feb 2012 15:15:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Leif Johansson R2012-02-07 draft-ietf-oauth-v2-23 no sense in letting things sit around :-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8ykYUACgkQ8Jx8FtbMZneITQCgvAX3BS8FjzTsY5Tm0Ye6VTIl M2MAmwaBOfQNFfABfTCQHZDanaPYPWST =qrmB -----END PGP SIGNATURE----- From new-work-bounces@ietf.org Tue Feb 7 09:40:02 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D9421F88A3; Tue, 7 Feb 2012 09:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328636402; bh=007T1qvuoYdatv+mmqnUd587MQW3VxCigZxpFiaR5h4=; h=From:To:Mime-Version:Message-Id:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=bVwICuvc1pCz6EYvuQDPsv+Rjr7RkyPu8t4ydFRU0t4cg4I4bqRWF2QrqWSM1dc2j J6YkLg71DGeeb94rYcInMiZE99MgC+7EMEDNop+zWjfepvQy4WfX9yH6DGyWbE/HV7 BeY9N0ZHJ81JTzIGAZm5KeHtoohiZeXS2r8oMy1w= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id D22F421F887A; Tue, 7 Feb 2012 09:40:00 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20120207174000.D22F421F887A@ietfa.amsl.com> Date: Tue, 7 Feb 2012 09:40:00 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 08 Feb 2012 08:29:00 -0800 Subject: [secdir] [new-work] WG Review: Recharter of Basic Level of Interoperability for SIP Services (bliss) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 17:40:02 -0000 A modified charter has been submitted for the Basic Level of Interoperability for SIP Services (bliss) working group in the Real-Time Applications and Infrastructure Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, February 14, 2012. Basic Level of Interoperability for SIP Services (bliss) ----------------------------------------- Status: Active Working Group Last Updated: 2012-02-02 Chair: Shida Schubert Real-Time Applications and Infrastructure Area Director(s): Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Robert Sparks Tech Advisor: Jonathan Rosenberg Mailing Lists: General Discussion: bliss@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bliss Archive: http://www.ietf.org/mail-archive/web/bliss Description of Working Group: The BLISS working group is rechartered to adjust its scope to reflect changes in working group interest and RAI processes since its original chartering. BLISS was chartered prior to the creation of DISPATCH. The charter called for the WG to document how to realize four initial building blocks in an interoperable way with existing standards, and to describe the use of those building blocks to implement specific call features. Any extensions to the protocols beyond the creation of event packages or the addition of SIP URI parameters was set out of scope for this working group. Working group interest in all but two of those building blocks has diminished. The current drafts on those two propose extensions that under the original charter would need to be developed in other working groups. Given the update to the SIP change process (RFC5727) and the subsequent restructuring of the RAI area, these constraints are being revised as detailed below. The BLISS working group shall be closed after completing the following two proposed standards: - call completion with queuing as proposed in draft-ietf-bliss-call-completion - shared appearances as proposed in draft-ietf-bliss-shared-appearances The goal to produce a problem statement and a common template for describing primitives is abandoned. The group will continue to work within the constraints of the creation of event packages and SIP URI parameters, with the addition of the ability to - exercise the already standardized extension points of SIP header fields. Currently, the documents propose to extend the SIP Alert-Info header field (RFC3261) to carry an appearance identifier, and the SIP Call-Info header field (RFC3261) to carry a call completion indicator. - extend the SIP Dialog event package (RFC4235) to carry appearance related state, The working group will coordinate review of those extensions with the SIPCORE working group. Describing the security properties (particularly any privacy considerations) of these deliverables remains of special importance. Upon completion of these two work items, the working group will conclude. Future proposals should be directed to the DISPATCH working group. Goals and Milestones: Mar 2012 Submit Shared Appearances to the IESG for publication as Proposed Standard Jul 2012 Submit Call Completion to the IESG for publication as Proposed Standard Sep 2012 Bliss concludes _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Feb 7 09:43:53 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C19321F88D8; Tue, 7 Feb 2012 09:43:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328636633; bh=k6hGz2sLffsM39l5uUoyeWwDCr+pZmuCEut6Qj0cyPU=; h=From:To:Mime-Version:Message-Id:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=itjkYVQHj4z/LkKEgCWrRz31sORi9Q7Lyt7uDdi4UCAs4b+aSXr4ju8yao4A4PoxW O7DOHbjOKOUUCIJ/sJrvdIFWIUQIokeGTbworEG82ih48R7YUNEt53M85HNxuGiyfH /CqpfVyFyYo4e/F4TCbE/Iyj2FNeDXhb7sdZ7gt4= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 18CAD21F88C6; Tue, 7 Feb 2012 09:43:52 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20120207174352.18CAD21F88C6@ietfa.amsl.com> Date: Tue, 7 Feb 2012 09:43:52 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 08 Feb 2012 08:29:00 -0800 Subject: [secdir] [new-work] WG Review: Recharter of BiDirectional or Server-Initiated HTTP (hybi) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 17:43:53 -0000 A modified charter has been submitted for the BiDirectional or Server- Initiated HTTP (hybi) working group in the Applications Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, February 14, 2012. BiDirectional or Server-Initiated HTTP (hybi) ----------------------------------------- Status: Active Working Group Last Updated: 2012-02-02 Chairs: Salvatore Loreto Gabriel Montenegro Applications Area Director(s): Pete Resnick Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Secretary: S Moonesamy Mailing Lists: Address: hybi@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/hybi Archive: http://www.ietf.org/mail-archive/web/hybi/ Description of Working Group: The BiDirectional or Server-Initiated HTTP (HyBi) working group defines the WebSocket Protocol, a technology for bidirectional communication between an HTTP client and an HTTP server that provides greater efficiency than previous approaches (e.g., use of hanging requests or long polling). Having completed work on the core protocol (RFC 6455), the group continues to define extensions for use by WebSocket implementations. The following extensions and optimizations are currently in scope: 1. A per-frame compression extension to improve bandwidth usage (draft-tyoshino-hybi-websocket-perframe-deflate is a likely starting point). 2. A multiplexing extension to improve the scalability of the WebSocket protocol (draft-tamplin-hybi-google-mux is a likely starting point). 3. Timeout-handling capabilities to reduce the chattiness of the protocol (draft-thomson-hybi-http-timeout is a likely starting point). The working group will also serve as a discussion venue for subprotocols. However, no subprotocol is currently chartered as a deliverable, and the WG must be rechartered to work on any subprotocols. The group will not work on an updated version of the WebSocket protocol, unless it is specifically rechartered to do so. The group will continue coordinating with the W3C WepApps working group with respect to the above deliverables and to ensure the best match possible between the WebSocket protocol and the WebSocket API. The group will also continue coordinating with other working groups within the IETF (e.g., HTTPBIS) as appropriate. Goal and Milestones: Feb 2012 - Adopt a WG item for the per-frame compression extension May 2012 - Issue WG last call on the per-frame compression extension Jun 2012 - Send per-frame compression extension to IESG for consideration as a Proposed Standard Jun 2012 - Adopt a WG item for timeout handling Jul 2012 - Adopt a WG for the multiplexing extension Aug 2012 - Issue WG last call on timeout handling Sep 2012 - Issue WG last call on the multiplexing extension Oct 2012 - Send timeout handling to IESG for consideration as a Proposed Standard Nov 2012 - Send multiplexing extension to IESG for consideration as a Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From julien.ietf@gmail.com Wed Feb 8 10:19:19 2012 Return-Path: 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 1031421E8015; Wed, 8 Feb 2012 10:19:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjVKhcQLM3sr; Wed, 8 Feb 2012 10:19:18 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0A321E8010; Wed, 8 Feb 2012 10:19:18 -0800 (PST) Received: by yenm3 with SMTP id m3so486636yen.31 for ; Wed, 08 Feb 2012 10:19:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=KYHz8YrIjACMt41tUEdIJ1QUe5xByp8SuGOosOorEBk=; b=TYl6xDq0pHQPS/CgRek340NdkW1SCcW+04o0gqykRIKLf6JzDQ5/khbjakTr3fq2SZ sW606H4XpzcEPr0c+orb7LGjGEyUO5Y9s4G7BGbLGkYBygEyxqvM7DkFNQiE0XrUdjwq 03qduNVpdCNaSArYebVp1uePlxdfoGAf2CN8s= MIME-Version: 1.0 Received: by 10.101.141.8 with SMTP id t8mr11534097ann.71.1328725158013; Wed, 08 Feb 2012 10:19:18 -0800 (PST) Received: by 10.146.67.39 with HTTP; Wed, 8 Feb 2012 10:19:17 -0800 (PST) Date: Wed, 8 Feb 2012 10:19:17 -0800 Message-ID: From: Julien Laganier To: The IESG , secdir@ietf.org, draft-ietf-marf-redaction.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] SECDIR review of draft-ietf-marf-redaction-08 X-BeenThere: secdir@ietf.org 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: Wed, 08 Feb 2012 18:19:19 -0000 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. This document suggest a method to redact private and/or sensitive portions (e.g., email addresses) of abuse reports in the messaging infrastructure. The proposed method enables a report receiver to correlate reports that might refer to a common but anonymous source. I believe that the proposed method is ok and that its security and privacy implications are adequately analyzed. --julien From radiaperlman@gmail.com Wed Feb 8 22:39:00 2012 Return-Path: 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 28C3C21F8599; Wed, 8 Feb 2012 22:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.686 X-Spam-Level: X-Spam-Status: No, score=-3.686 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZHCKmlXwSwL; Wed, 8 Feb 2012 22:38:59 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3361121F854E; Wed, 8 Feb 2012 22:38:59 -0800 (PST) Received: by eaal12 with SMTP id l12so449735eaa.31 for ; Wed, 08 Feb 2012 22:38:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=eftIdMBpfnNxikmImGG14w0pWLrQPM7vH2nLawK02W0=; b=W6NaeQjecH4Y5EJDvLbSLknqm9tabUaNHdyC6WLDoAZhbfxs3cAoInEkMePal3xb87 9HZc6CKqKrepx9ipPlDRBIyZ5vgBnjZbGgOvng5ARCZAbCE8W9ezCPJ8OsGq1AApFykP 4i3P29wTpNGSwfBifO2Qaac6ttHW+zfc2imQI= MIME-Version: 1.0 Received: by 10.213.28.133 with SMTP id m5mr162673ebc.62.1328769538328; Wed, 08 Feb 2012 22:38:58 -0800 (PST) Received: by 10.213.16.205 with HTTP; Wed, 8 Feb 2012 22:38:58 -0800 (PST) Date: Wed, 8 Feb 2012 22:38:58 -0800 Message-ID: From: Radia Perlman To: The IESG , secdir@ietf.org, draft-ietf-hokey-erp-aak.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] SECDIR review of draft-ietf-hokey-erp-aak X-BeenThere: secdir@ietf.org 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: Thu, 09 Feb 2012 06:39:00 -0000 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. This is mostly OK technically, but sloppily written. It's about giving a MH the keys to a new access point after a handoff. Starting from section 3..."Peer" is sometimes called "MH" (mobile host). It's preferable to use a single term, and I'd prefer MH (since it's not clear who the MH is peer with in this protocol). I found it surprising that the SAP knows where the MH will roam to. I'd think that the MH would need to see a new CAP and tell its SAP who it wants to connect with, or that the MH finds the CAP and tells the CAP who its SAP is/was. Under figure 6, it says "The x flag is reserved. It MUST be set to 0". Shouldn't the document say "and ignored on receipt"? There are various values that say TBD in the spec, but in the IANA considerations, there are values. So shouldn't they be copied into the spec instead of TBD? Also, not all the TBD values are listed in the IANA considerations. In the 4th paragraph before section 5.3, it talks about computing an integrity checksum over the ERP/AAK packet, excluding the authentication tag field. Does this mean that the authentication tag field is zeroed out for the computation, or that the message is truncated to exclude that field? In the paragraph before section 5.3, it talks about silently discarding the EAP-Initiate/Re-auth packet if it's not supported by the SAP. On a silent discard, how long do you wait for a response before assuming there won't be any, or perhaps that it got lost? (does it run over a reliable Transport? Even so, it might be silently discarded). There's also lots of minor typos. Should be proof-read. Radia From magnusn@gmail.com Wed Feb 8 22:43:24 2012 Return-Path: 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 2026E21F8565; Wed, 8 Feb 2012 22:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48tNpuZipGM9; Wed, 8 Feb 2012 22:43:23 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 86E5A21F8562; Wed, 8 Feb 2012 22:43:23 -0800 (PST) Received: by qcsg13 with SMTP id g13so899438qcs.31 for ; Wed, 08 Feb 2012 22:43:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=LMQjYHcjv+M6kLDUo0ElYoWICQKpl13yhmJZw8074G4=; b=nUlWb5J4fN63uzp5bJdgYY3FBFnWuq+WQodDz8B4XwRiuAlBK2LOSPMv4GCb+0gHq7 fyxidbhuHryOWM03zJPo1PcizWbZ7dZ5iHiVzK7wcD18oyQST0fZsX3vuntRlK9tzbAL c9Cq+Jvrse+AtoyGPU+fpb3k4fOSm36J7OU/s= MIME-Version: 1.0 Received: by 10.229.76.23 with SMTP id a23mr379829qck.100.1328769802193; Wed, 08 Feb 2012 22:43:22 -0800 (PST) Received: by 10.229.246.73 with HTTP; Wed, 8 Feb 2012 22:43:22 -0800 (PST) Date: Wed, 8 Feb 2012 22:43:22 -0800 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: iesg@ietf.org, secdir@ietf.org, draft-ietf-dhc-pd-exclude@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] Secdir review of draft-ietf-dhc-pd-exclude-04 X-BeenThere: secdir@ietf.org 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: Thu, 09 Feb 2012 06:43:24 -0000 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. This document defines a method for DHCPv6 routers to exclude a prefix out of a delegated set of prefixes. I have no comments on the document itself but the Security Considerations section is very terse. If the method in this draft does not introduce any new security considerations beyond those already present in RFC 3315 or RFC 3633 then it should at least say so. It appears to me however that something could be said about authenticating the request to exclude a particular prefix? -- Magnus From jouni.nospam@gmail.com Wed Feb 8 23:25:07 2012 Return-Path: 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 00EDC21F8565; Wed, 8 Feb 2012 23:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcuVF4Z-6LUq; Wed, 8 Feb 2012 23:25:06 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD9AB21F854D; Wed, 8 Feb 2012 23:25:05 -0800 (PST) Received: by lahl5 with SMTP id l5so1427480lah.31 for ; Wed, 08 Feb 2012 23:25:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=6A+g9ziMK8gmVcBrzxA4+M4SmnG//Lc4/cG1fttbo4g=; b=g3sZxw1zvpGLc/z1Ap6xMQJTQnCKrdbh36DeqrCNephI9F1b002tyHXQYJj97I2ZgA aMKerVBbpRhFNq/x3ss1WDN/8RwzRBejBJBkk4nDBG0Uy7C4YJkyqCg/OKoC598CYZ6U ZIqRNDiwVHeaZGQwTsjnFELXuUzy1Ep5WFbEs= Received: by 10.152.145.165 with SMTP id sv5mr395257lab.29.1328772304720; Wed, 08 Feb 2012 23:25:04 -0800 (PST) Received: from a88-114-172-138.elisa-laajakaista.fi (a88-114-172-138.elisa-laajakaista.fi. [88.114.172.138]) by mx.google.com with ESMTPS id mj2sm1455364lab.2.2012.02.08.23.25.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Feb 2012 23:25:02 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: Date: Thu, 9 Feb 2012 09:24:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-dhc-pd-exclude@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-dhc-pd-exclude-04 X-BeenThere: secdir@ietf.org 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: Thu, 09 Feb 2012 07:25:07 -0000 Magnus, Thank you for your review. Regarding the authentication of the excluded prefix. I admit the security considerations text is thin but, for = example, RFC3633 security considerations that we refer to already says: To guard against attacks through prefix delegation, requesting routers and delegating routers SHOULD use DHCP authentication as described in section 21, "Authentication of DHCP messages" of RFC 3315. For point to point links, where one trusts that there is no man in the middle, or one trusts layer two authentication, DHCP authentication or IPsec may not be necessary. Because a requesting We did not come up with anything more specific that should be added. Does the above address your concern regarding excluded prefix = authentication? We can add a sentence to the Security considerations saying: "This specification does not add any new security considerations in addition to those already discussed in RFC3315 and RFC3633." - Jouni On Feb 9, 2012, at 8:43 AM, Magnus Nystr=F6m wrote: > 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. >=20 > This document defines a method for DHCPv6 routers to exclude a prefix > out of a delegated set of prefixes. >=20 > I have no comments on the document itself but the Security > Considerations section is very terse. If the method in this draft does > not introduce any new security considerations beyond those already > present in RFC 3315 or RFC 3633 then it should at least say so. It > appears to me however that something could be said about > authenticating the request to exclude a particular prefix? >=20 > -- Magnus From magnusn@gmail.com Wed Feb 8 23:38:34 2012 Return-Path: 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 264FC21F85BB; Wed, 8 Feb 2012 23:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xyrrxod9dTfK; Wed, 8 Feb 2012 23:38:33 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1A521F844D; Wed, 8 Feb 2012 23:38:33 -0800 (PST) Received: by qafi29 with SMTP id i29so3928753qaf.10 for ; Wed, 08 Feb 2012 23:38:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=K0LQxcog3FbyNcMmnp3qFA4f+6dPlzp8ZNzxCKqIv+4=; b=CWBjwoXWlFhWhgqxE8XipAAeSyNL55gLJELYWdB9E/xmzEslquAtotbBjrxEV4a5yj e/kQAtVTj6CgIhjiAFUstzjjmCH8Y83MWpv4Sb+9olUJsOmgs+mI/ne0BDeXMFwtt2No eSpL1egfHjDx57nqXEVD/+KIGUYj/lXujC/Bo= MIME-Version: 1.0 Received: by 10.229.136.75 with SMTP id q11mr524227qct.60.1328773112719; Wed, 08 Feb 2012 23:38:32 -0800 (PST) Received: by 10.229.246.73 with HTTP; Wed, 8 Feb 2012 23:38:32 -0800 (PST) In-Reply-To: References: Date: Wed, 8 Feb 2012 23:38:32 -0800 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: jouni korhonen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-dhc-pd-exclude@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-dhc-pd-exclude-04 X-BeenThere: secdir@ietf.org 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: Thu, 09 Feb 2012 07:38:34 -0000 Thanks Jouni; the text in RFC 3633 looks great. Maybe you could update the security considerations section in your draft to say (add after current last sentence): "In particular, RFC 3633 provides recommendations for protection against prefix delegation attacks. This specification does not add any new security considerations beyond those provided by RFC 3633." ? This way, the reader will immediately know that it is covered by 3633. -- Magnus On Wed, Feb 8, 2012 at 11:24 PM, jouni korhonen wr= ote: > > Magnus, > > Thank you for your review. Regarding the authentication of the excluded > prefix. I admit the security considerations text is thin but, for example= , > RFC3633 security considerations that we refer to already says: > > =A0 To guard against attacks through prefix delegation, requesting > =A0 routers and delegating routers SHOULD use DHCP authentication as > =A0 described in section 21, "Authentication of DHCP messages" of RFC > =A0 3315. =A0For point to point links, where one trusts that there is no > =A0 man in the middle, or one trusts layer two authentication, DHCP > =A0 authentication or IPsec may not be necessary. =A0Because a requesting > > We did not come up with anything more specific that should be added. > Does the above address your concern regarding excluded prefix authenticat= ion? > > We can add a sentence to the Security considerations saying: > > "This specification does not add any new security considerations > =A0in addition to those already discussed in RFC3315 and RFC3633." > > > - Jouni > > > On Feb 9, 2012, at 8:43 AM, Magnus Nystr=F6m wrote: > >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. =A0These 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. >> >> This document defines a method for DHCPv6 routers to exclude a prefix >> out of a delegated set of prefixes. >> >> I have no comments on the document itself but the Security >> Considerations section is very terse. If the method in this draft does >> not introduce any new security considerations beyond those already >> present in RFC 3315 or RFC 3633 then it should at least say so. It >> appears to me however that something could be said about >> authenticating the request to exclude a particular prefix? >> >> -- Magnus > --=20 -- Magnus From bill.wu@huawei.com Thu Feb 9 02:26:18 2012 Return-Path: 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 6775121F86FD; Thu, 9 Feb 2012 02:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.895 X-Spam-Level: X-Spam-Status: No, score=-5.895 tagged_above=-999 required=5 tests=[AWL=0.704, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOp5kxsckMuB; Thu, 9 Feb 2012 02:26:17 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8E38921F86F2; Thu, 9 Feb 2012 02:26:17 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ4006KJFNJQ6@szxga03-in.huawei.com>; Thu, 09 Feb 2012 18:26:07 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ4009LWFNJKE@szxga03-in.huawei.com>; Thu, 09 Feb 2012 18:26:07 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGT09653; Thu, 09 Feb 2012 18:26:07 +0800 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 09 Feb 2012 18:26:00 +0800 Received: from w53375q (10.138.41.130) by szxeml418-hub.china.huawei.com (10.82.67.157) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 09 Feb 2012 18:11:40 +0800 Date: Thu, 09 Feb 2012 18:11:38 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Radia Perlman , The IESG , secdir@ietf.org, draft-ietf-hokey-erp-aak.all@tools.ietf.org Message-id: <0BD5C6E31FDC4BDC9813D221CD296680@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: X-Mailman-Approved-At: Thu, 09 Feb 2012 02:30:40 -0800 Subject: Re: [secdir] SECDIR review of draft-ietf-hokey-erp-aak X-BeenThere: secdir@ietf.org 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: Thu, 09 Feb 2012 10:26:18 -0000 Hi, Radia: Thank for your valuable review. please see my replies inline. Regards! -Qin ----- Original Message ----- From: "Radia Perlman" To: "The IESG" ; ; Sent: Thursday, February 09, 2012 2:38 PM Subject: SECDIR review of draft-ietf-hokey-erp-aak > 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. > > This is mostly OK technically, but sloppily written. It's about giving a MH > the keys to a new access point after a handoff. > > Starting from section 3..."Peer" is sometimes called "MH" (mobile host). It's > preferable to use a single term, and I'd prefer MH (since it's not clear who > the MH is peer with in this protocol). [Qin]: Okay. We can use MH for terminology consistency. > > I found it surprising that the SAP knows where the MH will roam to. I'd think > that the MH would need to see a new CAP and tell its SAP who it wants to connect > with, or that the MH finds the CAP and tells the CAP who its SAP is/was. [Qin]: SAP doesn't know where the MH will roam to. But SAP knows which CAP is adjacent to itself and therefore SAP can provide the MH a list of CAPs which are all neighbor of that SAP via EAP-Initiate/Re-auth-Start message. Then MH can override CAP list carried in the EAP-Initiate/Re-auth-Start message and send a new CAP list using EAP-Initiate/Re-auth message to backend server through SAP. We can add some text to make this clear if you believe this addresses your concern. > Under figure 6, it says "The x flag is reserved. It MUST be set to 0". > Shouldn't the document say "and ignored on receipt"? [Qin]: Agree, will fix this by following your suggestion. Thanks. > There are various values that say TBD in the spec, but in the IANA > considerations, > there are values. So shouldn't they be copied into the spec instead of TBD? > Also, not all the TBD values are listed in the IANA considerations. [Qin]: Okay. > In the 4th paragraph before section 5.3, it talks about computing an integrity > checksum over the ERP/AAK packet, excluding the authentication tag field. > Does this mean that the authentication tag field is zeroed out for the > computation, > or that the message is truncated to exclude that field? [Qin]: I think it is the latter case. The integrity checksum over ERP/AAK packet is computed from the first bit of code field of packet to the last bit of cryptosuit field of the packet which is placed before authenticator tag field. > In the paragraph before section 5.3, it talks about silently discarding the > EAP-Initiate/Re-auth packet if it's not supported by the SAP. On a silent > discard, how long do you wait for a response before assuming there won't be any, > or perhaps that it got lost? (does it run over a reliable Transport? Even so, > it might be silently discarded). [Qin]: That's a good point. In the case of SAP initiating ERP/AAK, this is not a issue since SAP has already support ERP/AAK. In the case of Peer initiating ERP/AAK, the peer should maintain retransmission timer and maximum retransmission times. Based on retransmission timeout estimation, the peer can know there won't be any response. Does this address your comment? > There's also lots of minor typos. Should be proof-read. [Qin]: Okay, will fix this in the update. Thanks. > Radia From jouni.nospam@gmail.com Thu Feb 9 07:31:22 2012 Return-Path: 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 D60CC21F870A; Thu, 9 Feb 2012 07:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEgqF6Tu-yET; Thu, 9 Feb 2012 07:31:22 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6269021F8593; Thu, 9 Feb 2012 07:31:21 -0800 (PST) Received: by lahl5 with SMTP id l5so1860817lah.31 for ; Thu, 09 Feb 2012 07:31:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0FYmagLy9/0hB2KQhXQAxRyYgLa2ESYUDprCTd2E+E4=; b=r6cOROOQ7k7BrHP4SxXHhG5RpR0xJQrmsE8dqOJxABX2YHqnLTH67z51MvStOfGzUF 8ohsw9YsBao4edleKtfv1WWJEW0L0Rl5CzRjRRcd+8UZE5na5CTDINUO+3h+GrpfiPFT 6LoCMSRfa2lxjoM7P/c3JoznNesB1MRemn0d8= Received: by 10.112.84.1 with SMTP id u1mr765706lby.35.1328801480346; Thu, 09 Feb 2012 07:31:20 -0800 (PST) Received: from a88-114-172-138.elisa-laajakaista.fi (a88-114-172-138.elisa-laajakaista.fi. [88.114.172.138]) by mx.google.com with ESMTPS id i9sm2418381lbz.3.2012.02.09.07.31.18 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Feb 2012 07:31:19 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: Date: Thu, 9 Feb 2012 17:31:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-dhc-pd-exclude@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-dhc-pd-exclude-04 X-BeenThere: secdir@ietf.org 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: Thu, 09 Feb 2012 15:31:23 -0000 Hi, That works for me. I'll do the update in the next revision. - Jouni On Feb 9, 2012, at 9:38 AM, Magnus Nystr=F6m wrote: > Thanks Jouni; the text in RFC 3633 looks great. Maybe you could update > the security considerations section in your draft to say (add after > current last sentence): >=20 > "In particular, RFC 3633 provides recommendations for protection > against prefix delegation attacks. This specification does not add any > new security considerations beyond those provided by RFC 3633." >=20 >=20 > ? This way, the reader will immediately know that it is covered by = 3633. >=20 > -- Magnus >=20 > On Wed, Feb 8, 2012 at 11:24 PM, jouni korhonen = wrote: >>=20 >> Magnus, >>=20 >> Thank you for your review. Regarding the authentication of the = excluded >> prefix. I admit the security considerations text is thin but, for = example, >> RFC3633 security considerations that we refer to already says: >>=20 >> To guard against attacks through prefix delegation, requesting >> routers and delegating routers SHOULD use DHCP authentication as >> described in section 21, "Authentication of DHCP messages" of RFC >> 3315. For point to point links, where one trusts that there is no >> man in the middle, or one trusts layer two authentication, DHCP >> authentication or IPsec may not be necessary. Because a requesting >>=20 >> We did not come up with anything more specific that should be added. >> Does the above address your concern regarding excluded prefix = authentication? >>=20 >> We can add a sentence to the Security considerations saying: >>=20 >> "This specification does not add any new security considerations >> in addition to those already discussed in RFC3315 and RFC3633." >>=20 >>=20 >> - Jouni >>=20 >>=20 >> On Feb 9, 2012, at 8:43 AM, Magnus Nystr=F6m wrote: >>=20 >>> 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. >>>=20 >>> This document defines a method for DHCPv6 routers to exclude a = prefix >>> out of a delegated set of prefixes. >>>=20 >>> I have no comments on the document itself but the Security >>> Considerations section is very terse. If the method in this draft = does >>> not introduce any new security considerations beyond those already >>> present in RFC 3315 or RFC 3633 then it should at least say so. It >>> appears to me however that something could be said about >>> authenticating the request to exclude a particular prefix? >>>=20 >>> -- Magnus >>=20 >=20 >=20 >=20 > --=20 > -- Magnus From yaronf.ietf@gmail.com Thu Feb 9 09:43:48 2012 Return-Path: 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 4AE6121E8021; Thu, 9 Feb 2012 09:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.836 X-Spam-Level: X-Spam-Status: No, score=-102.836 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_BEZEQINT_B=0.763, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYAJH66EcHo8; Thu, 9 Feb 2012 09:43:47 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5642A21E8014; Thu, 9 Feb 2012 09:43:47 -0800 (PST) Received: by werm10 with SMTP id m10so1934078wer.31 for ; Thu, 09 Feb 2012 09:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=8edL5GMjNCHrrFOOjOC4pnPsE4OuJwZ+cX8uq61bGEk=; b=RGRZMGOivO6u37kU1Rut3VM1MoE1fESrGfIoD9bAB3Uzbs6AQb9olWA4t2uQUJrlmz na44dQ8m4kwAQ7vNScTiMcFftrnyijZGNRo7b8lVYKO9qrb8dWk/dM6KPw5wgJ91JQMH 0xUP/CmJDI/y/zoNykWlt/TTB4qAa5VSVcwuk= Received: by 10.180.104.4 with SMTP id ga4mr34404263wib.17.1328809426587; Thu, 09 Feb 2012 09:43:46 -0800 (PST) Received: from [192.168.3.141] (bzq-218-164-247.red.bezeqint.net. [81.218.164.247]) by mx.google.com with ESMTPS id q7sm8135625wix.5.2012.02.09.09.43.45 (version=SSLv3 cipher=OTHER); Thu, 09 Feb 2012 09:43:45 -0800 (PST) Message-ID: <4F3405D0.7010603@gmail.com> Date: Thu, 09 Feb 2012 19:43:44 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: secdir@ietf.org, draft-ietf-dhc-dhcpv4-bulk-leasequery.all@tools.ietf.org, iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir review of draft-ietf-dhc-dhcpv4-bulk-leasequery-05 X-BeenThere: secdir@ietf.org 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: Thu, 09 Feb 2012 17:43:48 -0000 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. The document defines a protocol extension that allows infrastructure components in DSL/cable networks to query a master DHCP server for its static and/or dynamic bindings, to allow them to quickly recovery after reboot. Summary In my opinion, a major security issue is not covered sufficiently. Details I have not reviewed the protocol itself in depth. However I believe that it suffers from the "recursive security considerations" syndrome, where the current draft depends on RFC 4388 (6 years old) for its security, which in turn refers to RFC 3118 (11 years old) for parts of its security. IMHO the relevant threats for a bulk DHCP query are very different from those that RFC 3118 considered for generic DHCP. I worry most about the privacy implications: if I am a subscriber in Smalltown, pop. 10,000, I may be sharing a single DHCP server with the entire population. If any subscriber can issue a bulk query for the whole town once every hour, and thereby map any IP address to a MAC address, this has a serious effect on subscribers' privacy. This is what the current draft says about access control: Servers MAY restrict Bulk Leasequery connections and DHCPBULKLEASEQUERY messages to certain requestors. Connections not from permitted requestors SHOULD be closed immediately, to avoid server connection resource exhaustion. Servers MAY restrict some requestors to certain query types. Servers MAY reply to queries that are not permitted with the DHCPLEASEQUERYDONE message with a status-code option status of NotAllowed, or MAY simply close the connection. This IMHO is way too weak, specifically the first MAY. The Security Considerations refer to RFC 4388 for "restriction to trusted requestors", but I couldn't find any relevant language there either, other than a reference to RFC 3118. Thanks, Yaron From radiaperlman@gmail.com Thu Feb 9 10:51:31 2012 Return-Path: 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 ACD9021F865D; Thu, 9 Feb 2012 10:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.678 X-Spam-Level: X-Spam-Status: No, score=-3.678 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5rNdKvokII2; Thu, 9 Feb 2012 10:51:30 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 49EB921F865A; Thu, 9 Feb 2012 10:51:30 -0800 (PST) Received: by eaal12 with SMTP id l12so674097eaa.31 for ; Thu, 09 Feb 2012 10:51:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3T4Lj/eL6Ino3iBpBYYqh4VQf5TGd3zirfrZ5KkZodE=; b=IPLVvt1d0FvWdc7IZwqeEEwRN6wggC3KFsQpUPUYd4KM+uojeN8+6c7bSn1Blq+0dk QnUqz/37rgiFn7COUQp9T4Nyasn//Sl/22QC3nud16lWt8+evC8BCbgDYDm+6Hy87vt7 G+4NrClS1ISaqVfT8L1r0d+5mDpXmSyPne2ns= MIME-Version: 1.0 Received: by 10.213.29.73 with SMTP id p9mr569331ebc.138.1328813489339; Thu, 09 Feb 2012 10:51:29 -0800 (PST) Received: by 10.213.16.205 with HTTP; Thu, 9 Feb 2012 10:51:29 -0800 (PST) In-Reply-To: <0BD5C6E31FDC4BDC9813D221CD296680@china.huawei.com> References: <0BD5C6E31FDC4BDC9813D221CD296680@china.huawei.com> Date: Thu, 9 Feb 2012 10:51:29 -0800 Message-ID: From: Radia Perlman To: Qin Wu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-hokey-erp-aak.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-hokey-erp-aak X-BeenThere: secdir@ietf.org 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: Thu, 09 Feb 2012 18:51:31 -0000 Inline >> In the 4th paragraph before section 5.3, it talks about computing an int= egrity >> checksum over the ERP/AAK packet, excluding the authentication tag field= . >> Does this mean that the authentication tag field is zeroed out for the >> computation, >> or that the message is truncated to exclude that field? > > [Qin]: I think it is the latter case. The integrity checksum over ERP/AAK= packet is computed > from the first bit of code field of packet to the last bit of cryptosuit = field of the packet which > =A0is placed before authenticator tag field. I don't care which it is. But the document has to specify. I assume when answering me, you were also going to specify it in the document. :-) > >> In the paragraph before section 5.3, it talks about silently discarding = the >> EAP-Initiate/Re-auth packet if it's not supported by the SAP. =A0On a si= lent >> discard, how long do you wait for a response before assuming there won't= be any, >> or perhaps that it got lost? (does it run over a reliable Transport? =A0= Even so, >> it might be silently discarded). > > [Qin]: That's a good point. In the case of SAP initiating ERP/AAK, this i= s not a issue since SAP has > already support ERP/AAK. In the case of Peer initiating ERP/AAK, the peer= should maintain > retransmission timer and maximum retransmission times. Based on retransmi= ssion timeout estimation, > =A0the peer can know there won't be any response. Does this address your = comment? That is somewhat significant text (not just a typo), but I assume you'll get it right. Radia From volz@cisco.com Thu Feb 9 10:58:16 2012 Return-Path: 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 0284521F8762; Thu, 9 Feb 2012 10:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8HQHmge2rdS; Thu, 9 Feb 2012 10:58:15 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 19E4121F8760; Thu, 9 Feb 2012 10:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3079; q=dns/txt; s=iport; t=1328813895; x=1330023495; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=L5FPpEoIzATToO3CnSraeN+s8fF5MeA8sBG/r4YNmpc=; b=kHk3pQfM8bAR3/uM4DmlzaDphK/NmETS7cCTQgH11h3sLLtgDQEzvtTe 3zaHmpz01/oR6Gs6G4brEl59YTi05fhmoOYwqUuQ8HglTefcMxgUE2zqN z7VUrkw7Hj6D8GYu3bTSdVUpy4yQbArWZoMNlww8ovBVNx2tfUQaKW5i8 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAF4WNE+tJXHA/2dsb2JhbABEr1yBB4FyAQEBBBIBHQpLBAIBCBEEAQELBhcBBgEgJQkIAQEEARIIGqIZAZ8ZiDaDIAIFAggPAhIBAgUFCAM3h0ZjBIhIl3eHcg X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="55090987" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 09 Feb 2012 18:58:14 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q19IwEhu000880; Thu, 9 Feb 2012 18:58:14 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 12:58:14 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Feb 2012 12:58:14 -0600 Message-ID: In-Reply-To: <4F3405D0.7010603@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SecDir review of draft-ietf-dhc-dhcpv4-bulk-leasequery-05 Thread-Index: AcznUmlqvI4foktVSJSjlhzJitx4lAACJJWg References: <4F3405D0.7010603@gmail.com> From: "Bernie Volz (volz)" To: "Yaron Sheffer" , , , X-OriginalArrivalTime: 09 Feb 2012 18:58:14.0600 (UTC) FILETIME=[C6D8B480:01CCE75C] X-Mailman-Approved-At: Thu, 09 Feb 2012 10:59:39 -0800 Subject: Re: [secdir] SecDir review of draft-ietf-dhc-dhcpv4-bulk-leasequery-05 X-BeenThere: secdir@ietf.org 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: Thu, 09 Feb 2012 18:58:16 -0000 Yaron: Actually, the text used here was used "recently" for RFC 5460 (and also RFC 5007) - the DHCPv6 Leasequery. As this is the only use of TCP for DHCPv4, it really should be strongly recommended that firewalls block any 'external' (from subscribers/Internet) TCP traffic to the bulk leasequery port. This should be much easier to secure than UDP based traffic - as the 4388 leasequery and normal DHCP traffic both happen over the same UDP port and it is hard to filter 'all' traffic as clients do need to communicate directly with the DHCP server. - Bernie -----Original Message----- From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]=20 Sent: Thursday, February 09, 2012 12:44 PM To: secdir@ietf.org; draft-ietf-dhc-dhcpv4-bulk-leasequery.all@tools.ietf.org; iesg@ietf.org Subject: SecDir review of draft-ietf-dhc-dhcpv4-bulk-leasequery-05 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. The document defines a protocol extension that allows infrastructure components in DSL/cable networks to query a master DHCP server for its static and/or dynamic bindings, to allow them to quickly recovery after reboot. Summary In my opinion, a major security issue is not covered sufficiently. Details I have not reviewed the protocol itself in depth. However I believe that it suffers from the "recursive security considerations" syndrome, where the current draft depends on RFC 4388 (6 years old) for its security, which in turn refers to RFC 3118 (11 years old) for parts of its security. IMHO the relevant threats for a bulk DHCP query are very different from those that RFC 3118 considered for generic DHCP. I worry most about the privacy implications: if I am a subscriber in Smalltown, pop. 10,000, I may be sharing a single DHCP server with the entire population. If any subscriber can issue a bulk query for the whole town once every hour, and thereby map any IP address to a MAC address, this has a serious effect on subscribers' privacy. This is what the current draft says about access control: Servers MAY restrict Bulk Leasequery connections and DHCPBULKLEASEQUERY messages to certain requestors. Connections not from permitted requestors SHOULD be closed immediately, to avoid server connection resource exhaustion. Servers MAY restrict some requestors to certain query types. Servers MAY reply to queries that are not permitted with the DHCPLEASEQUERYDONE message with a status-code option status of NotAllowed, or MAY simply close the connection. This IMHO is way too weak, specifically the first MAY. The Security Considerations refer to RFC 4388 for "restriction to trusted requestors", but I couldn't find any relevant language there either, other than a reference to RFC 3118. Thanks, Yaron From bill.wu@huawei.com Thu Feb 9 17:26:02 2012 Return-Path: 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 5F3D511E8094; Thu, 9 Feb 2012 17:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.907 X-Spam-Level: X-Spam-Status: No, score=-5.907 tagged_above=-999 required=5 tests=[AWL=0.692, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjHRJJaAetav; Thu, 9 Feb 2012 17:26:01 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id AD79B11E8079; Thu, 9 Feb 2012 17:26:01 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ500CLLLB20Z@szxga03-in.huawei.com>; Fri, 10 Feb 2012 09:25:50 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ500E8MLB2P8@szxga03-in.huawei.com>; Fri, 10 Feb 2012 09:25:50 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGZ88683; Fri, 10 Feb 2012 09:25:12 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 10 Feb 2012 09:25:00 +0800 Received: from w53375q (10.138.41.130) by szxeml402-hub.china.huawei.com (10.82.67.32) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 10 Feb 2012 09:25:03 +0800 Date: Fri, 10 Feb 2012 09:25:02 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Radia Perlman Message-id: <468389BD4CC24892A8094B8A3D1C6EFE@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <0BD5C6E31FDC4BDC9813D221CD296680@china.huawei.com> Cc: draft-ietf-hokey-erp-aak.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-hokey-erp-aak X-BeenThere: secdir@ietf.org 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: Fri, 10 Feb 2012 01:26:02 -0000 Hi, Radia: We will impement the clarification texts into the update to fix the issues you pointed out below. Thank you again. Regards! -Qin ----- Original Message ----- From: "Radia Perlman" To: "Qin Wu" Cc: "The IESG" ; ; Sent: Friday, February 10, 2012 2:51 AM Subject: Re: SECDIR review of draft-ietf-hokey-erp-aak Inline >> In the 4th paragraph before section 5.3, it talks about computing an integrity >> checksum over the ERP/AAK packet, excluding the authentication tag field. >> Does this mean that the authentication tag field is zeroed out for the >> computation, >> or that the message is truncated to exclude that field? > > [Qin]: I think it is the latter case. The integrity checksum over ERP/AAK packet is computed > from the first bit of code field of packet to the last bit of cryptosuit field of the packet which > is placed before authenticator tag field. I don't care which it is. But the document has to specify. I assume when answering me, you were also going to specify it in the document. :-) > >> In the paragraph before section 5.3, it talks about silently discarding the >> EAP-Initiate/Re-auth packet if it's not supported by the SAP. On a silent >> discard, how long do you wait for a response before assuming there won't be any, >> or perhaps that it got lost? (does it run over a reliable Transport? Even so, >> it might be silently discarded). > > [Qin]: That's a good point. In the case of SAP initiating ERP/AAK, this is not a issue since SAP has > already support ERP/AAK. In the case of Peer initiating ERP/AAK, the peer should maintain > retransmission timer and maximum retransmission times. Based on retransmission timeout estimation, > the peer can know there won't be any response. Does this address your comment? That is somewhat significant text (not just a typo), but I assume you'll get it right. Radia From new-work-bounces@ietf.org Fri Feb 10 10:11:04 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6703821F87CF; Fri, 10 Feb 2012 10:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328897464; bh=87+sTVq7yNNoQPCpTunqU5vpb9ibCYaTqEYt4oKu0p4=; h=From:Date:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=QQUWIhWDdAc1w8kPZKEjb7l44c4/Ks6eKVtbkSLRlSabIt80Qn8+aOPlDfUBykmx/ h7eGYtxHpXFW92OQ39xxoDG+sGsmuYIIJKDqOkDgsX3JlhdYNhDo0c5/de4FR0cG0W 2cv2fgwScaOb0akHD69ofvTgc/GgRY2YOWaohjG4= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E76E21F87CF for ; Fri, 10 Feb 2012 10:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlZFiGzp45Tp for ; Fri, 10 Feb 2012 10:11:01 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id B72EB21F87D4 for ; Fri, 10 Feb 2012 10:11:00 -0800 (PST) Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Rvuvz-00089f-BX; Fri, 10 Feb 2012 13:10:59 -0500 From: Ian Jacobs Date: Fri, 10 Feb 2012 12:10:58 -0600 To: new-work@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 10 Feb 2012 10:23:50 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Web Cryptography Working Group (until 2012-03-15) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 18:11:04 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Security Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Web Cryptography Working Group: http://www.w3.org/2011/11/webcryptography-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2012-03-15 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Thomas Roessler, Security Activity Lead . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/Security/Activity.html [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Feb 14 14:23:32 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA6121E8115; Tue, 14 Feb 2012 14:23:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329258212; bh=m/atpb15WvjXF1GKVob5sfby91oEtCDMB3/fHDKUERE=; h=From:To:Mime-Version:Message-Id:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=y/p4Ewa44azk9ZiZO3DcV5Hps17nsnPCtd0ME7bnpdp5KVfFhwKE96zQdeVI7kQlF UuM4N00cJO6vJbPIlVaJnhBXI0bLTtmqwiEi17agi3R6NMUVsKj1GUKnnSlv6e7jF0 IP0DUDuftmCk+6h5dF7x90+WHCcFIF+wB22QWcBE= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id DD2D721E811E; Tue, 14 Feb 2012 14:23:24 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20120214222325.DD2D721E811E@ietfa.amsl.com> Date: Tue, 14 Feb 2012 14:23:24 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 15 Feb 2012 09:09:54 -0800 Subject: [secdir] [new-work] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 22:23:33 -0000 A modified charter has been submitted for the Locator/ID Separation Protocol (lisp) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Thursday, March 1, 2011. Locator/ID Separation Protocol (lisp) ------------------------------------- Current Status: Active Last updated: 2012-02-14 Chairs: Joel Halpern Terry Manderson Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Secretaries: Wassim Haddad Luigi Iannone Mailing Lists: General Discussion: lisp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: http://www.ietf.org/mail-archive/web/lisp/current/maillist.html Description of Working Group: The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "locator/identifier separation". The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. A number of approaches are being looked at in parallel in other contexts. The IRTF RRG examined several proposals, some of which were published as IRTF-track Experimental RFCs. The LISP WG has completed the first set of Experimental RFCs describing the Locator/ID Separation Protocol. LISP requires no changes to end-systems or to routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol. The LISP WG is chartered to continue work on the LISP base protocol, completing the ongoing work, and any items which directly impact LISP protocol structures and which are related to using LISP for improving Internet routing scalability. Specifically, the group will work on: - Architecture description: This document will describe the architecture of the entire LISP system, making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. - Deployment models: This document will describe what kind of deployments can be expected for LISP, and give operational advice on how they can be set up. - A description of the impacts of LISP: This document will describe the problems that LISP is intended to address and the impacts that employing LISP has. While the work on LISP was initiated by Internet routing scaling concerns, there has also been an interest on improved solutions to a number of different problems, such as traffic engineering. This document should describe problem areas (such as scaling or traffic engineer) where LISP is expected to have a positive effect, as well as any tradeoffs that are caused by LISP's design. - LISP security threats and solutions: This document will describe the security analysis of the LISP system, what issues it needs to protect against, and a solution that helps defend against those issues. The replay attack problem discussed on the mailing list should be included in this work. - Allocation of Endpoint IDentifier (EID) space: This document requests address space to be used for the LISP experiment as identifier space - Alternate mapping system designs: Develop alternative mapping designs to be tested. - Data models for management of LISP. The first three items need to be completed first before other items can be submitted as RFCs. The three first documents also need to complement each other, by describing how the architecture supports a solution for a particular problem area and how the solution can be deployed to help with that problem. In addition, if work chartered in some other IETF WG requires changes in the LISP base protocol or any items which directly impact LISP protocol structures, then the LISP WG is chartered to work on such changes. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF to understand which type of a solution is optimal. The LISP WG is not chartered to develop a standard solution for solving the routing scalability problem at this time. The specifications developed by the WG are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. Goals and Milestones September 2012: Submit an architecture description to the IESG for publication as an Experimental RFC September 2012: Submit a deployment model document to the IESG for publication as an Experimental RFC September 2012: Submit a LISP impact discussion document to the IESG for publication as an Experimental RFC October 2012: Submit a LISP threats analysis document to the IESG for publication as an Experimental RFC October 2012: Submit an EID allocation document to the IESG for publication as an Experimental RFC January 2013: Submit an lternate mapping system designs to the IESG for publication as an Experimental RFC March 2013: Submit a data model (e.g., a MIB) document to the IESG for publication as an Experimental RFC _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From weiler+secdir@watson.org Wed Feb 15 15:29:42 2012 Return-Path: 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 CC34221E8086; Wed, 15 Feb 2012 15:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Wq87JgM8iPa; Wed, 15 Feb 2012 15:29:42 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 410C321E8085; Wed, 15 Feb 2012 15:29:41 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q1FNTcOY054726; Wed, 15 Feb 2012 18:29:39 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q1FNTb9e054712; Wed, 15 Feb 2012 18:29:38 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 15 Feb 2012 18:29:37 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org, iesg@ietf.org, draft-george-travel-faq.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Wed, 15 Feb 2012 18:29:39 -0500 (EST) Subject: [secdir] secdir review of draft-george-travel-faq X-BeenThere: secdir@ietf.org 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: Wed, 15 Feb 2012 23:29:42 -0000 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. This is not a protocol spec, nothing in it impacts security, and the doc (correctly) says as much. Overall, the text is quite reasonable. I sent a couple of very minior suggestions to the author. I was a bit puzzled by the status of the doc. Last week the datatracker showed that this was in RFC Editor state ISR (independent submission review), but the IESG issued a last call. It looks like the doc is being published through the IETF now and not as an independent submission, and the tracker no longer shows that RFC Editor state. -- Sam From kkinnear@cisco.com Thu Feb 16 07:40:44 2012 Return-Path: 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 7F97121F87FC; Thu, 16 Feb 2012 07:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.799 X-Spam-Level: X-Spam-Status: No, score=-8.799 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vprBHk2LNG4; Thu, 16 Feb 2012 07:40:40 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4612621F87AD; Thu, 16 Feb 2012 07:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kkinnear@cisco.com; l=4822; q=dns/txt; s=iport; t=1329406840; x=1330616440; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=wW3CqdsNLB+YBeCKk8ft0fIVekUrzvJZtjEgVSycEwE=; b=Sg4TxWPRVtNlFPfLaPSXmMkCHkxAXqLoiUU05jmlm5E82P2OFlOmBLK6 sWfPPX3hrk3kFXZQ1abmYi923kd9tZsFbRoNzqn80wW0K8izS+lTGMMnP 8HpyWfjKVtrXQvtmZmzylYfPYel0BE8X58rV+qEPceT0avelISpVRakJe U=; X-IronPort-AV: E=Sophos;i="4.73,430,1325462400"; d="scan'208";a="59464365" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 16 Feb 2012 15:40:40 +0000 Received: from [161.44.65.167] ([161.44.65.167]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1GFed3U011545; Thu, 16 Feb 2012 15:40:39 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Kim Kinnear In-Reply-To: <4F3405D0.7010603@gmail.com> Date: Thu, 16 Feb 2012 10:40:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3405D0.7010603@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1084) Cc: secdir@ietf.org, draft-ietf-dhc-dhcpv4-bulk-leasequery.all@tools.ietf.org, iesg@ietf.org, Kim Kinnear Subject: Re: [secdir] SecDir review of draft-ietf-dhc-dhcpv4-bulk-leasequery-05 X-BeenThere: secdir@ietf.org 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: Thu, 16 Feb 2012 15:40:44 -0000 Yaron, On Feb 9, 2012, at 12:43 PM, Yaron Sheffer wrote: > 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. >=20 > The document defines a protocol extension that allows infrastructure = components in DSL/cable networks to query a master DHCP server for its = static and/or dynamic bindings, to allow them to quickly recovery after = reboot. >=20 > Summary >=20 > In my opinion, a major security issue is not covered sufficiently. >=20 > Details >=20 > I have not reviewed the protocol itself in depth. However I believe = that it suffers from the "recursive security considerations" syndrome, = where the current draft depends on RFC 4388 (6 years old) for its = security, which in turn refers to RFC 3118 (11 years old) for parts of = its security. IMHO the relevant threats for a bulk DHCP query are very = different from those that RFC 3118 considered for generic DHCP. For what it is worth, the security section for this draft is taken essentially verbatim from RFC 5460, DHCPv6 Bulk Leasequery. But I assume that we must be raising the bar here, since that was 3 years ago. >=20 > I worry most about the privacy implications: if I am a subscriber in = Smalltown, pop. 10,000, I may be sharing a single DHCP server with the = entire population. If any subscriber can issue a bulk query for the = whole town once every hour, and thereby map any IP address to a MAC = address, this has a serious effect on subscribers' privacy. >=20 > This is what the current draft says about access control: >=20 > Servers MAY restrict Bulk Leasequery connections and = DHCPBULKLEASEQUERY messages to certain requestors. Connections not from = permitted requestors SHOULD be closed immediately, to avoid server = connection resource exhaustion. Servers MAY restrict some requestors to = certain query types. Servers MAY reply to queries that are not = permitted with the DHCPLEASEQUERYDONE message with a status-code option = status of NotAllowed, or MAY simply close the connection. >=20 > This IMHO is way too weak, specifically the first MAY. The Security = Considerations refer to RFC 4388 for "restriction to trusted = requestors", but I couldn't find any relevant language there either, = other than a reference to RFC 3118. The theory behind all of this is that you should not allow TCP connections to the DHCPv4 ports from any devices or programs that are not part of your infrastructure. In almost all cases, the actual DHCP server isn't involved in the configuration of these restrictions, but rather these restrictions are imposed by network elements at a deeper level of the network than the DHCPv4 server (which is, after all, most usually an application running on a standard operating system). Of course, that doesn't mean that we shouldn't give people guidance as to what is important to restrict and what isn't. It seems a bit ... unenforceable .. to say that DHCPv4 servers which implement the Bulk Leasequery capability MUST be installed in environments where it is possible to configure access to the Bulk Leasequery capability only to trusted network components.d But I'll give it a try, below. I can certainly uplift the paragraph above on access control to SHOULD (and replicate it in the Security section), like this: >=20 > Servers SHOULD restrict Bulk Leasequery connections and > DHCPBULKLEASEQUERY messages to certain requestors, either > through explicit configuration of the Server itself or by > employing external network elements to provide such > restrictions. In particular, the typical DHCPv4 client SHOULD > NOT be allowed to receive a response to a Bulk Leasequery > request, and some technique MUST exist to allow prevention of > such access in any environment where Bulk Leasequery is > deployed. >=20 > Connections not from permitted requestors SHOULD be > closed immediately, to avoid server connection resource > exhaustion or alternatively, simply not be allowed to reach > the server at all. Servers SHOULD have the capability to > restrict certain requestors to certain query types. Servers > MAY reply to queries that are not permitted with the > DHCPLEASEQUERYDONE message with a status-code option status > of NotAllowed, or MAY simply close the connection. Would this change sufficiently mitigate your concerns regarding this draft? Regards -- Kim >=20 >=20 > Thanks, > Yaron >=20 From yaronf.ietf@gmail.com Thu Feb 16 07:49:59 2012 Return-Path: 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 5C69221F85C4; Thu, 16 Feb 2012 07:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jF2KLG4UAEBH; Thu, 16 Feb 2012 07:49:58 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id ACC6421F85D5; Thu, 16 Feb 2012 07:49:57 -0800 (PST) Received: by eekc41 with SMTP id c41so869170eek.31 for ; Thu, 16 Feb 2012 07:49:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hvJLTc89Jj65TTfuZE/WRBq4F4szj2fiKZASuzujRiY=; b=gxLYUl0Y/WUxIz3LZv2cJPADpf3DyjWog1nGRCepxlApjVfA9m9BZ8BbViKxScsVbl MsmYp36HJjSqZfuuT1g38ip0Xx7Tzwq5Y5y7DUvZbnW2UA/zhvZqHJsmJIpIZ3+Rf7QK UOZbdW7q+BH26YUlRMMb2GlOPi5+kVax2kZzE= Received: by 10.112.84.1 with SMTP id u1mr1147029lby.35.1329407396652; Thu, 16 Feb 2012 07:49:56 -0800 (PST) Received: from [192.168.7.200] (89-139-10-131.bb.netvision.net.il. [89.139.10.131]) by mx.google.com with ESMTPS id od2sm6354258lab.11.2012.02.16.07.49.54 (version=SSLv3 cipher=OTHER); Thu, 16 Feb 2012 07:49:55 -0800 (PST) Message-ID: <4F3D25A0.1060302@gmail.com> Date: Thu, 16 Feb 2012 17:49:52 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Kim Kinnear References: <4F3405D0.7010603@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-dhc-dhcpv4-bulk-leasequery.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-dhc-dhcpv4-bulk-leasequery-05 X-BeenThere: secdir@ietf.org 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: Thu, 16 Feb 2012 15:49:59 -0000 Hi Kim, thanks for the new text. Yes, it does mitigate my concerns. Regards, Yaron On 02/16/2012 05:40 PM, Kim Kinnear wrote: > > Yaron, > > > On Feb 9, 2012, at 12:43 PM, Yaron Sheffer wrote: > >> 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. >> >> The document defines a protocol extension that allows infrastructure components in DSL/cable networks to query a master DHCP server for its static and/or dynamic bindings, to allow them to quickly recovery after reboot. >> >> Summary >> >> In my opinion, a major security issue is not covered sufficiently. >> >> Details >> >> I have not reviewed the protocol itself in depth. However I believe that it suffers from the "recursive security considerations" syndrome, where the current draft depends on RFC 4388 (6 years old) for its security, which in turn refers to RFC 3118 (11 years old) for parts of its security. IMHO the relevant threats for a bulk DHCP query are very different from those that RFC 3118 considered for generic DHCP. > > For what it is worth, the security section for this draft > is taken essentially verbatim from RFC 5460, DHCPv6 Bulk > Leasequery. But I assume that we must be raising the bar > here, since that was 3 years ago. >> >> I worry most about the privacy implications: if I am a subscriber in Smalltown, pop. 10,000, I may be sharing a single DHCP server with the entire population. If any subscriber can issue a bulk query for the whole town once every hour, and thereby map any IP address to a MAC address, this has a serious effect on subscribers' privacy. > >> >> This is what the current draft says about access control: >> >> Servers MAY restrict Bulk Leasequery connections and DHCPBULKLEASEQUERY messages to certain requestors. Connections not from permitted requestors SHOULD be closed immediately, to avoid server connection resource exhaustion. Servers MAY restrict some requestors to certain query types. Servers MAY reply to queries that are not permitted with the DHCPLEASEQUERYDONE message with a status-code option status of NotAllowed, or MAY simply close the connection. >> >> This IMHO is way too weak, specifically the first MAY. The Security Considerations refer to RFC 4388 for "restriction to trusted requestors", but I couldn't find any relevant language there either, other than a reference to RFC 3118. > > The theory behind all of this is that you should not > allow TCP connections to the DHCPv4 ports from any > devices or programs that are not part of your > infrastructure. > > In almost all cases, the actual DHCP server isn't > involved in the configuration of these restrictions, but > rather these restrictions are imposed by network elements > at a deeper level of the network than the DHCPv4 server > (which is, after all, most usually an application running > on a standard operating system). > > Of course, that doesn't mean that we shouldn't give > people guidance as to what is important to restrict and > what isn't. > > It seems a bit ... unenforceable .. to say that DHCPv4 > servers which implement the Bulk Leasequery capability > MUST be installed in environments where it is possible to > configure access to the Bulk Leasequery capability only > to trusted network components.d But I'll give it a > try, below. > > I can certainly uplift the paragraph above on access > control to SHOULD (and replicate it in the Security > section), like this: >> >> Servers SHOULD restrict Bulk Leasequery connections and >> DHCPBULKLEASEQUERY messages to certain requestors, either >> through explicit configuration of the Server itself or by >> employing external network elements to provide such >> restrictions. In particular, the typical DHCPv4 client SHOULD >> NOT be allowed to receive a response to a Bulk Leasequery >> request, and some technique MUST exist to allow prevention of >> such access in any environment where Bulk Leasequery is >> deployed. >> >> Connections not from permitted requestors SHOULD be >> closed immediately, to avoid server connection resource >> exhaustion or alternatively, simply not be allowed to reach >> the server at all. Servers SHOULD have the capability to >> restrict certain requestors to certain query types. Servers >> MAY reply to queries that are not permitted with the >> DHCPLEASEQUERYDONE message with a status-code option status >> of NotAllowed, or MAY simply close the connection. > > Would this change sufficiently mitigate your concerns > regarding this draft? > > Regards -- Kim > >> >> >> Thanks, >> Yaron >> > From seonghan.shin@aist.go.jp Thu Feb 16 19:40:44 2012 Return-Path: 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 B2FBD21E806E for ; Thu, 16 Feb 2012 19:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+0vllQRysNM for ; Thu, 16 Feb 2012 19:40:40 -0800 (PST) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD5121E8056 for ; Thu, 16 Feb 2012 19:40:39 -0800 (PST) Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id q1H3eHZm016064; Fri, 17 Feb 2012 12:40:17 +0900 (JST) env-from (seonghan.shin@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1329450018; bh=xboESLrppbYSO+7tourBG069SNAgg4FeSCp+e8aGgzI=; h=From:Date:Message-ID; b=k0a+T9EGNWIvYFAmOhYXS618ZTu2SucI9yxH1ZZFlUgdLUHYIjGIl94jnoA6fDXhP fFG+iBTxlBe0PaPX5eouzeuwfr5iO+en9tzBG0yQLSUcjBrHISM4v5xnkKvgRy5sdD 5OhkfbbjxxiTvWqshYiKdsz+B+95KePvuv05nzIc= Received: from smtp4.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id q1H3eGd2008601; Fri, 17 Feb 2012 12:40:16 +0900 (JST) env-from (seonghan.shin@aist.go.jp) Received: by smtp4.aist.go.jp with ESMTP id q1H3eBjd014425; Fri, 17 Feb 2012 12:40:11 +0900 (JST) env-from (seonghan.shin@aist.go.jp) From: "SeongHan Shin" To: "'Tero Kivinen'" , "'Tina TSOU'" References: <4F20D424.1060901@gmail.com> <20258.43953.678320.842027@fireball.kivinen.iki.fi> In-Reply-To: <20258.43953.678320.842027@fireball.kivinen.iki.fi> Date: Fri, 17 Feb 2012 12:40:16 +0900 Message-ID: <007f01cced25$dcf442b0$96dcc810$@aist.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: ja Thread-index: AQF3vzRYahQsHTw/d2zaNYM5Ipa7XALQ31jOAk7mURgCGsBz7Jaw4WLA X-Mailman-Approved-At: Fri, 17 Feb 2012 01:52:32 -0800 Cc: 'Kaz Kobara' , seonghan.shin@aist.go.jp, draft-shin-augmented-pake@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-shin-augmented-pake-10 X-BeenThere: secdir@ietf.org 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: Fri, 17 Feb 2012 03:40:44 -0000 Dear Tina and Tero, Thank you very much for your comments! The following changes are reflected to a next version of our I-D. > I found some editorial glitches and the use of "temporal" when "temporary" > was intended, but someone else can catch those. Corrected to "temporary" > Reference K11 is now RFC 6467. That means the Notify message type and the > GSPM payload type have now been assigned (16424 and 49 respectively) and > can be inserted into the document where it currently says "TBD". I updated reference K11 to RFC6467 and inserted the assigned values into the document. > The request to IANA names the wrong registry. The correct name is "IKEv2 > Secure Password Methods" registry, established by RFC 6467. Corrected. > > The relationship between this document and RFC 6467 is odd. In the > > ordinary course of events this document would have a normative > > dependency on RFC 6467. > > Not exactly. The original intention is that all documents using numbers > defined in my draft (now RFC6467) would be self-containing, and there might > not even be need for publishing my draft as RFC, it was originally just > written as tool so that all secure password method drafts could coordinate > their numbers. As it is now published as RFC, I think it is ok to make either > normative or non-normative reference to it, depending whether the document > itself is self-containing or not. > > Currently I think all the secure password method documents are > self-containing, thus non-normative reference is needed, the implementor > who is implementing the secure password method in question, does not NEED > to read RFC6467 to be able to implement for example > draft-shin-augmented-pake as that draft already contains all information > needed. > > > It is obvious that the latter was written after the present document, > > and avoidance of the dependency was deliberate on both sides. Still, > > the authors of this document might reconsider, even though RFC 6467 > > would be a down-reference since it is Informational. > > The intended status of draft-shin-augmented-pake is listed as experimental, > so there really a down-reference problem there? > > Anyways as draft-shin-augmented-pake self-contained, the reference can be > non-normative. Thanks, Tero! I just keep reference RFC6467 in non-normative. Best regards, Shin ------------------------------------------------------------------ SeongHan Shin Research Center for Information Security (RCIS), National Institute of Advanced Industrial Science and Technology (AIST), Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan Tel : +81-29-861-2670/5284 Fax : +81-29-861-5285 E-mail : seonghan.shin@aist.go.jp ------------------------------------------------------------------ > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Friday, January 27, 2012 10:51 PM > To: Tina TSOU > Cc: secdir@ietf.org; draft-shin-augmented-pake@tools.ietf.org > Subject: [secdir] SECDIR review of draft-shin-augmented-pake-10 > > Tina TSOU writes: > > The relationship between this document and RFC 6467 is odd. In the > > ordinary course of events this document would have a normative > > dependency on RFC 6467. > > Not exactly. The original intention is that all documents using numbers > defined in my draft (now RFC6467) would be self-containing, and there might > not even be need for publishing my draft as RFC, it was originally just > written as tool so that all secure password method drafts could coordinate > their numbers. As it is now published as RFC, I think it is ok to make either > normative or non-normative reference to it, depending whether the document > itself is self-containing or not. > > Currently I think all the secure password method documents are > self-containing, thus non-normative reference is needed, the implementor > who is implementing the secure password method in question, does not NEED > to read RFC6467 to be able to implement for example > draft-shin-augmented-pake as that draft already contains all information > needed. > > > It is obvious that the latter was written after the present document, > > and avoidance of the dependency was deliberate on both sides. Still, > > the authors of this document might reconsider, even though RFC 6467 > > would be a down-reference since it is Informational. > > The intended status of draft-shin-augmented-pake is listed as experimental, > so there really a down-reference problem there? > > Anyways as draft-shin-augmented-pake self-contained, the reference can be > non-normative. > -- > kivinen@iki.fi From weiler+secdir@watson.org Sat Feb 18 08:48:39 2012 Return-Path: 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 C6E9321F85EC for ; Sat, 18 Feb 2012 08:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9IQbUxJDnbl for ; Sat, 18 Feb 2012 08:48:39 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2338521F85DF for ; Sat, 18 Feb 2012 08:48:38 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q1IGmba1007381 for ; Sat, 18 Feb 2012 11:48:37 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q1IGmalK007374 for ; Sat, 18 Feb 2012 11:48:36 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 18 Feb 2012 11:48:36 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Sat, 18 Feb 2012 11:48:37 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 16:48:39 -0000 A large number of new documents, some already scheduled for the 1 March telechat. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Jeffrey Hutzelman is next in the rotation. For telechat 2012-03-01 Reviewer LC end Draft Alan DeKok T 2012-02-23 draft-ietf-lisp-interworking-04 Donald Eastlake T 2012-02-27 draft-ietf-manet-packetbb-sec-08 Shawn Emery T 2012-02-27 draft-ietf-manet-smf-13 Phillip Hallam-Baker T 2012-02-23 draft-ietf-pcn-3-in-1-encoding-08 Steve Hanna T 2012-02-23 draft-ietf-pcn-encoding-comparison-08 Dan Harkins T 2012-02-27 draft-ietf-pcp-base-23 Hilarie Orman T 2012-03-01 draft-ietf-dnsext-ecdsa-06 Joe Salowey T 2012-02-21 draft-snell-atompub-tombstones-14 Tina TSOU T 2012-02-20 draft-ietf-behave-64-analysis-05 Carl Wallace T 2012-02-21 draft-ietf-netext-pmip-lr-08 Brian Weis T 2012-02-20 draft-ietf-v6ops-v6nd-problems-04 For telechat 2012-03-15 Sam Hartman T 2012-03-13 draft-mcgrew-tls-aes-ccm-03 Last calls and special requests: Derek Atkins 2012-02-28 draft-ietf-adslmib-gbond-mib-09 Rob Austein 2012-02-28 draft-ietf-adslmib-gbond-tdim-mib-07 Richard Barnes 2012-02-28 draft-ietf-core-link-format-11 Dave Cridland 2012-02-23 draft-ietf-l3vpn-mvpn-wildcards-02 Tobias Gondrom 2012-02-29 draft-ietf-mext-mip6-tls-03 Paul Hoffman 2012-03-16 draft-reschke-http-status-308-05 Leif Johansson R2012-02-07 draft-ietf-oauth-v2-23 Barry Leiba 2012-01-13 draft-ietf-pcn-signaling-requirements-08 Tim Polk 2012-02-07 draft-ietf-oauth-v2-bearer-17 Eric Rescorla 2012-02-08 draft-ietf-sieve-notify-sip-message-08 Vincent Roca 2012-02-06 draft-ietf-simple-chat-13 Klaas Wierenga 2012-03-08 draft-desruisseaux-caldav-sched-10 Nico Williams 2012-03-14 draft-garcia-shim6-applicability-03 Tom Yu 2012-02-28 draft-ietf-adslmib-gbond-atm-mib-05 Glen Zorn 2012-02-28 draft-ietf-adslmib-gbond-eth-mib-05 From hartmans@mit.edu Sat Feb 18 10:21:42 2012 Return-Path: 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 4D27721F85E7; Sat, 18 Feb 2012 10:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.675 X-Spam-Level: X-Spam-Status: No, score=-103.675 tagged_above=-999 required=5 tests=[AWL=-1.410, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNwPM+wh02Hy; Sat, 18 Feb 2012 10:21:39 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id D7EEF21F85D5; Sat, 18 Feb 2012 10:21:35 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A928320383; Sat, 18 Feb 2012 13:20:13 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B337F434F; Sat, 18 Feb 2012 13:21:26 -0500 (EST) From: Sam Hartman To: secdir@ietf.org,iesg@ietf.org Date: Sat, 18 Feb 2012 13:21:26 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [secdir] secdir review of draft-mcgrew-tls-aes-ccm-03 X-BeenThere: secdir@ietf.org 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: Sat, 18 Feb 2012 18:21:42 -0000 I reviewed this draft for the security directorate. Looks fine to me. Reasonable choice of which ciphersuites to define, seems consistent with RFc 5216. From bew@cisco.com Sat Feb 18 12:39:02 2012 Return-Path: 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 368FB21E8015; Sat, 18 Feb 2012 12:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nua73V9SAxqP; Sat, 18 Feb 2012 12:39:01 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBEF21E800F; Sat, 18 Feb 2012 12:39:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=983; q=dns/txt; s=iport; t=1329597541; x=1330807141; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=W4OBvZS20mwB0V3QhzTK/UhClCHvKPidn+X5du62B9s=; b=dV3mCimgzeyVvD2xj1jB0zGsfDTppwzJtTiniaHsJNhLfj7u0tO5P5tz ZLUHEmk71GNf5VshzHa1IPR1t2J7weyqWACOsBCV1p8QfXtWoZ/gYCSpM 9x811GcjNxxrKcY0IKfU2SP7Xi1Zstq1sc3P8DZipM3Q4msqD6ewmy+b1 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAK0LQE+rRDoG/2dsb2JhbABEsiaBB4IMASc/gT4BNKJmAZ4ajAIFGw4NBRAIAgICDAENAwODPgODDWMEiE6MaZMO X-IronPort-AV: E=Sophos;i="4.73,443,1325462400"; d="scan'208";a="31147739" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 18 Feb 2012 20:39:01 +0000 Received: from stealth-10-32-244-210.cisco.com (stealth-10-32-244-210.cisco.com [10.32.244.210]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1IKd0BD021659; Sat, 18 Feb 2012 20:39:00 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 18 Feb 2012 12:39:00 -0800 Message-Id: <31317304-6412-40D9-A660-E16F3E84FD6D@cisco.com> To: secdir@ietf.org, The IESG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-v6ops-v6nd-problems.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-v6ops-v6nd-problems-04 X-BeenThere: secdir@ietf.org 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: Sat, 18 Feb 2012 20:39:02 -0000 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. This document describes IPv6 Neighbor Discovery (ND) operational = problems encountered IPv6 routers. The root issue is the large subnet = sizes that are typically used, where a router naively reacting to the = discovery of IPv6 addresses within an entire subnet can cause resource = exhaustion issues. The document suggests techniques that protocol = implementors and operators can employ to mitigate the resource = exhaustions. The document adequately describes the resource exhaustion as a DoS = opportunity. The advice itself does not appear to create any new DoS = considerations. I believe it is ready to publish. Brian= From Tina.Tsou.Zouting@huawei.com Tue Feb 21 08:34:34 2012 Return-Path: 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 BD01421F87E7 for ; Tue, 21 Feb 2012 08:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RxV4OWHab81 for ; Tue, 21 Feb 2012 08:34:34 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 020A721F87E4 for ; Tue, 21 Feb 2012 08:34:34 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZR00A0S4JSYL@szxga04-in.huawei.com> for secdir@ietf.org; Wed, 22 Feb 2012 00:31:05 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZR005K94JS7M@szxga04-in.huawei.com> for secdir@ietf.org; Wed, 22 Feb 2012 00:31:04 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGZ25883; Wed, 22 Feb 2012 00:31:04 +0800 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Feb 2012 00:30:47 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.28]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Wed, 22 Feb 2012 00:30:57 +0800 Date: Tue, 21 Feb 2012 16:30:57 +0000 From: Tina TSOU In-reply-to: To: "secdir@ietf.org" Message-id: <688B3A69-603E-40A5-86FD-74F27250FD26@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: SECDIR Review of draft-ietf-behave-64-analysis-05 Thread-index: AQHM8LYw0IRIEsAc3UiAv56rwcxZfg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "draft-ietf-behave-64-analysis@tools.ietf.org" Subject: [secdir] SECDIR Review of draft-ietf-behave-64-analysis-05 X-BeenThere: secdir@ietf.org 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: Tue, 21 Feb 2012 16:34:34 -0000 I don't see any security concerns as we don't define any new protocol. I have a small suggestion though: The Abstract of the draft somehow doesn't truly reflect the actual description of the draft. This draft analyzes how NAT 64 confirms to RFC 4966, which problems mentioned in 4966 are solved, which are not solved etc. Whereas the abstract mentions "This document evaluate how the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT." I think we can be more specific here. Sent from my iPad From new-work-bounces@ietf.org Tue Feb 21 10:10:39 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B6721F888B; Tue, 21 Feb 2012 10:10:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329847839; bh=S6Cfq0X8WAIOIZY2uoSLleDfl9alhpo/CzrlScqv218=; h=From:To:Mime-Version:Message-Id:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=mnXY2joWJeLjLwVNd7K879XYjV1kHg1p4O4SlsNUsGcYPznp+nnjo1vnVz/GKaeor 62Xw8OwmaN0lQbmXWjNz63BNtKbqIirQXS8+gMm43yG8S2xah+6rhWXCLUaCNSEug1 rQNJrVEGQz3YJ90kB0apCcHAEZsfDtIwn/zvcOMs= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id C363621F87F2; Tue, 21 Feb 2012 10:10:10 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20120221181010.C363621F87F2@ietfa.amsl.com> Date: Tue, 21 Feb 2012 10:10:10 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 21 Feb 2012 10:11:44 -0800 Subject: [secdir] [new-work] WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 18:10:39 -0000 A modified charter has been submitted for the Hypertext Transfer Protocol Bis (httpbis) working group in the Applications Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, February 28, 2012. Hypertext Transfer Protocol Bis (httpbis) ========================================= Charter Last Modified: 2012-02-09 Current Status: Active Working Group Chair(s): Mark Nottingham Applications Area Director(s): Pete Resnick Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Mailing Lists: General Discussion:ietf-http-wg@w3.org To Subscribe: ietf-http-wg-request@w3.org In Body: subscribe Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/ Description of Working Group ---------------------------- This Working Group is charged with maintaining and developing the "core" specifications for HTTP. The Working Group's specification deliverables are: * A document (or set of documents) that is suitable to supersede RFC 2616 (HTTP/1.1) and move RFC 2817 to Historic status * A document cataloguing the security properties of HTTP/1.1 * A document that specifies HTTP/2.0 an improved binding of HTTP's semantics to the underlying transport. ### HTTP/1.1 HTTP is one of the most successful and widely-used protocols on the Internet today. However, its specification has several editorial issues. Additionally, after years of implementation and extension, several ambiguities have become evident, impairing interoperability and the ability to easily implement and use HTTP. The working group will refine RFC2616 to: * Incorporate errata and updates (e.g., references, IANA registries, ABNF) * Fix editorial problems which have led to misunderstandings of the specification * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Where necessary, add implementation advice * Document the security properties of HTTP and its associated mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications It will also incorporate the generic authentication framework from RFC 2617, without obsoleting or updating that specification's definition of the Basic and Digest schemes. Finally, it will incorporate relevant portions of RFC 2817 (in particular, the CONNECT method and advice on the use of Upgrade), so that that specification can be moved to Historic status. In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments ### HTTP/2.0 There is emerging implementation experience and interest in a protocol that retains the semantics of HTTP, without the legacy of HTTP/1.x message framing and syntax, which have been identified as hampering performance and encouraging misuse of the underlying transport. As such, there is an opportunity to create a new major (non-wire-compatible) version of HTTP. To do this, the Working Group will solicit candidates for this work from the community, to be submitted as Internet-Drafts. Expected focus areas for candidates include: * Significantly improved perceived performance in common use cases (e.g., browsers, mobile) * More efficient use of network resources; in particular, reducing the need to use multiple TCP connections * Ability to be deployed on today's Internet, using IPv4 and IPv6, in the presence of NATs * Maintaining HTTP's ease of deployment * Reflecting modern security requirements and practices Although proposals are not required to meet all of these goals, it is expected that the resulting work (if undertaken) will be chartered to meet them (and therefore, selecting one that meets the majority of them as a starting point is in everyone's interest). The Working Group will then select a starting point for the new work based upon the following criteria: * Compatibility with HTTP/1.1 semantics; i.e., it must be possible to pass through a HTTP/1.1 message with reasonable fidelity * Broad implementer interest (e.g., from Web browsers, "back-end" or "web api" uses of HTTP, servers, intermediaries, CDNs, etc.) Changes to the existing semantics of HTTP are out of scope in order to preserve the meaning of messages that might cross a 1.1 --> 2.0 --> 1.1 request chain. However, the resulting effort may define new semantics to further the goals above, along with suitable extensibility mechanisms for defining additional semantics. If the Working Group forms consensus around a proposal to use as a starting point, it is expected it will re-charter to begin work on that document (or set of documents). The resulting work will be known as "HTTP/2.0", unless the Working Group determines that this isn't suitable (e.g., for interoperability). Although work on this new version will begin in parallel with completion of work on HTTP/1.1, the Working Group will prioritize HTTP/1.1 work until it is complete. Goals and Milestones --------------------- Done First HTTP/1.1 Revision Internet Draft Done First HTTP Security Properties Internet Draft Feb 2012 Working Group Last Call for HTTP/1.1 Revision Feb 2012 Working Group Last Call for HTTP Security Properties Feb 2012 Call for Proposals for HTTP/2.0 Apr 2012 Submit HTTP/1.1 Revision to IESG for consideration as a Proposed Standard Apr 2012 Submit HTTP Security Properties to IESG for consideration as Informational RFC June 2012 Re-charter to work on HTTP/2.0 ### _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From jiangsheng@huawei.com Tue Feb 21 18:35:14 2012 Return-Path: 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 761AB21F86F2 for ; Tue, 21 Feb 2012 18:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GT6ld3GV7szN for ; Tue, 21 Feb 2012 18:35:11 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 454AA21F86DD for ; Tue, 21 Feb 2012 18:35:07 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZR005LCWH9X1@szxga03-in.huawei.com> for secdir@ietf.org; Wed, 22 Feb 2012 10:34:22 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZR006FFWH846@szxga03-in.huawei.com> for secdir@ietf.org; Wed, 22 Feb 2012 10:34:21 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGZ36655; Wed, 22 Feb 2012 10:34:20 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Feb 2012 10:34:02 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.20]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 22 Feb 2012 10:33:58 +0800 Date: Wed, 22 Feb 2012 02:33:57 +0000 From: Sheng Jiang X-Originating-IP: [10.108.4.88] To: Sheng Jiang , Stephen Kent , "secdir@ietf.org" Message-id: <5D36713D8A4E7348A7E10DF7437A4B92188B034F@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_wW+hzYWMqTgjKTVXDBtYRw)" Content-language: zh-CN Accept-Language: en-GB, zh-CN, en-US Thread-topic: review of draft-ietf-dhc-secure-dhcpv6-04.txt Thread-index: AQHM1wVGR+IsEftM3kywUBVOpvWIcZYUcUbwgDPx0pA= X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: HD/t IZAQ Nc4F Z8b9 Z/Fh bZcZ bh0g b9iT cdWA ljGr sg18 tdUS vjbv wsmM 6A4V 7IU9; 6; agBvAGgAbgBfAGIAcgB6AG8AegBvAHcAcwBrAGkAQABjAGEAYgBsAGUALgBjAG8AbQBjAGEAcwB0AC4AYwBvAG0AOwBrAGUAbgB0AEAAYgBiAG4ALgBjAG8AbQA7AHIAZAByAG8AbQBzAC4AaQBlAHQAZgBAAGcAbQBhAGkAbAAuAGMAbwBtADsAcwBlAGMAZABpAHIAQABpAGUAdABmAC4AbwByAGcAOwBzAGgAZQBuAHMAaAB1AG8AQABjAG4AbgBpAGMALgBjAG4AOwB0AGUAZAAuAGwAZQBtAG8AbgBAAG4AbwBtAGkAbgB1AG0ALgBjAG8AbQA=; Sosha1_v1; 7; {29CFB7EC-B203-4D9B-9687-9D06BF8968A1}; agBpAGEAbgBnAHMAaABlAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Wed, 22 Feb 2012 02:33:49 GMT; UgBFADoAIAByAGUAdgBpAGUAdwAgAG8AZgAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBkAGgAYwAtAHMAZQBjAHUAcgBlAC0AZABoAGMAcAB2ADYALQAwADQALgB0AHgAdAA= x-cr-puzzleid: {29CFB7EC-B203-4D9B-9687-9D06BF8968A1} X-CFilter-Loop: Reflected References: Cc: "rdroms.ietf@gmail.com" , "ted.lemon@nominum.com" , "shenshuo@cnnic.cn" , "john_brzozowski@cable.comcast.com" Subject: Re: [secdir] review of draft-ietf-dhc-secure-dhcpv6-04.txt X-BeenThere: secdir@ietf.org 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: Wed, 22 Feb 2012 02:35:14 -0000 --Boundary_(ID_wW+hzYWMqTgjKTVXDBtYRw) Content-type: text/plain; charset=iso-8859-2 Content-transfer-encoding: quoted-printable Hi, Stephen, Thanks for your review. I have integrated them in a new version or make som= e correspondent improvements. However, I do not agree the below comment and= would like to discuss it further. The fact that the signature option can be placed anywhere in the = DHCPv6 message strikes me as dangerous. It imposes a requirement on a recei= ver to treat the protected and unprotected portions of the message differen= tly, for any possible placement of the signature option. This adds complexi= ty to implementations, since the security checking would have to indicate t= o the rest of message processing which parts of a message were checked and = which were not verified. Unless there are DHCHv6 options that may be modifi= ed (or added) legitimately when a message traverses a relay, it is not clea= r why there needs to be a provision to exclude any portions of a DHCPv6 mes= sage from the integrity/authentication check. The charge is not right here. Although the signature option can be = placed anywhere, it actually protects ALL DHCPv6 options and payload (excep= t for itself and auth option), see Section 5.2 for how to perform signature= . Therefore, there is no unprotected portion at all. The place of signatur= e option does not mean the portion after it is unprotected. Best regards, Sheng From: Sheng Jiang Sent: Friday, January 20, 2012 9:09 AM To: 'Stephen Kent'; secdir@ietf.org Cc: shenshuo@cnnic.cn; ted.lemon@nominum.com; john_brzozowski@cable.comcast= .com; rdroms.ietf@gmail.com Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt Hi, Stephen, Thanks so much for your carefully reviewing. It is very helpful for us to i= mprove this draft. I will integrate your comments in next version and come = back to you before submission (it will be early Feb, giving that we will st= art the Chinese New Year holiday soon) . Best regards, Sheng From: Stephen Kent [mailto:kent@bbn.com] Sent: Friday, January 20, 2012 7:51 AM To: secdir@ietf.org Cc: shenshuo@cnnic.cn; Sheng Jiang; ted.lemon@nominum.com; john_brzozowski@= cable.comcast.com; rdroms.ietf@gmail.com Subject: review of draft-ietf-dhc-secure-dhcpv6-04.txt I reviewed this document (draft-ietf-dhc-secure-dhcpv6-04.txt) as part of t= he security directorate's ongoing effort to review all IETF documents being= processed by the IESG. These comments were written primarily for the bene= fit of the security area directors. Document editors and WG chairs should = treat these comments just like any other last call comments. This document needs significant work because: - numerous English language errors that make it hard to read - inconsistencies between different sections of the document are present - the incomplete description of sender and receiver processing - it contains a questionable technical proposal for flexibility re placement of the new sig option - alg agility is not correctly described for the sig option, and examples are alg specific - some examples are erroneous The comments provided below are keyed to the sections of the document. Abstract "If not secured, DHCPv6 is vulnerable to various attacks, particularly fake= attack." Presumably the authors are referring to "spoofing" attacks. The c= ommonly employed terminology should be used here. 1. Introduction Same comment for 1st paragraph here. The 2nd paragraph cites draft-ietf-csi-dhcpv6-cga-ps and says that it intro= duced "requirements of using CGA to secure DHCPv6." The cited document does= not define requirements for using use CGAs to secure DHCP, contrary to wha= t is stated here. The cited document analyzes how one might use DHCPv6 to c= onfigure CGA parameters in host clients, and how one might use CGAs to coun= ter spoofing attacks against DHCPv6 servers. At the time this SECDIR review= is being written, the cited document has 6 DISCUSS votes, suggesting that= it requires significant revision, and making it a questionable basis for e= stablishing "requirements" for CGA use in the DHCHv6 context. The following statement "=A9or where available security mechanisms are not = sufficient, =A9" is too vague, e.g., it fails to say what/why available sec= urity mechanisms do no suffice. 2. Security Overview It appears that this section is intended to describe the need for security = mechanisms that counter DHCPv6 server spoofing attacks. It does so very poo= rly. It is haphazard and redundant in its organization, and some of the tex= t is confusing, at best. This section begins by stating "DHCPv6 is a client/server protocol that pro= vides managed and stateful configuration of devices." I question the "state= ful" part of this assertion. DHCP is designed to avoid the need for hosts t= o manually configured, which is very "stateful." Since a DHCP server typica= lly assigns an address to a host from a pool, and only for the duration of = a "lease" this behavior is not a great example of statefullness. SO, it is = not clear what aspects of "state" the authors have in mind here. The text says "In the basic DHCPv6 specifications, regular IPv6 addresses a= re used." I presume the authors mean that the DHCP server uses a "regular" = IPv6 address for itself, but since DHCPv6 servers provide IPv6 addresses to= their clients, this statement is ambiguous. The last paragraph on page 3 begins with double quotes, but this appears to= be a typo. This paragraph provides two examples of possible motivations fo= r attacker that spoofs DHCP responses. Do the authors assert that these the= most important motivations, the only ones, or what? The document quotes from RFC 3315. It isn't clear if this is intended to ex= tend the description of adverse outcomes from spoofing a DHCPv6 server, or = if it is merely a restatement of the generic concern cited in the prior par= agraphs. The next paragraph uses many words to describe a MITM attack, which the doc= ument already noted at the bottom of page 3. The paragraph then goes on to = say "This becomes important to detect and prevent when encrypted traffic is= allowed to pass through firewalls." This is a confusing statement at best.= If the traffic is encrypted, a MITM attack does not provide an adversary w= ith a lot of interesting info to collect via a MITM attack. It isn't clear = what the authors were trying to communicate here. The document states "Once servers start updating DNS and other directory se= rvices, attackers may spoof DHCP servers to register incorrect information = in those services." Which "servers" are being cited as the subject here? Wh= o is updating them? This 1-sentence paragraph does not explain the role tha= t DHCPv6 server spoofing plays in the cited concern. The document states "Another possible attack is that attackers may be able = to gain unauthorized access to some resources, such as network access." Una= uthorized network access is a valid security concern, but the authors fail = to explain how DHCP spoofing is related to this generic concern. One usuall= y associates RADIUS, NEA and similar protocols as more relevant to network = access control. The authors discuss two key management mechanisms defined for DHCPv6, and c= onclude by saying "In either way, the security of key itself is in question= mark." Even if one deletes the last word to make the sentence readable, th= e assertion is not supported when discussing the first option, i.e., initia= l manual distribution of a symmetric key. Kerberos has made use of this app= roach for many years, with reasonable success. A better criticism is that m= anual key distribution runs counter to the goal of minimizing the configura= tion data needed at each host, consistent with the goals of DHCP use. Also,= manual key distribution is viewed as less secure than automated key distri= bution mechanisms. This section ends with a paragraph citing another security option, i.e., us= e of IPsec, to secure server and relay agent communications. (The document = misspells the protocol name.) "Furthermore, the manual configuration and st= atic keys are potential issue makers." IPsec does not require use of manual= key management or static keys, so this comment is inappropriate. 3. Secure DHCPv6 Overview The proposed mechanism calls for each DHCPv6 server to use a CGA for its ow= n address, and to digitally sign the messages it sends using the private ke= y corresponding to the public key linked to the DHCPv6 server address. This= mechanism counters DHCPv6 server spoofing, IF all clients are configured w= ith the CGAs of authorized DHCPv6 servers. This section of the document doe= s not describe this critical configuration requirement. Instead, this docum= ent cite draft-ietf-dhc-cga-config-dhcpv6. The cited document talks about h= ow to use DHCPv6 to control CGA generation on clients. It does not describe= configuring client with the CGAs of authorized DHCPv6 servers. Thus the ci= ted document does not address this issue. The text includes a curious statement "By using the signature option, the v= erification of data integrity and replay protections can also be achieved w= ithout the authentication option." It is true that if one were to verify a = signature on a received message, but not verify that the sending CGA is tha= t of an authorized DHCPv6 server, that connectionless message integrity is = achieved. However, it is not clear that this security function is useful, i= n isolation. Also, the text in this section provides no analysis to show wh= y use of the signature, by itself, provides replay protection. (One would n= eed to describe the context established by DHCP message exchanges to make s= uch an argument.) The section ends with a very confusing paragraph. The paragraph appears to = be discussing how to make use of the proposed CGA-based security mechanism = when a relay agent lies between the server and clients. The text is not cle= ar, and thus does not constitute a solid argument for why this works. 4.1 New Components In discussing how to extend DHCPv6 syntax to make use of the proposed CGA s= ecurity mechanism, the section includes a statement "The authority of a pub= lic key is established through the address ownership proof mechanism, by us= ing CGAs." This is not true, unless clients are configured to know the CGAs= of all authorized DHCPv6 servers with which the clients may interact. 4.2 Support for algorithm agility This section begins with a sloppy characterization of hash function require= ments, including a quote from RFC 4270 "The recent attacks have demonstrate= d that one of those security properties is not true." This quote is not use= ful on this context, since the authors fail to indicate which of the two ci= ted security properties is not true here. The section goes on to say that "= =A9our analysis shows none of these attacks are currently doable." The auth= ors provide no analysis to support this assertion, nor a cite to a document= that would do so. Thus, either this statement needs to be removed, or supp= ort for it needs to be provided. More importantly, it appears that algorithm agility support for Secure DHCP= v6 is based (in large part) on carrying the hash and signature algorithm ID= s in the Signature Option. That is different from the RFC 4270 analysis of = how to enable algorithm agility for the CGA itself. Moreover, a credible al= gorithm agility solution requires a system-level discussion of how communic= ating servers, relays, and clients know which algorithms can be used in dea= ling with each other. This document does not include such a discussion, nor= does it describe how to transition from one algorithm to another, within t= he context of a network. For example, do all servers have to be upgraded to= offer a new algorithm simultaneously? How about relays and clients? 5 Extensions for Secure DHCPv6 Since this section introduces a new DHCPv6 option, the document needs to st= ate that it updates RFC 3315. 5.1 CGA Parameters Option The description of this new option includes the following text: "Note that = a future extension MAY provide a mechanism allowing the owner of an address= and the signer to be different parties." First, this is a misuse of "MAY."= Second, this text is not appropriate for a syntax specification at this ti= me, i.e., what should an implementer do based on this statement? 5.2 Signature Option I question the soundness of the proposed design. The fact that the signatur= e option can be placed anywhere in the DHCPv6 message strikes me as dangero= us. It imposes a requirement on a receiver to treat the protected and unpro= tected portions of the message differently, for any possible placement of t= he signature option. This adds complexity to implementations, since the sec= urity checking would have to indicate to the rest of message processing whi= ch parts of a message were checked and which were not verified. Unless ther= e are DHCHv6 options that may be modified (or added) legitimately when a me= ssage traverses a relay, it is not clear why there needs to be a provision = to exclude any portions of a DHCPv6 message from the integrity/authenticat= ion check. "COULD" is not an RFC 2119-defined term. The option carries an explicit hash algorithm ID, which is good, but the te= xt says: "RSA signature [RSA] with SHA-1 [sha-1] is adopted. In order to pr= ovide hash algorithm agility, SHA-1 is assigned an initial value 0x0000 in = this document." Why is a signature algorithm part of this definition (vs. j= ust a hash algorithm), when there is a separate signature algorithm ID fiel= d? The text here is inconsistent with the latter IANA considerations. It a= ppears that the mention of RSA is an error, but it would be better to just = remove any mention of an initial algorithm value here. The description of i= nitial values for the signature algorithm ID, and the second hash algorithm= ID also should be removed from this text, and appear only in the IANA cons= iderations section. The discussion of the key hash field runs counter to the goal of algorithm = agility. The reference to SHA-1 should be removed, if the intent is to defi= ne the key hash algorithm via the previously-mentioned parameter. The key h= ash, if it is to be a fixed length, merely needs to be defined as the leftm= ost 128 bits of the hash value of the public key of the sender. The description of how to compute the signature field is wrong. The text de= scribes the fields over which the hash is to be computed. Instead the text = says "The signature constructed by using the sender's private key over the = following sequence of octets." The first value is a message type tag value, which is said to have been com= puted as a random value by the editor of the specification. The document ne= eds to explain why this value needs to be part of the input to the hash fun= ction, and how is was generated. The current text is inadequate. 6.1 Processing rules of sender The discussion of processing provided here is piecemeal. The text should pr= ovide comprehensive, step-by-step processing instructions. As noted in my comments above, authentication of an address, as provided by= CGA use, does not prevent spoofing attacks related to higher layer functio= nality. Thus, for example, unless a client knows the CGA of a server or rel= ay agent, authenticating the address of the purported server or relay agent= does not prevent spoofing, the type of attack cited at the beginning of th= is document as the primary rationale for the mechanisms proposed here. The text at the end of the introductory sentence says: "can be configured t= o send Secure DHCPv6 messages only if CGAs have been configured on it." It = is not clear whether this is saying that the sender has to have a "configur= ed" CGA (e.g., vs. a dynamically-generated CGA), or if the sender needs to = have a configured list of recipient CGAs, or something else. It probably is= feasible to configure clients with the CGAs of servers or relay agents, bu= t this document did not address that issue. If the authors envision client = use of CGAs for DHCPv6 security, they need to explain how this will be mana= ged. The management ought not undermine the anonymity features that are a h= allmark of client use of CGAs, and it must not include a circular dependenc= y. (For example, one of the documents cited in this document calls for usin= g DHCPv6 to supply CGA configuration parameters to client. That would not s= eem to be compatible with a client using DHCPv6 and CGAs to communicate wit= h a server, initially.) This section ends with the statement: "The CGA of DHCPv6 server will not lo= se during relaying so that the client can verify CGA address and signature.= " I presume this means that the CGA or the server will not be lost when it = passes through the relay, but the English is awkward, at best. 6.2 Receiver processing Here too the discussion of processing is piecemeal. The text should provide= comprehensive, step-by-step processing instructions. The "Minbits" discussion is NOT supportive of algorithm agility. It seems t= o refer to a minimum RSA key size, without mentioning RSA. This key size re= commendation would be inappropriate for DSA, ECDSA, etc. Also, the phrase = "SHOULD be 1024 bits" is inappropriate. If this were the default length, th= en it ought to be a MUST. Also, the text says: "Any implementation SHOULD f= ollow prudent cryptographic practice in determining the appropriate key len= gths." This might be reasonable (though ambiguous) advice for a site, but n= ot for an implementation. Protocol standards establish requirements for def= ault or mandatory to implement algorithms and key sizes, and ALL compliant = implementations support the cited algorithms. The guidance provided re messages that fail to include the CGA or Signature= options is not helpful, as it fails to say what behavior is required when = a receiver treats a message as unsecured? Saying that a receiver MAY discar= d the message is too vague, i.e., if the receiver processes it, what SHOULD= /MUST the receiver do differently, in the absence of either or both of thes= e options? This ambiguity seems to contradict the later statement that "Onl= y the messages that get through both CGA and signature verifications are ac= cepted as secured DHCPv6 messages and continue to be handled for their cont= ained DHCPv6 options." It is also runs counter to the later statement "Mess= ages that do not pass all the above tests MUST be silently discarded if the= host has been configured to accept only secured DHCPv6 messages." This dis= crepancy needs to be resolved. The text mandates verification of the Signature option using a public key t= hat is either acquired from the CGA option, or "one known by other means." = The latter phrase is too vague to be useful. It also contradicts the statem= ent in section 5.1: "This specification requires that the public key found = from the CGA Parameters field in the CGA option MUST be that referred by th= e Key Hash field in the Signature option." Later in this section there is a discussion of how to handle messages that = fail the requisite checks. The texts states "Messages that do not pass all = the above tests MUST be silently discarded if the host has been configured = to accept only secured DHCPv6 messages. The messages MAY be accepted if the= host has been configured to accept both secured and unsecured messages but= MUST be treated as an unsecured message. The receiver MAY also otherwise s= ilently discard packets." This last sentence is confusing, given the previo= us two sentences. Also, what are the security semantics of a receiver that = is configured to accept both secured and unsecured DHCPv6 messages? Does th= is makes sense for servers, clients, and relays? The document seems to be l= acking a system-level discussion of the issue of how Secure DHCPv6 can be d= eployed, incrementally, and whether a mixed mode of operation makes sense o= n a long term or only a transient basis. The text later in Section 6.1 states that the Signature option is the last = one in the message, hence all the prior options are covered by the signatur= e. That seems appropriate, but the text there does not restrict what option= s MAY be present (as opposed to the two options that MUST be present). Thus= this might create ambiguity for a receiver, e.g., how SHOULD/MUST a receiv= er deal with a secured messages that also contains unsigned options? Is thi= s something that needs to be configured for each server/relay/client? What = are the right configuration capabilities to deal with this, e.g., does the = configuration need to enumerate what unsigned options are allowed to be pro= cessed, etc? 6.3 Processing rules of Relay Agent Two more instances of "will not lose" in this section, that need to be fixe= d. 7. Security Considerations At the top of page 13 the discussion is confusing, at best. The authors see= m to suggest that the proposed mechanisms do not require use of a "pre-noti= fied DHCPv6 server address." But, absent such configuration info, the use o= f the proposed mechanisms do NOT prevent server spoofing. Then the text sug= gests that such configuration info may be needed, but that this creates pot= ential DoS vulnerabilities. The authors then punt on this question. This is= not acceptable. The authors cannot have it both ways. Either they are mand= ating use of fixed CGAs for servers, or not. The security properties of the= proposed mechanisms are greatly affected by this choice. There are several examples here of incorrect use of MAY, when referring to = future options that might be defined to deal with a mix of secured and unse= cured messages. As noted above, the current specification allows a node to = accept both secured and unsecured message, without discussing what behavior= is required, and without a specification of how such a node might be confi= gured to limit possible damage. There is also no system-level discussion of= whether it is necessary to configure some nodes, e.g., servers, to operate= in this mode because of an anticipated deployment model. The text here provides vague security advice "=A9when link-local CGAs are u= sed by the DHCPv6 clients, it is recommended to use a slightly higher Sec v= alue." The text then asserts that "When higher Sec values are used, the rel= ative advantage of attacking link-local addresses becomes insignificant." S= ince no specific Sec values are recommended, this latter statement is unsup= ported, at best. There is a typo in the ultimate paragraph for this section: "=A9used in th= e RSA signature in Secure." Should be "=A9used in the RSA signature in Secu= re DHCPv6." Since algorithm agility is emphasized here, why are only RSA-ba= sed signatures cited? --Boundary_(ID_wW+hzYWMqTgjKTVXDBtYRw) Content-type: text/html; charset=iso-8859-2 Content-transfer-encoding: quoted-printable review of draft-ietf-dhc-secure-dhcpv6-04.txt

Hi, Stephen,

 <= /p>

Thanks for your review. I= have integrated them in a new version or make some correspondent improveme= nts. However, I do not agree the below comment and would like to discuss it further.

 <= /p>

<Stephen> The fact= that the signature option can be placed anywhere in the DHCPv6 message str= ikes me as dangerous. It imposes a requirement on a receiver to treat the p= rotected and unprotected portions of the message differently, for any possible placement of the signature option. This adds= complexity to implementations, since the security checking would have to i= ndicate to the rest of message processing which parts of a message were che= cked and which were not verified. Unless there are DHCHv6 options that may be modified (or added) legitimate= ly when a message traverses a relay, it is not clear why there needs to be = a provision to exclude any portions of a DHCPv6 message from  the inte= grity/authentication check.

 <= /p>

<Sheng> The charge = is not right here. Although the signature option can be placed anywhere, it= actually protects ALL DHCPv6 options and payload (except for itself and auth option), see Section 5.2 for how to perform signature. The= refore, there is no unprotected  portion at all. The place of signatur= e option does not mean the portion after it is unprotected.

 <= /p>

Best regards,<= /span>

 <= /p>

Sheng

 <= /p>

From: Sheng Ji= ang
Sent: Friday, January 20, 2012 9:09 AM
To: 'Stephen Kent'; secdir@ietf.org
Cc: shenshuo@cnnic.cn; ted.lemon@nominum.com; john_brzozowski@cable.= comcast.com; rdroms.ietf@gmail.com
Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt

 

Hi, Stephen,

 <= /p>

Thanks so much for your c= arefully reviewing. It is very helpful for us to improve this draft. I will= integrate your comments in next version and come back to you before submission (it will be early Feb, giving that we will start the= Chinese New Year holiday soon) .

 <= /p>

Best regards,<= /span>

 <= /p>

Sheng

 <= /p>

From: Stephen = Kent [mailto:kent@bbn.com]
Sent: Friday, January 20, 2012 7:51 AM
To: secdir@ietf.org
Cc: shenshuo@cnnic.cn; Sheng Jiang; ted.lemon@nominum.com; john_brzo= zowski@cable.comcast.com; rdroms.ietf@gmail.com
Subject: review of draft-ietf-dhc-secure-dhcpv6-04.txt

 

I reviewed this document= (draft-ietf-dhc-secure-dhcpv6-04.txt) as part of the security directorate'= s ongoing effort to review all IETF documents being processed by the IESG.&= nbsp; 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 commen= ts.

 

This document needs sign= ificant work because:

  -&nb= sp; numerous English language errors tha= t make it hard to read

  - inconsistencies= between different sections of the document are present

  - the incomplete = description of sender and receiver processing

  - it contains a q= uestionable technical proposal for flexibility re

    place= ment of the new sig option

  - alg agility is = not correctly described for the sig option, and

    examp= les are alg specific

  - some examples a= re erroneous



The comments provided below are keyed to the sections of the document.

Abstract

"If not secured, DHCPv6 is vulnerable to various attacks, particularly= fake attack." Presumably the authors are referring to "spoofing&= quot; attacks. The commonly employed terminology should be used here.


1. Introduction

Same comment for 1st paragraph here.

The 2nd paragraph cites draft-ietf-csi-dhcpv6-cga-ps and says that it intro= duced "requirements of using CGA to secure DHCPv6." The cited doc= ument does not define requirements for using use CGAs to secure DHCP, contr= ary to what is stated here. The cited document analyzes how one might use DHCPv6 to configure CGA parameters in ho= st clients, and how one might use CGAs to counter spoofing attacks against = DHCPv6 servers. At the time this SECDIR review is being written,  the = cited document has 6 DISCUSS votes, suggesting that it requires significant revision, and making it a questionable basis = for establishing "requirements" for CGA use in the DHCHv6 context= .

The following statement "=A9or where available security mechanisms are= not sufficient, =A9" is too vague, e.g., it fails to say what/why ava= ilable security mechanisms do no suffice.


2. Security Overview

It appears that this section is intended to describe the need for security = mechanisms that counter DHCPv6 server spoofing attacks. It does so very poo= rly. It is haphazard and redundant in its organization, and some of the tex= t is confusing, at best.

This section begins by stating "DHCPv6 is a client/server protocol tha= t provides managed and stateful configuration of devices." I question = the "stateful" part of this assertion. DHCP is designed to avoid = the need for hosts to manually configured, which is very "stateful." Since a DHCP server typically assigns an addres= s to a host from a pool, and only for the duration of a "lease" t= his behavior is not a great example of statefullness. SO, it is not clear w= hat aspects of "state" the authors have in mind here.

The text says "In the basic DHCPv6 specifications, regular IPv6 addres= ses are used." I presume the authors mean that the DHCP server uses a = "regular" IPv6 address for itself, but since DHCPv6 servers provi= de IPv6 addresses to their clients, this statement is ambiguous.

The last paragraph on page 3 begins with double quotes, but this appears to= be a typo. This paragraph provides two examples of possible motivations fo= r attacker that spoofs DHCP responses. Do the authors assert that these the= most important motivations, the only ones, or what?

The document quotes from RFC 3315. It isn't clear if this is intended to ex= tend the description of adverse outcomes from spoofing a DHCPv6 server, or = if it is merely a restatement of the generic concern cited in the prior par= agraphs.

The next paragraph uses many words to describe a MITM attack, which the doc= ument already noted at the bottom of page 3. The paragraph then goes on to = say "This becomes important to detect and prevent when encrypted traff= ic is allowed to pass through firewalls." This is a confusing statement at best. If the traffic is encrypted, a MITM= attack does not provide an adversary with a lot of interesting info to col= lect via a MITM attack. It isn't clear what the authors were trying to comm= unicate here.


The document states "Once servers start updating DNS and other directo= ry services, attackers may spoof DHCP servers to register incorrect informa= tion in those services." Which "servers" are being cited as = the subject here? Who is updating them? This 1-sentence paragraph does not explain the role that DHCPv6 server spoofing plays in t= he cited concern.

The document states "Another possible attack is that attackers may be = able to gain unauthorized access to some resources, such as network access.= " Unauthorized network access is a valid security concern, but the aut= hors fail to explain how DHCP spoofing is related to this generic concern. One usually associates RADIUS, NEA and si= milar protocols as more relevant to network access control.

The authors discuss two key management mechanisms defined for DHCPv6, and c= onclude by saying "In either way, the security of key itself is in que= stion mark." Even if one deletes the last word to make the sentence re= adable, the assertion is not supported when discussing the first option, i.e., initial manual distribution of a symmet= ric key. Kerberos has made use of this approach for many years, with reason= able success. A better criticism is that manual key distribution runs count= er to the goal of minimizing the configuration data needed at each host, consistent with the goals of DHCP = use. Also, manual key distribution is viewed as less secure than automated = key distribution mechanisms.

This section ends with a paragraph citing another security option, i.e., us= e of IPsec, to secure server and relay agent communications. (The document = misspells the protocol name.) "Furthermore, the manual configuration a= nd static keys are potential issue makers." IPsec does not require use of manual key management or static keys, so thi= s comment is inappropriate.


3. Secure DHCPv6 Overview

The proposed mechanism calls for each DHCPv6 server to use a CGA for its ow= n address, and to digitally sign the messages it sends using the private ke= y corresponding to the public key linked to the DHCPv6 server address. This= mechanism counters DHCPv6 server spoofing, IF all clients are configured with the CGAs of authorized DHCPv6= servers. This section of the document does not describe this critical conf= iguration requirement. Instead, this document cite draft-ietf-dhc-cga-confi= g-dhcpv6. The cited document talks about how to use DHCPv6 to control CGA generation on clients. It does not = describe configuring client with the CGAs of authorized DHCPv6 servers. Thu= s the cited document does not address this issue.

The text includes a curious statement "By using the signature option, = the verification of data integrity and replay protections can also be achie= ved without the authentication option." It is true that if one were to= verify a signature on a received message, but not verify that the sending CGA is that of an authorized DHCPv6 server= , that connectionless message integrity is achieved. However, it is not cle= ar that this security function is useful, in isolation. Also, the text in t= his section provides no analysis to show why use of the signature, by itself, provides replay protection. (= One would need to describe the context established by DHCP message exchange= s to make such an argument.)

The section ends with a very confusing paragraph. The paragraph appears to = be discussing how to make use of the proposed CGA-based security mechanism = when a relay agent lies between the server and clients. The text is not cle= ar, and thus does not constitute a solid argument for why this works.

4.1 New Components

In discussing how to extend DHCPv6 syntax to make use of the proposed CGA s= ecurity mechanism, the section includes a statement "The authority of = a public key is established through the address ownership proof mechanism, = by using CGAs." This is not true, unless clients are configured to know the CGAs of all authorized DHCPv6 servers w= ith which the clients may interact.

4.2 Support for algorithm agility

This section begins with a sloppy characterization of hash function require= ments, including a quote from RFC 4270 "The recent attacks have demons= trated that one of those security properties is not true." This quote = is not useful on this context, since the authors fail to indicate which of the two cited security properties is not true he= re. The section goes on to say that "=A9our analysis shows none of the= se attacks are currently doable." The authors provide no analysis to s= upport this assertion, nor a cite to a document that would do so. Thus, either this statement needs to be removed, or supp= ort for it needs to be provided.


More importantly, it appears that algorithm agility support for Secure DHCP= v6 is based (in large part) on carrying the hash and signature algorithm ID= s in the Signature Option. That is different from the RFC 4270 analysis of = how to enable algorithm agility for the CGA itself. Moreover, a credible algorithm agility solution requir= es a system-level discussion of how communicating servers, relays, and clie= nts know which algorithms can be used in dealing with each other. This docu= ment does not include such a discussion, nor does it describe how to transition from one algorithm to another, with= in the context of a network. For example, do all servers have to be upgrade= d to offer a new algorithm simultaneously? How about relays and clients?

5 Extensions for Secure DHCPv6

Since this section introduces a new DHCPv6 option, the document needs to st= ate that it updates RFC 3315.


5.1 CGA Parameters Option

The description of this new option includes the following text: "Note = that a future extension MAY provide a mechanism allowing the owner of an ad= dress and the signer to be different parties." First, this is a misuse= of "MAY." Second, this text is not appropriate for a syntax specification at this time, i.e., what should an implementer = do based on this statement?

5.2 Signature Option

I question the soundness of the proposed design. The fact that the signatur= e option can be placed anywhere in the DHCPv6 message strikes me as dangero= us. It imposes a requirement on a receiver to treat the protected and unpro= tected portions of the message differently, for any possible placement of the signature option. This adds complexity t= o implementations, since the security checking would have to indicate to th= e rest of message processing which parts of a message were checked and whic= h were not verified. Unless there are DHCHv6 options that may be modified (or added) legitimately when a mes= sage traverses a relay, it is not clear why there needs to be a provision t= o exclude any portions of a DHCPv6 message from  the integrity/authent= ication check. "COULD" is not an RFC 2119-defined term.

The option carries an explicit hash algorithm ID, which is good, but the te= xt says: "RSA signature [RSA] with SHA-1 [sha-1] is adopted. In order = to provide hash algorithm agility, SHA-1 is assigned an initial value 0x000= 0 in this document." Why is a signature algorithm part of this definition (vs. just a hash algorithm), when there = is a separate signature algorithm ID field?  The text here is inconsis= tent with the latter IANA considerations. It appears that the mention of RS= A is an error, but it would be better to just remove any mention of an initial algorithm value here. The descrip= tion of initial values for the signature algorithm ID, and the second hash = algorithm ID also should be removed from this text, and appear only in the = IANA considerations section.

The discussion of the key hash field runs counter to the goal of algorithm = agility. The reference to SHA-1 should be removed, if the intent is to defi= ne the key hash algorithm via the previously-mentioned parameter. The key h= ash, if it is to be a fixed length, merely needs to be defined as the leftmost 128 bits of the hash value of t= he public key of the sender.

The description of how to compute the signature field is wrong. The text de= scribes the fields over which the hash is to be computed. Instead the text = says "The signature constructed by using the sender's private key over= the following sequence of octets."

The first value is a message type tag value, which is said to have been com= puted as a random value by the editor of the specification. The document ne= eds to explain why this value needs to be part of the input to the hash fun= ction, and how is was generated. The current text is inadequate.


6.1 Processing rules of sender
 
The discussion of processing provided here is piecemeal. The text should pr= ovide comprehensive, step-by-step processing instructions.
As noted in my comments above, authentication of an address, as provided by= CGA use, does not prevent spoofing attacks related to higher layer functio= nality. Thus, for example, unless a client knows the CGA of a server or rel= ay agent, authenticating the address of the purported server or relay agent does not prevent spoofing, the type= of attack cited at the beginning of this document as the primary rationale= for the mechanisms proposed here.


The text at the end of the introductory sentence says: "can be configu= red to send Secure DHCPv6 messages only if CGAs have been configured on it.= " It is not clear whether this is saying that the sender has to have a= "configured" CGA (e.g., vs. a dynamically-generated CGA), or if the sender needs to have a configured list of recipient CGAs, = or something else. It probably is feasible to configure clients with the CG= As of servers or relay agents, but this document did not address that issue= . If the authors envision client use of CGAs for DHCPv6 security, they need to explain how this will be man= aged. The management ought not undermine the anonymity features that are a = hallmark of client use of CGAs, and it must not include a circular dependen= cy. (For example, one of the documents cited in this document calls for using DHCPv6 to supply CGA configuration = parameters to client. That would not seem to be compatible with a client us= ing DHCPv6 and CGAs to communicate with a server, initially.)

This section ends with the statement: "The CGA of DHCPv6 server will n= ot lose during relaying so that the client can verify CGA address and signa= ture." I presume this means that the CGA or the server will not be los= t when it passes through the relay, but the English is awkward, at best.


6.2 Receiver processing

Here too the discussion of processing is piecemeal. The text should provide= comprehensive, step-by-step processing instructions.

The "Minbits" discussion is NOT supportive of algorithm agility. = It seems to refer to a minimum RSA key size, without mentioning RSA. This k= ey size recommendation would be inappropriate for DSA, ECDSA, etc.  Al= so, the phrase "SHOULD be 1024 bits" is inappropriate. If this were the default length, then it ought to be a MUST. Also, the tex= t says: "Any implementation SHOULD follow prudent cryptographic practi= ce in determining the appropriate key lengths." This might be reasonab= le (though ambiguous) advice for a site, but not for an implementation. Protocol standards establish requirements for d= efault or mandatory to implement algorithms and key sizes, and ALL complian= t implementations support the cited algorithms.

The guidance provided re messages that fail to include the CGA or Signature= options is not helpful, as it fails to say what behavior is required when = a receiver treats a message as unsecured? Saying that a receiver MAY discar= d the message is too vague, i.e., if the receiver processes it, what SHOULD/MUST the receiver do differently= , in the absence of either or both of these options? This ambiguity seems t= o contradict the later statement that "Only the messages that get thro= ugh both CGA and signature verifications are accepted as secured DHCPv6 messages and continue to be handled for the= ir contained DHCPv6 options." It is also runs counter to the later sta= tement "Messages that do not pass all the above tests MUST be silently= discarded if the host has been configured to accept only secured DHCPv6 messages." This discrepancy needs to be= resolved.

The text mandates verification of the Signature option using a public key t= hat is either acquired from the CGA option, or "one known by other mea= ns." The latter phrase is too vague to be useful. It also contradicts = the statement in section 5.1: "This specification requires that the public key found from the CGA Parameters field in the CG= A option MUST be that referred by the Key Hash field in the Signature optio= n."

Later in this section there is a discussion of how to handle messages that = fail the requisite checks. The texts states "Messages that do not pass= all the above tests MUST be silently discarded if the host has been config= ured to accept only secured DHCPv6 messages. The messages MAY be accepted if the host has been configured to accept bot= h secured and unsecured messages but MUST be treated as an unsecured messag= e. The receiver MAY also otherwise silently discard packets." This las= t sentence is confusing, given the previous two sentences. Also, what are the security semantics of a receiver that is= configured to accept both secured and unsecured DHCPv6 messages? Does this= makes sense for servers, clients, and relays? The document seems to be lac= king a system-level discussion of the issue of how Secure DHCPv6 can be deployed, incrementally, and whether= a mixed mode of operation makes sense on a long term or only a transient b= asis.


The text later in Section 6.1 states that the Signature option is the last = one in the message, hence all the prior options are covered by the signatur= e. That seems appropriate, but the text there does not restrict what option= s MAY be present (as opposed to the two options that MUST be present). Thus this might create ambiguity fo= r a receiver, e.g., how SHOULD/MUST a receiver deal with a secured messages= that also contains unsigned options? Is this something that needs to be co= nfigured for each server/relay/client? What are the right configuration capabilities to deal with this, e.g., doe= s the configuration need to enumerate what unsigned options are allowed to = be processed, etc?


6.3 Processing rules of Relay Agent

Two more instances of "will not lose" in this section, that need = to be fixed.



7. Security Considerations

At the top of page 13 the discussion is confusing, at best. The authors see= m to suggest that the proposed mechanisms do not require use of a "pre= -notified DHCPv6 server address." But, absent such configuration info,= the use of the proposed mechanisms do NOT prevent server spoofing. Then the text suggests that such configuration in= fo may be needed, but that this creates potential DoS vulnerabilities. The = authors then punt on this question. This is not acceptable. The authors can= not have it both ways. Either they are mandating use of fixed CGAs for servers, or not. The security properti= es of the proposed mechanisms are greatly affected by this choice.

There are several examples here of incorrect use of MAY, when referring to = future options that might be defined to deal with a mix of secured and unse= cured messages. As noted above, the current specification allows a node to = accept both secured and unsecured message, without discussing what behavior is required, and without a speci= fication of how such a node might be configured to limit possible damage. T= here is also no system-level discussion of whether it is necessary to confi= gure some nodes, e.g., servers, to operate in this mode because of an anticipated deployment model.

The text here provides vague security advice "=A9when link-local CGAs = are used by the DHCPv6 clients, it is recommended to use a slightly higher = Sec value." The text then asserts that "When higher Sec values ar= e used, the relative advantage of attacking link-local addresses becomes insignificant." Since no specific Sec values are re= commended, this latter statement is unsupported, at best.

There is a typo in the ultimate paragraph for this section:  "=A9= used in the RSA signature in Secure." Should be "=A9used in the R= SA signature in Secure DHCPv6." Since algorithm agility is emphasized = here, why are only RSA-based signatures cited?

--Boundary_(ID_wW+hzYWMqTgjKTVXDBtYRw)-- From jsalowey@cisco.com Tue Feb 21 19:25:46 2012 Return-Path: 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 3A52B21E804C; Tue, 21 Feb 2012 19:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9KOwPd8I0Sw; Tue, 21 Feb 2012 19:25:45 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 24E4421E800F; Tue, 21 Feb 2012 19:25:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1296; q=dns/txt; s=iport; t=1329881145; x=1331090745; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=oNa5MulqCTdrlLLsQxckwL+du5DbQV4WGDOE/8M4sT8=; b=PEmzIzHxMCyt3VLQ6xGHdE5rThGcJpwSMKNoCqI1D1rnnS716JdmVlK1 siaJowzk9SFpAql89szlKGywOcKSUn2rpOdsDluhrr/AML5ZbEMSMQapV MX4M+rExKAQJwfkdPnzptPXMue1bNsHT/x1otUW9ZJq3I1ne3TbbTuIKw M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswHAJ9fRE+Q/khM/2dsb2JhbABEgxKvTYEHggwBJz+BPzSnXgGXK4lUgnIKBAoLCA8ICwMPDQITBAEKAgUDAoUcgz1jBIhPjGmFXY0xgTI X-IronPort-AV: E=Sophos;i="4.73,461,1325462400"; d="scan'208";a="66705148" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 22 Feb 2012 03:25:44 +0000 Received: from [10.123.1.204] (rtp-vpn5-1498.cisco.com [10.82.237.223]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1M3PgEM026229; Wed, 22 Feb 2012 03:25:43 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Feb 2012 19:22:56 -0800 Message-Id: <62D370A2-7E18-4A83-BA4C-C9FEAF5F3C6F@cisco.com> To: secdir@ietf.org, draft-snell-atompub-tombstones.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: The IESG Subject: [secdir] secdir review of draft-snell-atompub-tombstones-14 X-BeenThere: secdir@ietf.org 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: Wed, 22 Feb 2012 03:25:46 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document defines a XML data format used to remove entries from an = atom feed. The document does make use of the XML digital signature and = encryption specifications from the W3C to provide integrity, = authenticity and confidentiality. Key management for the encryption is = not discussed, however this seems to be consistent with other AtomPub = documents. How a message is authorized is not described in much = detail. In the security considerations there is mention that it is = expected that the delete message will be signed using the same key as = the particular feed but how to handle this seems to be largely out of = scope of the document. Both of these are not necessarily problems in = themselves, but could lead to interop and manageability problems. = Since the deleted entry document may contain an IRI perhaps it would be = good to reference the security considerations in RFC 3987.=20 Cheers, Joe= From jsalowey@cisco.com Tue Feb 21 19:25:52 2012 Return-Path: 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 B877421E806C; Tue, 21 Feb 2012 19:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5o8UWcJGEy94; Tue, 21 Feb 2012 19:25:52 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2DABB21E8065; Tue, 21 Feb 2012 19:25:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1296; q=dns/txt; s=iport; t=1329881152; x=1331090752; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=oNa5MulqCTdrlLLsQxckwL+du5DbQV4WGDOE/8M4sT8=; b=SHIleCwM0t0jdtZwEse1IUoqHIvf2Yu+TBSnwr7aey4rq8UvsC1+wn3L Lm+BI/HkhCUxqZFP5VbRNppSBURk2MO0Sb9IoWr28KG4Qe1SrjUgk6ztU NZGuhtDl0Hnw2CiLtLsB0Tbs606ByyrbL4aCpI5BsRl1L6FyQMLotkTq6 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswHAJ9fRE+Q/khM/2dsb2JhbABEgxKvTYEHggwBJz+BPzSnXgGXK4lUgnIKBAoLCA8ICwMPDQITBAEKAgUDAoUcgz1jBIhPjGmFXY0xgTI X-IronPort-AV: E=Sophos;i="4.73,461,1325462400"; d="scan'208";a="66705150" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 22 Feb 2012 03:25:51 +0000 Received: from [10.123.1.204] (rtp-vpn5-1498.cisco.com [10.82.237.223]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1M3PgEN026229; Wed, 22 Feb 2012 03:25:50 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Feb 2012 19:26:44 -0800 Message-Id: To: secdir@ietf.org, draft-snell-atompub-tombstones.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: The IESG Subject: [secdir] secdir review of draft-snell-atompub-tombstones-14 X-BeenThere: secdir@ietf.org 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: Wed, 22 Feb 2012 03:25:52 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document defines a XML data format used to remove entries from an = atom feed. The document does make use of the XML digital signature and = encryption specifications from the W3C to provide integrity, = authenticity and confidentiality. Key management for the encryption is = not discussed, however this seems to be consistent with other AtomPub = documents. How a message is authorized is not described in much = detail. In the security considerations there is mention that it is = expected that the delete message will be signed using the same key as = the particular feed but how to handle this seems to be largely out of = scope of the document. Both of these are not necessarily problems in = themselves, but could lead to interop and manageability problems. = Since the deleted entry document may contain an IRI perhaps it would be = good to reference the security considerations in RFC 3987.=20 Cheers, Joe= From kent@bbn.com Wed Feb 22 17:32:17 2012 Return-Path: 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 61D2821E801D for ; Wed, 22 Feb 2012 17:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.37 X-Spam-Level: X-Spam-Status: No, score=-106.37 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQieTOQxVdwn for ; Wed, 22 Feb 2012 17:32:16 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 95A6E21E8013 for ; Wed, 22 Feb 2012 17:32:16 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:55370 helo=[172.20.8.192]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S0NXP-000GSf-E6; Wed, 22 Feb 2012 20:32:03 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92188B034F@SZXEML506-MBS.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B92188B034F@SZXEML506-MBS.china.huawei.com> Date: Wed, 22 Feb 2012 20:31:48 -0500 To: Sheng Jiang From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-882161773==_ma============" Cc: "secdir@ietf.org" , "shenshuo@cnnic.cn" , "rdroms.ietf@gmail.com" , "john_brzozowski@cable.comcast.com" , Sheng Jiang , "ted.lemon@nominum.com" Subject: Re: [secdir] review of draft-ietf-dhc-secure-dhcpv6-04.txt X-BeenThere: secdir@ietf.org 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: Thu, 23 Feb 2012 01:32:17 -0000 --============_-882161773==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 2:33 AM +0000 2/22/12, Sheng Jiang wrote: >Hi, Stephen, > >Thanks for your review. I have integrated them in a new version or >make some correspondent improvements. However, I do not agree the >below comment and would like to discuss it further. > > The fact that the signature option can be placed anywhere >in the DHCPv6 message strikes me as dangerous. It imposes a >requirement on a receiver to treat the protected and unprotected >portions of the message differently, for any possible placement of >the signature option. This adds complexity to implementations, since >the security checking would have to indicate to the rest of message >processing which parts of a message were checked and which were not >verified. Unless there are DHCHv6 options that may be modified (or >added) legitimately when a message traverses a relay, it is not >clear why there needs to be a provision to exclude any portions of a >DHCPv6 message from the integrity/authentication check. > > The charge is not right here. Although the signature option >can be placed anywhere, it actually protects ALL DHCPv6 options and >payload (except for itself and auth option), see Section 5.2 for how >to perform signature. Therefore, there is no unprotected portion at >all. The place of signature option does not mean the portion after >it is unprotected. The text in 5.2 states, when it describes the Sig option: "It protects all the DHCPv6 header and options before it. Any options after the Signature option can be processed, but it should be noticed that they are not protected by this Signature option." This text contradicts what you said above. The text later in 5.2, in the discussion of how to compute the sig value, says what you meant (sort of), but that contradicts the text cited above. Also, the text describing how to compute the sig is incorrect, since it says: " The signature constructed by using the sender's private key over the following sequence of octets:..." The private key is used to sign the hash value computed over the sequence of octets described in this part of 5.2. Also, allowing the sig option to appear anywhere in the message is, as I indicated earlier, a bad idea. Even if the text is corrected to make clear that the whole message is protected, it is "cleaner" to put the sig option at the end, so that the sender and receiver does not have to skip over it in computing the hash value that is to be signed. Steve --============_-882161773==_ma============ Content-Type: text/html; charset="us-ascii" RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt
At 2:33 AM +0000 2/22/12, Sheng Jiang wrote:
Hi, Stephen,
 
Thanks for your review. I have integrated them in a new version or make some correspondent improvements. However, I do not agree the below comment and would like to discuss it further.
 
<Stephen> The fact that the signature option can be placed anywhere in the DHCPv6 message strikes me as dangerous. It imposes a requirement on a receiver to treat the protected and unprotected portions of the message differently, for any possible placement of the signature option. This adds complexity to implementations, since the security checking would have to indicate to the rest of message processing which parts of a message were checked and which were not verified. Unless there are DHCHv6 options that may be modified (or added) legitimately when a message traverses a relay, it is not clear why there needs to be a provision to exclude any portions of a DHCPv6 message from  the integrity/authentication check.
 
<Sheng> The charge is not right here. Although the signature option can be placed anywhere, it actually protects ALL DHCPv6 options and payload (except for itself and auth option), see Section 5.2 for how to perform signature. Therefore, there is no unprotected  portion at all. The place of signature option does not mean the portion after it is unprotected.

The text in 5.2 states, when it describes the Sig option:

"It protects all the DHCPv6 header and options before it. Any options after the Signature option can be processed, but it should be noticed that they are not protected by this Signature option."

This text contradicts what you said above. The text later in 5.2, in the discussion of how to compute the sig value, says what you meant (sort of), but that contradicts the text cited above.  Also, the text describing how to compute the sig is incorrect, since it says:

" The signature constructed by using the sender's private key over the following sequence of octets:..."

The private key is used to sign the hash value computed over the sequence of octets described in this part of 5.2. Also, allowing the sig option  to appear anywhere in the message is, as I indicated earlier, a bad idea. Even if the text is corrected to make clear that the whole message is protected, it is "cleaner" to put the sig option at the end, so that the sender and receiver does not have to skip over it in computing the hash value that is to be signed.

Steve
--============_-882161773==_ma============-- From jiangsheng@huawei.com Wed Feb 22 17:39:32 2012 Return-Path: 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 BC39E21F8527 for ; Wed, 22 Feb 2012 17:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5XMadMyGWJ7 for ; Wed, 22 Feb 2012 17:39:31 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id BD01F21F8522 for ; Wed, 22 Feb 2012 17:39:30 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZT008J7OLP5J@szxga04-in.huawei.com> for secdir@ietf.org; Thu, 23 Feb 2012 09:39:25 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZT00IAVOLGAD@szxga04-in.huawei.com> for secdir@ietf.org; Thu, 23 Feb 2012 09:39:25 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGZ93729; Thu, 23 Feb 2012 09:39:24 +0800 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 23 Feb 2012 09:39:05 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.20]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Thu, 23 Feb 2012 09:39:18 +0800 Date: Thu, 23 Feb 2012 01:39:17 +0000 From: Sheng Jiang In-reply-to: X-Originating-IP: [10.108.4.88] To: Stephen Kent Message-id: <5D36713D8A4E7348A7E10DF7437A4B92188B095A@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_r+qy3YkjBITemwCMmeXN/w)" Content-language: zh-CN Accept-Language: en-GB, zh-CN, en-US Thread-topic: review of draft-ietf-dhc-secure-dhcpv6-04.txt Thread-index: AQHM1wVGR+IsEftM3kywUBVOpvWIcZYUcUbwgDPx0pCAAP6SAIAAhvYA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <5D36713D8A4E7348A7E10DF7437A4B92188B034F@SZXEML506-MBS.china.huawei.com> Cc: "rdroms.ietf@gmail.com" , "john_brzozowski@cable.comcast.com" , "ted.lemon@nominum.com" , "shenshuo@cnnic.cn" , "secdir@ietf.org" Subject: Re: [secdir] review of draft-ietf-dhc-secure-dhcpv6-04.txt X-BeenThere: secdir@ietf.org 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: Thu, 23 Feb 2012 01:39:32 -0000 --Boundary_(ID_r+qy3YkjBITemwCMmeXN/w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Stephen, Thanks for point out the incorrect text. It was there from early stage design. I have corrected it in the new version. Many thanks, Sheng From: Stephen Kent [mailto:kent@bbn.com] Sent: Thursday, February 23, 2012 9:32 AM To: Sheng Jiang Cc: Sheng Jiang; secdir@ietf.org; shenshuo@cnnic.cn; ted.lemon@nominum.com; john_brzozowski@cable.comcast.com; rdroms.ietf@gmail.com; Stephen Kent Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt At 2:33 AM +0000 2/22/12, Sheng Jiang wrote: Hi, Stephen, Thanks for your review. I have integrated them in a new version or make some correspondent improvements. However, I do not agree the below comment and would like to discuss it further. The fact that the signature option can be placed anywhere in the DHCPv6 message strikes me as dangerous. It imposes a requirement on a receiver to treat the protected and unprotected portions of the message differently, for any possible placement of the signature option. This adds complexity to implementations, since the security checking would have to indicate to the rest of message processing which parts of a message were checked and which were not verified. Unless there are DHCHv6 options that may be modified (or added) legitimately when a message traverses a relay, it is not clear why there needs to be a provision to exclude any portions of a DHCPv6 message from the integrity/authentication check. The charge is not right here. Although the signature option can be placed anywhere, it actually protects ALL DHCPv6 options and payload (except for itself and auth option), see Section 5.2 for how to perform signature. Therefore, there is no unprotected portion at all. The place of signature option does not mean the portion after it is unprotected. The text in 5.2 states, when it describes the Sig option: "It protects all the DHCPv6 header and options before it. Any options after the Signature option can be processed, but it should be noticed that they are not protected by this Signature option." This text contradicts what you said above. The text later in 5.2, in the discussion of how to compute the sig value, says what you meant (sort of), but that contradicts the text cited above. Also, the text describing how to compute the sig is incorrect, since it says: " The signature constructed by using the sender's private key over the following sequence of octets:..." The private key is used to sign the hash value computed over the sequence of octets described in this part of 5.2. Also, allowing the sig option to appear anywhere in the message is, as I indicated earlier, a bad idea. Even if the text is corrected to make clear that the whole message is protected, it is "cleaner" to put the sig option at the end, so that the sender and receiver does not have to skip over it in computing the hash value that is to be signed. Steve --Boundary_(ID_r+qy3YkjBITemwCMmeXN/w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt

Hi, Stephen,

 <= /p>

Thanks for point out the = incorrect text. It was there from early stage design. I have corrected it i= n the new version.

 <= /p>

Many thanks,

 <= /p>

Sheng

 <= /p>

From: Stephen = Kent [mailto:kent@bbn.com]
Sent: Thursday, February 23, 2012 9:32 AM
To: Sheng Jiang
Cc: Sheng Jiang; secdir@ietf.org; shenshuo@cnnic.cn; ted.lemon@nomin= um.com; john_brzozowski@cable.comcast.com; rdroms.ietf@gmail.com; Stephen K= ent
Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt

 

At 2:33 AM +0000 2/22/12, Sheng Jiang wrote:

Hi, Stephen,

 

Thanks for your review. I have integrated them in a = new version or make some correspondent improvements. However, I do not agre= e the below comment and would like to discuss it further.

 

<Stephen> The fact that the signature option c= an be placed anywhere in the DHCPv6 message strikes me as dangerous. It imp= oses a requirement on a receiver to treat the protected and unprotected por= tions of the message differently, for any possible placement of the signature option. This adds complexity to implem= entations, since the security checking would have to indicate to the rest o= f message processing which parts of a message were checked and which were n= ot verified. Unless there are DHCHv6 options that may be modified (or added) legitimately when a message traver= ses a relay, it is not clear why there needs to be a provision to exclude a= ny portions of a DHCPv6 message from  the integrity/authentication che= ck.

 

<Sheng> The charge is not right here. Although= the signature option can be placed anywhere, it actually protects ALL DHCP= v6 options and payload (except for itself and auth option), see Section 5.2= for how to perform signature. Therefore, there is no unprotected  portion at all. The place of signature optio= n does not mean the portion after it is unprotected.

 

The text in 5.2 states, when it describes the Sig op= tion:

 

"It protects all the DHCPv6 header and options before it.= Any options after the Signature option can be processed, but it should be = noticed that they are not protected by this Signature option."

 

This text contradicts what you said above. The text later in 5= .2, in the discussion of how to compute the sig value, says what you meant = (sort of), but that contradicts the text cited above.  Also, the text describing how to compute the sig i= s incorrect, since it says:

 

" The signature constructed by using the sender's private= key over the following sequence of octets:..."

 

The private key is used to sign the hash value computed= over the sequence of octets described in this part of 5.2. Also, allowing = the sig option  to appear anywhere in the message is, as I indicated earlier, a bad idea. Even if the text is co= rrected to make clear that the whole message is protected, it is "clea= ner" to put the sig option at the end, so that the sender and receiver= does not have to skip over it in computing the hash value that is to be signed.

 

Steve

--Boundary_(ID_r+qy3YkjBITemwCMmeXN/w)-- From weiler+secdir@watson.org Thu Feb 23 07:04:49 2012 Return-Path: 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 71D4921F859B for ; Thu, 23 Feb 2012 07:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQf5zWXF4Pmx for ; Thu, 23 Feb 2012 07:04:48 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 73EFA21F8768 for ; Thu, 23 Feb 2012 07:04:48 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q1NF4kj0092469 for ; Thu, 23 Feb 2012 10:04:47 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q1NF4j0V092460 for ; Thu, 23 Feb 2012 10:04:46 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 23 Feb 2012 10:04:45 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 23 Feb 2012 10:04:47 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 15:04:49 -0000 We have lots of documents, some recently assigned, that are on next week's IESG telechat. Reviews by tomorrow would be appreciated. -- Sam Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Charlie Kaufman is next in the rotation. For telechat 2012-03-01 Reviewer LC end Draft Alan DeKok T 2012-02-23 draft-ietf-lisp-interworking-04 Donald Eastlake T 2012-02-27 draft-ietf-manet-packetbb-sec-08 Shawn Emery T 2012-02-27 draft-ietf-manet-smf-13 Tobias Gondrom T 2012-02-29 draft-ietf-mext-mip6-tls-03 Phillip Hallam-Baker T 2012-02-23 draft-ietf-pcn-3-in-1-encoding-08 Steve Hanna T 2012-02-23 draft-ietf-pcn-encoding-comparison-08 Dan Harkins T 2012-02-27 draft-ietf-pcp-base-23 Hilarie Orman T 2012-03-01 draft-ietf-dnsext-ecdsa-06 Carl Wallace T 2012-02-21 draft-ietf-netext-pmip-lr-08 For telechat 2012-03-15 Reviewer LC end Draft Leif Johansson T 2012-03-06 draft-ietf-decade-problem-statement-05 Nico Williams T 2012-03-14 draft-garcia-shim6-applicability-03 Last calls and special requests: Reviewer LC end Draft Derek Atkins 2012-02-28 draft-ietf-adslmib-gbond-mib-09 Rob Austein 2012-02-28 draft-ietf-adslmib-gbond-tdim-mib-07 Richard Barnes 2012-02-28 draft-ietf-core-link-format-11 Dave Cridland 2012-02-23 draft-ietf-l3vpn-mvpn-wildcards-02 Paul Hoffman 2012-03-16 draft-reschke-http-status-308-05 Jeffrey Hutzelman 2012-03-21 draft-betts-itu-oam-ach-code-point-03 Leif Johansson R2012-02-07 draft-ietf-oauth-v2-23 Tim Polk 2012-02-07 draft-ietf-oauth-v2-bearer-17 Eric Rescorla 2012-02-08 draft-ietf-sieve-notify-sip-message-08 Vincent Roca 2012-02-06 draft-ietf-simple-chat-13 Klaas Wierenga 2012-03-08 draft-desruisseaux-caldav-sched-10 Tom Yu 2012-02-28 draft-ietf-adslmib-gbond-atm-mib-05 Glen Zorn 2012-02-28 draft-ietf-adslmib-gbond-eth-mib-05 From shanna@juniper.net Fri Feb 24 22:56:44 2012 Return-Path: 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 805B921E803A; Fri, 24 Feb 2012 22:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Pim7SFiunjL; Fri, 24 Feb 2012 22:56:43 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id E995911E8072; Fri, 24 Feb 2012 22:56:42 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKT0iGKe4Z3y64yN/2lMgI/ZkltpwpMopD@postini.com; Fri, 24 Feb 2012 22:56:43 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 24 Feb 2012 22:50:39 -0800 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 24 Feb 2012 22:50:38 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Sat, 25 Feb 2012 01:50:38 -0500 From: Stephen Hanna To: "secdir@ietf.org" , "draft-ietf-pcn-encoding-comparison.all@ietf.org" Date: Sat, 25 Feb 2012 01:50:37 -0500 Thread-Topic: secdir review of draft-ietf-pcn-encoding-comparison-08 Thread-Index: Aczzg5nO9eyUrqP+Tja49My4hOy8Rg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Cc: "iesg@ietf.org" Subject: [secdir] secdir review of draft-ietf-pcn-encoding-comparison-08 X-BeenThere: secdir@ietf.org 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: Sat, 25 Feb 2012 06:56:44 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document describes a variety of approaches for encoding pre-congestion information into the IP header. The document claims that all relevant security considerations are covered in RFC 5559 and so far as I can tell this is correct since these approaches all fit within the architecture defined by RFC 5559 and the security considerations for that document appear to be adequate. In any case, this document does not include any normative text. Whichever approach or approaches are eventually selected for standardization will presumably need to come back to IESG for approval. A more detailed security analysis of the approaches can be done at that time. >From a security perspective, I see no obstacle to approval of this document at this time. I will say that the document is rather difficult to understand if you're not well versed in PCN technology. I believe that I have understood enough to evaluate the security aspects of the document but I would not claim that I understood the document at a deep level. This may be fine but it will certainly reduce the number of useful reviews that the document will get. Thanks, Steve From rbarnes@bbn.com Sat Feb 25 02:40:49 2012 Return-Path: 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 AB54021F8555; Sat, 25 Feb 2012 02:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.512 X-Spam-Level: X-Spam-Status: No, score=-106.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7p0lVnMuTV9; Sat, 25 Feb 2012 02:40:45 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D2AA021F8554; Sat, 25 Feb 2012 02:40:44 -0800 (PST) Received: from [128.89.255.192] (port=65027) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S1F3L-000KT2-21; Sat, 25 Feb 2012 05:40:36 -0500 From: Richard Barnes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 25 Feb 2012 11:40:36 +0100 Message-Id: <3E9A3BC9-6AEB-4E03-A053-5E7A172DA4E7@bbn.com> To: secdir@ietf.org, iesg@ietf.org, draft-ietf-core-link-format@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [secdir] secdir review of draft-ietf-core-link-format-11 X-BeenThere: secdir@ietf.org 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: Sat, 25 Feb 2012 10:40:49 -0000 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. This document defines a format for describing a list of resources linked = from a server, e.g., an HTTP or CoAP server. The document suggests the = use of TLS or DTLS on the underlying transport for transport security. = My only remaining security concern is that there could be access control = concerns as well. For example, a server might not authorize all clients = to see all services, or might provide some clients with different levels = of access (e.g., read vs. read/write). The document already envisions = that the list of links will have some dynamism, allowing for filtering = based on link attributes. I would suggest simply noting that servers = may want to support HTTP, CoAP, or [D]TLS client authentication and = adaptation of the list of returned links based on the client's identity = and authorizations. =20 Suggested text for Section 6: " Some servers may provide resource discovery services to a mix of clients = that are trusted to different levels. For example, a lighting control = system might allow any client to read state variables, but only certain = clients to write state (turn lights on or off). Servers SHOULD support = authentication features of the underlying transport protocols (HTTP, = CoAP, or DTLS/TLS) and allow operators to return different lists of = links based on a client's identity and authorization. " Non security-related comments follow. General: This document seems a little bit awkward semantically. The = HTTP Link header is intended to provide links from a given resource = (identified by the request URI) to associated resources. The service = described in this document seems to provide a general list of URIs, = without a firm idea of what the "source" of these references is. = Indeed, with the "anchor" parameter, it seems like this document allows = a service at "/.well-known/core" to act as a general "Tell me about this = URI" service, which seems over-broad. Is this the intent of the WG? = Perhaps the "anchor" parameter should be restricted to relative, not = absolute, URIs? And how is this different from just doing a HEAD = request to the URI to get a Link header that would contain the same = information? General: In a similar vein, it seems like this format need not = necessarily be restricted to CORE. Might it not have more general = utility for HTTP service discovery? Really the only impact would be to = change the name of the well-known URI from "core" to something more = generic. Section 1.2.1: Quotes or angle-brackets around "/.well-known/core" Section 1.2.3: The word "filtering" is used here before it is defined. Section 2: The document hints at conversion from the HTTP Link header a = couple of times. It seems like it would be helpful to lay out the = conversion rules in detail. It seems like you may at least need to = convert some things to UTF-8? Section 2.1: It sounds like the default context URI you're envisioning = here is essentially the same as the Origin associated with the scheme, = host, and port: Section 3.1: s/semantically important/application specific semantic/ Section 3.3: The MTU might not be the relevant metric for TCP-based = transport (e.g., HTTP) Section 4.1: It seems like the byte-equality matching here might create = a disconnect here between the query patterns you can write and = parameters you can have. In particular, it seems like you might at = least need to decode percent-encoding before comparison. Otherwise, you = might have parameters that are un-filterable. Section 7.3: Should the "Encoding considerations" say something about it = always being UTF-8? From mohamed.boucadair@orange.com Tue Feb 21 22:59:47 2012 Return-Path: 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 5DB3321E8067 for ; Tue, 21 Feb 2012 22:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcYSMhWYH3qi for ; Tue, 21 Feb 2012 22:59:46 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B29FB21E8040 for ; Tue, 21 Feb 2012 22:59:46 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 6FCCA32449F; Wed, 22 Feb 2012 07:59:45 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 557B84C015; Wed, 22 Feb 2012 07:59:45 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 22 Feb 2012 07:59:45 +0100 From: To: Tina TSOU , "secdir@ietf.org" Date: Wed, 22 Feb 2012 07:59:44 +0100 Thread-Topic: SECDIR Review of draft-ietf-behave-64-analysis-05 Thread-Index: AQHM8LYw0IRIEsAc3UiAv56rwcxZfpZIfK2Q Message-ID: <94C682931C08B048B7A8645303FDC9F35D88A13AB8@PUEXCB1B.nanterre.francetelecom.fr> References: <688B3A69-603E-40A5-86FD-74F27250FD26@huawei.com> In-Reply-To: <688B3A69-603E-40A5-86FD-74F27250FD26@huawei.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.2.22.55416 X-Mailman-Approved-At: Sat, 25 Feb 2012 09:28:48 -0800 Cc: "draft-ietf-behave-64-analysis@tools.ietf.org" Subject: Re: [secdir] SECDIR Review of draft-ietf-behave-64-analysis-05 X-BeenThere: secdir@ietf.org 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: Wed, 22 Feb 2012 06:59:47 -0000 Hi Tina, Thank you for your review and for the suggestion. Cheers, Med=20 > -----Message d'origine----- > De : Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]=20 > Envoy=E9 : mardi 21 f=E9vrier 2012 17:31 > =C0 : secdir@ietf.org > Cc : draft-ietf-behave-64-analysis@tools.ietf.org > Objet : SECDIR Review of draft-ietf-behave-64-analysis-05 >=20 > I don't see any security concerns as we don't define any new protocol. > I have a small suggestion though: > The Abstract of the draft somehow doesn't truly reflect the=20 > actual description of the draft. This draft analyzes how NAT=20 > 64 confirms to RFC 4966, which problems mentioned in 4966 are=20 > solved, which are not solved etc. Whereas the abstract=20 > mentions "This document evaluate how the new stateful=20 > translation mechanisms avoid the problems that caused the=20 > IETF to deprecate NAT-PT." I think we can be more specific here. >=20 > Sent from my iPad > = From leifj@sunet.se Sun Feb 26 12:43:56 2012 Return-Path: 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 DAD1421F84F9; Sun, 26 Feb 2012 12:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afEC9SyEKtBA; Sun, 26 Feb 2012 12:43:56 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id D42D021F84F3; Sun, 26 Feb 2012 12:43:55 -0800 (PST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q1QKhlm8013338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Feb 2012 21:43:51 +0100 (CET) Message-ID: <4F4A9982.20600@sunet.se> Date: Sun, 26 Feb 2012 21:43:46 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: iesg@ietf.org, draft-ietf-oauth-v2.all@tools.ietf.org, secdir@ietf.org X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-ietf-oauth-v2-23 X-BeenThere: secdir@ietf.org 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: Sun, 26 Feb 2012 20:43:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. This is a "re-visit" of a review I did of -22 of this specification and so I'm only focusing on significant differences: - - Overall -23 adds clarifications throughout the text and -23 is the better for it. Breaking out TLS requirements to a separate section makes the text more readable too. - - The new section on interoperability talks about future work and profiling but doesn't constrain future profiles in any way. To me this only punts on the issue of interoperability. I understand this is a hard problem. I suggest at least adding a list of parameters and other elements subject to profiling and if possible list any constraints on such profiles. - - Several of the comments I made in my earlier review have been addressed, specifically those dealing with consistent use of terms and normative language. - - I like the text in 10.10 giving advice on generating tokens and credentials. However the text gives specific entropy constraints but doesn't talk about using rate-limiting as protection against online guessing attacks. A good source for this is NIST SP 800-63 Appendix A. Also I'm not sure entropy constraints are appropriate for a protocol specification but barring the introduction of identity assurance for OAuth I don't have a better idea. I suggest noting that these constraints are subject to revision with state of the art in online guessing so implementors don't get too married to these particular numbers. Best Leif Johansson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9KmX4ACgkQ8Jx8FtbMZncBzwCfV0NOmp+I+PQI1n6vdvtZM8/X HSQAoL2wz8DOCAbMCXwHa4zwUjsMBZon =Jx3y -----END PGP SIGNATURE----- From jiangsheng@huawei.com Mon Feb 27 00:18:09 2012 Return-Path: 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 ACB2C21F8528 for ; Mon, 27 Feb 2012 00:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wY8vIpBsrw+J for ; Mon, 27 Feb 2012 00:18:07 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8378621F8540 for ; Mon, 27 Feb 2012 00:18:05 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M01007OXLPWAB@szxga03-in.huawei.com> for secdir@ietf.org; Mon, 27 Feb 2012 16:17:56 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M010071SLPWW2@szxga03-in.huawei.com> for secdir@ietf.org; Mon, 27 Feb 2012 16:17:56 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHB75477; Mon, 27 Feb 2012 16:17:04 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 27 Feb 2012 16:16:36 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.20]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 27 Feb 2012 16:16:57 +0800 Date: Mon, 27 Feb 2012 08:16:56 +0000 From: Sheng Jiang X-Originating-IP: [10.108.4.88] To: Sheng Jiang , Stephen Kent Message-id: <5D36713D8A4E7348A7E10DF7437A4B92188B1DF2@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Iail226E+BvXNTAM6H5I7Q)" Content-language: zh-CN Accept-Language: en-GB, zh-CN, en-US Thread-topic: review of draft-ietf-dhc-secure-dhcpv6-04.txt Thread-index: AQHM1wVGR+IsEftM3kywUBVOpvWIcZYUcUbwgDPx0pCAAP6SAIAAhvYAgAanwQA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <5D36713D8A4E7348A7E10DF7437A4B92188B034F@SZXEML506-MBS.china.huawei.com> Cc: "rdroms.ietf@gmail.com" , "john_brzozowski@cable.comcast.com" , "ted.lemon@nominum.com" , "shenshuo@cnnic.cn" , "secdir@ietf.org" Subject: Re: [secdir] review of draft-ietf-dhc-secure-dhcpv6-04.txt X-BeenThere: secdir@ietf.org 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, 27 Feb 2012 08:18:09 -0000 --Boundary_(ID_Iail226E+BvXNTAM6H5I7Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Stephen, We are still working on your comments. You wrote "it appears that algorithm agility support for Secure DHCPv6 is based (in large part) on carrying the hash and signature algorithm IDs in the Signature Option. That is different from the RFC 4270 analysis of how to enable algorithm agility for the CGA itself." Could you give further suggestion: if you don't like the way of agility support? What is better mechanism to support algorithm agility in our approach? Many thanks and best regards, Sheng From: Sheng Jiang Sent: Thursday, February 23, 2012 9:39 AM To: 'Stephen Kent' Cc: secdir@ietf.org; shenshuo@cnnic.cn; ted.lemon@nominum.com; john_brzozowski@cable.comcast.com; rdroms.ietf@gmail.com Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt Hi, Stephen, Thanks for point out the incorrect text. It was there from early stage design. I have corrected it in the new version. Many thanks, Sheng From: Stephen Kent [mailto:kent@bbn.com] Sent: Thursday, February 23, 2012 9:32 AM To: Sheng Jiang Cc: Sheng Jiang; secdir@ietf.org; shenshuo@cnnic.cn; ted.lemon@nominum.com; john_brzozowski@cable.comcast.com; rdroms.ietf@gmail.com; Stephen Kent Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt At 2:33 AM +0000 2/22/12, Sheng Jiang wrote: Hi, Stephen, Thanks for your review. I have integrated them in a new version or make some correspondent improvements. However, I do not agree the below comment and would like to discuss it further. The fact that the signature option can be placed anywhere in the DHCPv6 message strikes me as dangerous. It imposes a requirement on a receiver to treat the protected and unprotected portions of the message differently, for any possible placement of the signature option. This adds complexity to implementations, since the security checking would have to indicate to the rest of message processing which parts of a message were checked and which were not verified. Unless there are DHCHv6 options that may be modified (or added) legitimately when a message traverses a relay, it is not clear why there needs to be a provision to exclude any portions of a DHCPv6 message from the integrity/authentication check. The charge is not right here. Although the signature option can be placed anywhere, it actually protects ALL DHCPv6 options and payload (except for itself and auth option), see Section 5.2 for how to perform signature. Therefore, there is no unprotected portion at all. The place of signature option does not mean the portion after it is unprotected. The text in 5.2 states, when it describes the Sig option: "It protects all the DHCPv6 header and options before it. Any options after the Signature option can be processed, but it should be noticed that they are not protected by this Signature option." This text contradicts what you said above. The text later in 5.2, in the discussion of how to compute the sig value, says what you meant (sort of), but that contradicts the text cited above. Also, the text describing how to compute the sig is incorrect, since it says: " The signature constructed by using the sender's private key over the following sequence of octets:..." The private key is used to sign the hash value computed over the sequence of octets described in this part of 5.2. Also, allowing the sig option to appear anywhere in the message is, as I indicated earlier, a bad idea. Even if the text is corrected to make clear that the whole message is protected, it is "cleaner" to put the sig option at the end, so that the sender and receiver does not have to skip over it in computing the hash value that is to be signed. Steve --Boundary_(ID_Iail226E+BvXNTAM6H5I7Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt

Hi, Stephen,

 <= /p>

We are still working on y= our comments. You wrote “it appears = that algorithm agility support for Secure DHCPv6 is based (in large part) on carrying the hash and signature algorithm IDs in the Signature Op= tion. That is different from the RFC 4270 analysis of how to enable algorit= hm agility for the CGA itself.”=

 <= /p>

Could you give further su= ggestion: if you don’t like the way of agility support? What is bette= r mechanism to support algorithm agility in our approach?=

 <= /p>

Many thanks and best rega= rds,

 <= /p>

Sheng

 <= /p>

From: Sheng Ji= ang
Sent: Thursday, February 23, 2012 9:39 AM
To: 'Stephen Kent'
Cc: secdir@ietf.org; shenshuo@cnnic.cn; ted.lemon@nominum.com; john_= brzozowski@cable.comcast.com; rdroms.ietf@gmail.com
Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt

 

Hi, Stephen,

 <= /p>

Thanks for point out the = incorrect text. It was there from early stage design. I have corrected it i= n the new version.

 <= /p>

Many thanks,

 <= /p>

Sheng

 <= /p>

From: Stephen = Kent [mailto:kent@bbn.com]
Sent: Thursday, February 23, 2012 9:32 AM
To: Sheng Jiang
Cc: Sheng Jiang; secdir@ietf.org; shenshuo@cnnic.cn; ted.lemon@nomin= um.com; john_brzozowski@cable.comcast.com; rdroms.ietf@gmail.com; Stephen K= ent
Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt

 

At 2:33 AM +0000 2/22/12, Sheng Jiang wrote:

Hi, Stephen,

 

Thanks for your review. I have integrated them in a = new version or make some correspondent improvements. However, I do not agre= e the below comment and would like to discuss it further.

 

<Stephen> The fact that the signature option c= an be placed anywhere in the DHCPv6 message strikes me as dangerous. It imp= oses a requirement on a receiver to treat the protected and unprotected por= tions of the message differently, for any possible placement of the signature option. This adds complexity to implem= entations, since the security checking would have to indicate to the rest o= f message processing which parts of a message were checked and which were n= ot verified. Unless there are DHCHv6 options that may be modified (or added) legitimately when a message traver= ses a relay, it is not clear why there needs to be a provision to exclude a= ny portions of a DHCPv6 message from  the integrity/authentication che= ck.

 

<Sheng> The charge is not right here. Although= the signature option can be placed anywhere, it actually protects ALL DHCP= v6 options and payload (except for itself and auth option), see Section 5.2= for how to perform signature. Therefore, there is no unprotected  portion at all. The place of signature optio= n does not mean the portion after it is unprotected.

 

The text in 5.2 states, when it describes the Sig op= tion:

 

"It protects all the DHCPv6 header and options before it.= Any options after the Signature option can be processed, but it should be = noticed that they are not protected by this Signature option."

 

This text contradicts what you said above. The text later in 5= .2, in the discussion of how to compute the sig value, says what you meant = (sort of), but that contradicts the text cited above.  Also, the text describing how to compute the sig i= s incorrect, since it says:

 

" The signature constructed by using the sender's private= key over the following sequence of octets:..."

 

The private key is used to sign the hash value computed= over the sequence of octets described in this part of 5.2. Also, allowing = the sig option  to appear anywhere in the message is, as I indicated earlier, a bad idea. Even if the text is co= rrected to make clear that the whole message is protected, it is "clea= ner" to put the sig option at the end, so that the sender and receiver= does not have to skip over it in computing the hash value that is to be signed.

 

Steve

--Boundary_(ID_Iail226E+BvXNTAM6H5I7Q)-- From derek@ihtfp.com Mon Feb 27 09:41:10 2012 Return-Path: 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 7CB4421F87D8; Mon, 27 Feb 2012 09:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.243 X-Spam-Level: X-Spam-Status: No, score=-101.243 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2KxU5uRZS3A; Mon, 27 Feb 2012 09:41:09 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEAF21F87BF; Mon, 27 Feb 2012 09:41:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id AD6F42600B8; Mon, 27 Feb 2012 12:40:56 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 28985-06; Mon, 27 Feb 2012 12:40:54 -0500 (EST) Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 7E839260027; Mon, 27 Feb 2012 12:40:54 -0500 (EST) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q1RHelQN010849; Mon, 27 Feb 2012 12:40:47 -0500 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Mon, 27 Feb 2012 12:40:45 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: edward.beili@actelis.com, adslmib-chairs@tools.ietf.org, moti.morgenstern@ecitele.com Subject: [secdir] sec-dir review of draft-ietf-adslmib-gbond-mib-09 X-BeenThere: secdir@ietf.org 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, 27 Feb 2012 17:41:10 -0000 Hi, 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. This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, defined in ITU-T recommendations G.998.1, G.998.2 and G.998.3. The MIB modules specific to each bonding technology are defined in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB respectively. The security considerations of this document include a number of warnings and potential threats and suggest the deployment of SNMPv3 as a mitigation. I believe this is sufficient. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nick@inex.ie Mon Feb 27 16:46:45 2012 Return-Path: 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 A33A721E8015; Mon, 27 Feb 2012 16:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlWzbQbvs91j; Mon, 27 Feb 2012 16:46:45 -0800 (PST) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id E2C4F21E800C; Mon, 27 Feb 2012 16:46:44 -0800 (PST) X-Envelope-To: secdir@ietf.org Received: from crumpet.foobar.org (twinkie.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q1S0l9M6022897 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 28 Feb 2012 00:47:15 GMT (envelope-from nick@inex.ie) Message-ID: <4F4C23E7.9030805@inex.ie> Date: Tue, 28 Feb 2012 00:46:31 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Joel jaeggli References: <4F1AE479.2010704@bogus.com> In-Reply-To: <4F1AE479.2010704@bogus.com> X-Enigmail-Version: 1.3.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 27 Feb 2012 16:49:10 -0800 Cc: draft-ietf-v6ops-ipv6-discard-prefix.all@tools.ietf.org, secdir@ietf.org, iesg@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-v6ops-ipv6-discard-prefix-02 X-BeenThere: secdir@ietf.org 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: Tue, 28 Feb 2012 00:46:45 -0000 On 21/01/2012 16:14, Joel jaeggli wrote: > Not a big fan of the use of "however" I think this can be addressed at > minimum by auth48. yes will clear it in auth48 + a couple of other stylistic nitpicks in the intro. Nick > On 1/20/12 10:47 , Chris Lonvick wrote: >> Hi, >> >> 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. >> >> Overall, the document is very straightforward and the Security >> Considerations section is appropriate for the content. >> >> I do have one nit to pass along. I think that a paragraph break is in >> the wrong place in the Introduction. >> >> Current in Introduction: >> (end of first paragraph) >> manner which is efficient, scalable and straightforward to implement. >> For IPv4, some networks configure RTBH installations using [RFC1918] >> address space or the address blocks reserved for documentation in >> [RFC5737]. >> >> However RTBH configurations are not documentation, but operationally >> important features of many public-facing production networks. >> Furthermore, [RFC3849] specifies that the IPv6 documentation prefix >> should be filtered in both local and public contexts. On this basis, >> it is suggested that both private network address blocks and >> documentation prefixes described in [RFC5737] are inappropriate for >> the purpose of RTBH configurations. >> >> Suggested: >> manner which is efficient, scalable and straightforward to implement. >> >> For IPv4, some networks configure RTBH installations using [RFC1918] >> address space or the address blocks reserved for documentation in >> [RFC5737]. However RTBH configurations are not documentation, but >> operationally important features of many public-facing production >> networks. Furthermore, [RFC3849] specifies that the IPv6 documentation >> prefix should be filtered in both local and public contexts. On this >> basis, it is suggested that both private network address blocks and >> documentation prefixes described in [RFC5737] are inappropriate for >> the purpose of RTBH configurations. >> >> Regards, >> Chris From jiangsheng@huawei.com Tue Feb 28 03:18:32 2012 Return-Path: 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 11C1921F861F for ; Tue, 28 Feb 2012 03:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGjLQhWTwtZo for ; Tue, 28 Feb 2012 03:18:31 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5966521F85F7 for ; Tue, 28 Feb 2012 03:18:29 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M03006F1OQQJF@szxga05-in.huawei.com> for secdir@ietf.org; Tue, 28 Feb 2012 19:18:26 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0300ALBOQ8V2@szxga05-in.huawei.com> for secdir@ietf.org; Tue, 28 Feb 2012 19:18:26 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHL85764; Tue, 28 Feb 2012 19:17:52 +0800 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 28 Feb 2012 19:17:30 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.20]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Tue, 28 Feb 2012 19:17:42 +0800 Date: Tue, 28 Feb 2012 11:17:40 +0000 From: Sheng Jiang X-Originating-IP: [10.108.4.88] To: Sheng Jiang , Stephen Kent Message-id: <5D36713D8A4E7348A7E10DF7437A4B92188B2659@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_7PoVbMYukNNVeFUW0G0ZhA)" Content-language: zh-CN Accept-Language: en-GB, zh-CN, en-US Thread-topic: review of draft-ietf-dhc-secure-dhcpv6-04.txt Thread-index: AQHM1wVGR+IsEftM3kywUBVOpvWIcZYUcUbwgDPx0pCAAP6SAIAAhvYAgAanwQCAAb3/sA== X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <5D36713D8A4E7348A7E10DF7437A4B92188B034F@SZXEML506-MBS.china.huawei.com> Cc: "rdroms.ietf@gmail.com" , "john_brzozowski@cable.comcast.com" , "ted.lemon@nominum.com" , "shenshuo@cnnic.cn" , "secdir@ietf.org" Subject: Re: [secdir] review of draft-ietf-dhc-secure-dhcpv6-04.txt X-BeenThere: secdir@ietf.org 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: Tue, 28 Feb 2012 11:18:32 -0000 --Boundary_(ID_7PoVbMYukNNVeFUW0G0ZhA) Content-type: multipart/alternative; boundary="Boundary_(ID_ElouD2TIehDSC4lcQmhl+Q)" --Boundary_(ID_ElouD2TIehDSC4lcQmhl+Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Stephen, We have modified our draft according to your comments. It improves our draft a lot. Could you please review the latest version? The attachment are txt version and the diff Many thanks and best regards, Sheng From: Sheng Jiang Sent: Monday, February 27, 2012 4:17 PM To: Sheng Jiang; 'Stephen Kent' Cc: 'secdir@ietf.org'; 'shenshuo@cnnic.cn'; 'ted.lemon@nominum.com'; 'john_brzozowski@cable.comcast.com'; 'rdroms.ietf@gmail.com' Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt Hi, Stephen, We are still working on your comments. You wrote "it appears that algorithm agility support for Secure DHCPv6 is based (in large part) on carrying the hash and signature algorithm IDs in the Signature Option. That is different from the RFC 4270 analysis of how to enable algorithm agility for the CGA itself." Could you give further suggestion: if you don't like the way of agility support? What is better mechanism to support algorithm agility in our approach? Many thanks and best regards, Sheng From: Sheng Jiang Sent: Thursday, February 23, 2012 9:39 AM To: 'Stephen Kent' Cc: secdir@ietf.org; shenshuo@cnnic.cn; ted.lemon@nominum.com; john_brzozowski@cable.comcast.com; rdroms.ietf@gmail.com Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt Hi, Stephen, Thanks for point out the incorrect text. It was there from early stage design. I have corrected it in the new version. Many thanks, Sheng From: Stephen Kent [mailto:kent@bbn.com] Sent: Thursday, February 23, 2012 9:32 AM To: Sheng Jiang Cc: Sheng Jiang; secdir@ietf.org; shenshuo@cnnic.cn; ted.lemon@nominum.com; john_brzozowski@cable.comcast.com; rdroms.ietf@gmail.com; Stephen Kent Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt At 2:33 AM +0000 2/22/12, Sheng Jiang wrote: Hi, Stephen, Thanks for your review. I have integrated them in a new version or make some correspondent improvements. However, I do not agree the below comment and would like to discuss it further. The fact that the signature option can be placed anywhere in the DHCPv6 message strikes me as dangerous. It imposes a requirement on a receiver to treat the protected and unprotected portions of the message differently, for any possible placement of the signature option. This adds complexity to implementations, since the security checking would have to indicate to the rest of message processing which parts of a message were checked and which were not verified. Unless there are DHCHv6 options that may be modified (or added) legitimately when a message traverses a relay, it is not clear why there needs to be a provision to exclude any portions of a DHCPv6 message from the integrity/authentication check. The charge is not right here. Although the signature option can be placed anywhere, it actually protects ALL DHCPv6 options and payload (except for itself and auth option), see Section 5.2 for how to perform signature. Therefore, there is no unprotected portion at all. The place of signature option does not mean the portion after it is unprotected. The text in 5.2 states, when it describes the Sig option: "It protects all the DHCPv6 header and options before it. Any options after the Signature option can be processed, but it should be noticed that they are not protected by this Signature option." This text contradicts what you said above. The text later in 5.2, in the discussion of how to compute the sig value, says what you meant (sort of), but that contradicts the text cited above. Also, the text describing how to compute the sig is incorrect, since it says: " The signature constructed by using the sender's private key over the following sequence of octets:..." The private key is used to sign the hash value computed over the sequence of octets described in this part of 5.2. Also, allowing the sig option to appear anywhere in the message is, as I indicated earlier, a bad idea. Even if the text is corrected to make clear that the whole message is protected, it is "cleaner" to put the sig option at the end, so that the sender and receiver does not have to skip over it in computing the hash value that is to be signed. Steve --Boundary_(ID_ElouD2TIehDSC4lcQmhl+Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt

Hi, Stephen,

 <= /p>

We have modified our draf= t according to your comments. It improves our draft a lot. Could you please= review the latest version? The attachment are txt version and the diff

 <= /p>

Many thanks and best rega= rds,

 <= /p>

Sheng

 <= /p>

From: Sheng Ji= ang
Sent: Monday, February 27, 2012 4:17 PM
To: Sheng Jiang; 'Stephen Kent'
Cc: 'secdir@ietf.org'; 'shenshuo@cnnic.cn'; 'ted.lemon@nominum.com';= 'john_brzozowski@cable.comcast.com'; 'rdroms.ietf@gmail.com'
Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt

 

Hi, Stephen,

 <= /p>

We are still working on y= our comments. You wrote “it appears = that algorithm agility support for Secure DHCPv6 is based (in large part) on carrying the hash and signature algorithm IDs in the Signature Op= tion. That is different from the RFC 4270 analysis of how to enable algorit= hm agility for the CGA itself.”

 <= /p>

Could you give further su= ggestion: if you don’t like the way of agility support? What is bette= r mechanism to support algorithm agility in our approach?=

 <= /p>

Many thanks and best rega= rds,

 <= /p>

Sheng

 <= /p>

From: Sheng Ji= ang
Sent: Thursday, February 23, 2012 9:39 AM
To: 'Stephen Kent'
Cc: secdir@ietf.org; shenshuo@cnnic.cn; ted.lemon@nominum.com; john_= brzozowski@cable.comcast.com; rdroms.ietf@gmail.com
Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt

 

Hi, Stephen,

 <= /p>

Thanks for point out the = incorrect text. It was there from early stage design. I have corrected it i= n the new version.

 <= /p>

Many thanks,

 <= /p>

Sheng

 <= /p>

From: Stephen = Kent [mailto:kent@bbn.com]
Sent: Thursday, February 23, 2012 9:32 AM
To: Sheng Jiang
Cc: Sheng Jiang; secdir@ietf.org; shenshuo@cnnic.cn; ted.lemon@nomin= um.com; john_brzozowski@cable.comcast.com; rdroms.ietf@gmail.com; Stephen K= ent
Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt

 

At 2:33 AM +0000 2/22/12, Sheng Jiang wrote:

Hi, Stephen,

 

Thanks for your review. I have integrated them in a = new version or make some correspondent improvements. However, I do not agre= e the below comment and would like to discuss it further.

 

<Stephen> The fact that the signature option c= an be placed anywhere in the DHCPv6 message strikes me as dangerous. It imp= oses a requirement on a receiver to treat the protected and unprotected por= tions of the message differently, for any possible placement of the signature option. This adds complexity to implem= entations, since the security checking would have to indicate to the rest o= f message processing which parts of a message were checked and which were n= ot verified. Unless there are DHCHv6 options that may be modified (or added) legitimately when a message traver= ses a relay, it is not clear why there needs to be a provision to exclude a= ny portions of a DHCPv6 message from  the integrity/authentication che= ck.

 

<Sheng> The charge is not right here. Although= the signature option can be placed anywhere, it actually protects ALL DHCP= v6 options and payload (except for itself and auth option), see Section 5.2= for how to perform signature. Therefore, there is no unprotected  portion at all. The place of signature optio= n does not mean the portion after it is unprotected.

 

The text in 5.2 states, when it describes the Sig op= tion:

 

"It protects all the DHCPv6 header and options before it.= Any options after the Signature option can be processed, but it should be = noticed that they are not protected by this Signature option."

 

This text contradicts what you said above. The text later in 5= .2, in the discussion of how to compute the sig value, says what you meant = (sort of), but that contradicts the text cited above.  Also, the text describing how to compute the sig i= s incorrect, since it says:

 

" The signature constructed by using the sender's private= key over the following sequence of octets:..."

 

The private key is used to sign the hash value computed= over the sequence of octets described in this part of 5.2. Also, allowing = the sig option  to appear anywhere in the message is, as I indicated earlier, a bad idea. Even if the text is co= rrected to make clear that the whole message is protected, it is "clea= ner" to put the sig option at the end, so that the sender and receiver= does not have to skip over it in computing the hash value that is to be signed.

 

Steve

--Boundary_(ID_ElouD2TIehDSC4lcQmhl+Q)-- --Boundary_(ID_7PoVbMYukNNVeFUW0G0ZhA) Content-type: text/html; name="Diff draft-ietf-dhc-secure-dhcpv6-04_txt - draft-ietf-dhc-secure-dhcpv6-05_txt.htm" Content-transfer-encoding: 7BIT Content-disposition: attachment; filename="Diff draft-ietf-dhc-secure-dhcpv6-04_txt - draft-ietf-dhc-secure-dhcpv6-05_txt.htm"; size=198401; creation-date="Tue, 28 Feb 2012 09:47:55 GMT"; modification-date="Tue, 28 Feb 2012 09:47:55 GMT" Content-description: Diff draft-ietf-dhc-secure-dhcpv6-04_txt - draft-ietf-dhc-secure-dhcpv6-05_txt.htm Diff: draft-ietf-dhc-secure-dhcpv6-04.txt - draft-ietf-dhc-secure-dhcpv6-05.txt
< draft-ietf-dhc-secure-dhcpv6-04.txt   draft-ietf-dhc-secure-dhcpv6-05.txt >
DHC Working Group Sheng Jiang DHC Working Group Sheng Jiang
Internet Draft Huawei Technologies Co., Ltd Internet Draft Huawei Technologies Co., Ltd
Intended status: Standards Track Sean Shen Intended status: Standards Track Sean Shen
Expires: July 1, 2012 CNNIC Update: RFC3315 CNNIC
December 30, 2011 Expires: September 15, 2012 March 10, 2012
Secure DHCPv6 Using CGAs Secure DHCPv6 Using CGAs
draft-ietf-dhc-secure-dhcpv6-04.txt draft-ietf-dhc-secure-dhcpv6-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 1, 2012. This Internet-Draft will expire on September 15, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract Abstract
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables
DHCP servers to pass configuration parameters. It offers DHCPv6 servers to pass configuration parameters. It offers
configuration flexibility. If not secured, DHCPv6 is vulnerable to configuration flexibility. If not secured, DHCPv6 is vulnerable to
various attacks, particularly fake attack. This document analyzes the various attacks, particularly spoofing attack. This document analyzes
security issues of DHCPv6 and specifies security mechanisms, mainly the security issues of DHCPv6 and specifies a Secure DHCPv6 mechanism
using CGAs. based on using CGAs.
Table of Contents Table of Contents
1. Introduction ................................................ 3 1. Introduction ................................................ 3
2. Terminology ................................................. 3 2. Terminology ................................................. 3
3. Security Overview of DHCPv6 ................................. 3 3. Security Overview of DHCPv6 ................................. 3
4. Secure DHCPv6 Overview ...................................... 4 4. Secure DHCPv6 Overview ...................................... 4
4.1. New Components ......................................... 5 4.1. New Components ......................................... 5
4.2. Support for algorithm agility .......................... 6 4.2. Support for algorithm agility .......................... 5
5. Extension for Secure DHCPv6 ................................. 6 5. Extensions for Secure DHCPv6 ................................ 6
5.1. CGA Parameter Option ................................... 6 5.1. CGA Parameter Option ................................... 6
5.2. Signature Option ....................................... 7 5.2. Signature Option ....................................... 7
5.3. DUID-SA Type .......................................... 10 5.3. DUID-SA Type ........................................... 9
6. Processing Rules and Behaviors ............................. 10 6. Processing Rules and Behaviors .............................. 9
6.1. Processing Rules of Sender ............................ 10 6.1. Processing Rules of Sender ............................. 9
6.2. Processing Rules of Receiver .......................... 11 6.2. Processing Rules of Receiver .......................... 10
6.3. Processing Rules of Relay Agent ....................... 12 6.3. Processing Rules of Relay Agent ....................... 11
7. Security Considerations .................................... 12 7. Security Considerations .................................... 12
8. IANA Considerations ........................................ 13 8. IANA Considerations ........................................ 13
9. Acknowledgments ............................................ 14 9. Acknowledgments ............................................ 14
10. References ................................................ 15 10. References ................................................ 14
10.1. Normative References ................................. 15 10.1. Normative References ................................. 14
10.2. Informative References ............................... 15 10.2. Informative References ............................... 14
Author's Addresses ............................................ 16
1. Introduction 1. Introduction
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6 [RFC3315]) The Dynamic Host Configuration Protocol for IPv6 (DHCPv6 [RFC3315])
enables DHCP servers to pass configuration parameters. It offers enables DHCPv6 servers to pass configuration parameters. It offers
configuration flexibility. If not secured, DHCPv6 is vulnerable to configuration flexibility. If not secured, DHCPv6 is vulnerable to
various attacks, particularly fake attack. various attacks, particularly spoofing attack.
The requirements of using CGA to secure DHCPv6 have been introduced This document analyzes the security issues of DHCPv6 in details. This
in [I-D.draft-ietf-csi-dhcpv6-cga-ps]. This document analyzes the document is aiming to provide mechanisms for improving the security
security issues of DHCPv6 in more details. This document is aiming to of DHCPv6, thus the address of a DHCPv6 message sender, which can be
provide mechanisms for improving the security of DHCPv6, thus the a DHCPv6 server, a relay agent or a client, is able to be verified by
address of a DHCP message sender, which can be a DHCP server, a reply a receiver. It improves communication security of DHCPv6 interaction.
agent or a client, is able to be verified by a receiver. It improves The security mechanisms specified in this document is mainly based on
communication security of DHCPv6 interaction. The security mechanisms the Cryptographically Generated Addresses (CGA [RFC3972]).
specified in this document is mainly based on the Cryptographically
Generated Addresses (CGA [RFC3972]).
Secure DHCPv6 is applicable in environments where physical security Secure DHCPv6 is applicable in environments where physical security
on the link is not assured (such as over wireless) or where available on the link is not assured (such as over wireless) and attacks on
security mechanisms are not sufficient, and attacks on DHCPv6 are a DHCPv6 are a concern.
concern.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Security Overview of DHCPv6 3. Security Overview of DHCPv6
DHCPv6 is a client/server protocol that provides managed and stateful DHCPv6 is a client/server protocol that provides managed
configuration of devices. It enables DHCPv6 server to auto-configure configuration of devices. It enables DHCPv6 server to auto-configure
relevant network parameters on clients through the DHCPv6 message relevant network parameters on clients through the DHCPv6 message
exchanging mechanisms. In the basic DHCPv6 specifications [RFC3315], exchanging mechanisms. In the basic DHCPv6 specifications [RFC3315],
security of DHCPv6 message can be improved in a few aspects. security of DHCPv6 message can be improved in a few aspects.
In the basic DHCPv6 specifications, regular IPv6 addresses are used. a) In the basic DHCPv6 specifications, the DHCPv6 server uses a
It is possible for a malicious attacker to use a fake address to "regular" IPv6 address for itself. It is possible for a malicious
spoof or launch an attack. attacker to use a fake address to spoof or launch an attack. See
Section 23, "Security Considerations" of [RFC3315] for more
"One attack specific to a DHCP client is the establishment of a details.
malicious server with the intent of providing incorrect configuration
information to the client. The motivation for doing so may be to
mount a 'man in the middle' attack that causes the client to
communicate with a malicious server instead of a valid server for
some service such as DNS or NTP. The malicious server may also mount
a denial of service attack through mis-configuration of the client
that causes all network communication from the client to fail."
[RFC3315]
"A DHCP client may also be subject to attack through the receipt of a
Reconfigure message from a malicious server that causes the client to
obtain incorrect configuration information from that server."
[RFC3315]
Fake servers can also provide clients with partially correct Furthermore, if DHCPv6 servers play the role of updating DNS and
information that allows the attacker to route traffic through certain other directory services, attackers may spoof DHCPv6 servers to
host where critical information can be collected. This becomes register incorrect information in those services.
important to detect and prevent when encrypted traffic is allowed to
pass through firewalls. Clients can be configured with bogus data, so
that they will assume that the network is down.
Once servers start updating DNS and other directory services, CGA-based security mechanism can provide source address ownership
attackers may spoof DHCP servers to register incorrect information in proofing, which prevents such attacks.
those services.
Another possible attack is that attackers may be able to gain b) The basic DHCPv6 specifications achieve message origin
unauthorized access to some resources, such as network access. authentication and message integrity via an authentication option
with a symmetric key pair. For the key of the hash function, there
are two key management mechanisms. Firstly, the key management is
out of band, usually manual, i.e. operators set up key database
for both server and client before running DHCPv6. Usually multiple
keys are deployed once a time and key id is used to specify which
key is used. Manual key distribution runs counter to the goal of
minimizing the configuration data needed at each host. Secondly, a
DHCPv6 server sends a reconfigure key to the client in the initial
exchange of DHCPv6 messages for future use, in this case security
is not guaranteed because this key is transmitted in plaintext.
The basic DHCPv6 specifications achieve message origin authentication Comparing to this, CGA-based security mechanism does not request
and message integrity via an authentication option with a symmetric any key management mechanisms.
key pair. For the key of the hash function, there are two key
management mechanisms. Firstly, the key management is out of band,
usually manual, i.e. operators set up key database for both server
and client before running DHCPv6. Usually multiple keys are deployed
once a time and key id is used to specify which key is used.
Secondly, a DHCPv6 server sends a reconfigure key to the client in
the initial exchange of DHCPv6 messages for future use, in this case
security is not guaranteed because this key is transmitted in
plaintext. In either way, the security of key itself is in question
mark.
Communication between a server and a relay agent, and communication c) Communication between a server and a relay agent, and
between relay agents, can be secured through the use of IPSec, as communication between relay agents, can be secured through the use
described in section 21.1 in [RFC3315]. However, IPSec is quite of IPsec, as described in section 21.1 in [RFC3315]. However,
complicated. A simpler security mechanism may have better deploy IPsec is quite complicated. A simpler security mechanism may have
ability. Furthermore, the manual configuration and static keys are better deploy ability.
potential issue makers. Relay agents MAY require other security
mechanisms besides IPSec.
4. Secure DHCPv6 Overview 4. Secure DHCPv6 Overview
To solve the abovementioned security issues, we introduce CGAs into To solve the abovementioned security issues, we introduce CGAs into
DHCPv6. CGAs are introduced in [RFC3972]. "CGAs are IPv6 addresses DHCPv6. CGAs are introduced in [RFC3972]. "CGAs are IPv6 addresses
for which the interface identifier is generated by computing a for which the interface identifier is generated by computing a
cryptographic one-way hash function from a public key and auxiliary cryptographic one-way hash function from a public key and auxiliary
parameters. The binding between the public key and the address can be parameters. The binding between the public key and the address can be
verified by re-computing the hash value and by comparing the hash verified by re-computing the hash value and by comparing the hash
with the interface identifier. Messages sent from an IPv6 address can with the interface identifier. Messages sent from an IPv6 address can
be protected by attaching the public key and auxiliary parameters and be protected by attaching the public key and auxiliary parameters and
by signing the message with the corresponding private key. The by signing the message with the corresponding private key. The
protection works without a certification authority or any security protection works without a certification authority or any security
infrastructure." infrastructure."
This documentation introduces a Secure DHCPv6 mechanism that uses
CGAs to secure the DHCPv6 protocol. It assumes the secured DHCPv6
message sender has already haven CGAs and their correspondent CGA
parameters; and the receiver has already been given the CGAs of the
sender.
In this document, a CGA option with an address ownership proof In this document, a CGA option with an address ownership proof
mechanism and a signature option with a corresponding verification mechanism and a signature option with a corresponding verification
mechanism are introduced. A DHCPv6 message (from either a server, a mechanism are introduced. A DHCPv6 message (from either a server, a
relay agent or a client) with a CGA as source address, can carry the relay agent or a client) with a CGA as source address, can carry the
CGA Parameters data structure and a digital signature. The receiver CGA Parameters data structure and a digital signature. The receiver
of this DHCPv6 message can verify both the CGA and signature, then of this DHCPv6 message, who has already known the CGA of the sender,
process the payload of the DHCPv6 message only if the validation is can verify both the CGA and signature, then process the payload of
successful. the DHCPv6 message only if the validation is successful.
With them, the receiver of a DHCP message can verify the sender can verify both the CGA and signature, then process the payload of
address of the DHCP message, which improves communication security of the DHCPv6 message only if the validation is successful.
DHCP messages. By using the signature option, the verification of
data integrity and replay protections can also be achieved without
the authentication option.
This documentation focuses on using CGAs to secure the DHCPv6 With them, the receiver of a DHCPv6 message can verify the sender
protocol. It assumes the sender, which uses CGAs, has self-generated address of the DHCPv6 message, which improves communication security
or been configured CGAs. The CGA configuration in the DHCPv6 network of DHCPv6 messages. The verification of data integrity and replay
is out of scope and specified in protections can also be achieved without the authentication option.
[I-D.draft-ietf-dhc-cga-config-dhcpv6].
In the relay scenarios, because relay agent restructures the DHCPv6 The sender can be a DHCPv6 server, a relay agent or a client. So, the
messages, a receiver would not find the sender's source CGA address end-to-end security protection can be from DHCPv6 servers to relay
in the DHCPv6 message header. In the client-relay-server scenarios, agents or clients, or from clients to relay agent or DHCPv6 servers.
"the relay agent copies the source address from the header of the IP Relay agents MAY add its own Secure DHCPv6 options, too.
datagram in which the message was received to the peer-address field
of the Relay-forward message" [RFC3315]. The receiver, a DHCPv6
server, can find the sender's source CGA address in the peer-address
field for CGA verification. In the server-relay-client scenarios, a
DHCP server knows a client is behind relay(s) if it receives a Relay-
forward DHCPv6 message. Then it will reply a Relay-reply message with
the server's source CGA address being carried in the server DUID,
which is in the payload. In this way, the receiver, a DHCPv6 client
can get the server's source CGA address for CGA verification. The
server DUID is also protected by CGA.
4.1. New Components 4.1. New Components
The components of the solution specified in this document are as The components of the solution specified in this document are as
follows: follows:
- CGAs are used to make sure that the sender of a DHCPv6 message - CGAs are used to make sure that the sender of a DHCPv6 message
is the "owner" of the claimed address. A public-private key is the "owner" of the claimed address. A public-private key
pair has been generated by a node itself before it can claim an pair has been generated by a node itself before it can claim an
address. A new DHCPv6 option, the CGA Parameter Option, is used address. A new DHCPv6 option, the CGA Parameter Option, is used
to carry the public key and associated parameters. to carry the public key and associated parameters.
- Public key signatures protect the integrity of the messages and - Public key signatures protect the integrity of the DHCPv6
authenticate the identity of their sender. The authority of a messages and authenticate the identity of their sender.
public key is established through the address ownership proof
mechanism, by using CGAs.
- Server Address type of DUID is used to carry server's source - Server Address type of DUID is used to carry server's source
address in the relay scenarios. The receiver gets the server's address in the relay scenarios. The receiver gets the server's
source CGA address for CGA verification. source CGA address for CGA verification.
4.2. Support for algorithm agility 4.2. Support for algorithm agility
Hash functions are the fundamental of security mechanisms, including Hash functions are the fundamental of security mechanisms, including
CGAs in this document. "...they have two security properties: to be CGAs in this document. "...they have two security properties: to be
one way and collision free." "The recent attacks have demonstrated one way and collision free." "The recent attacks have demonstrated
that one of those security properties is not true." [RFC4270] that one of those security properties is not true." [RFC4270] It is
theoretically possible to perform collision attack Attacks against
the "collision-free" property.
Following the approach recommended by [RFC4270] and [NewHash], our Following the approach recommended by [RFC4270] and [NewHash], recent
analysis shows none of these attacks are currently doable. However, analysis shows none of these attacks are currently doable [RFC6273].
these attacks indicate the possibility of future real-world attacks. "The broken security property will not affect the overall security of
Therefore, we have to take into account that future attacks will be many specific Internet protocols, the conservative security approach
improved and provide a support for multiple hash algorithms. Our is to change hash algorithms." [RFC4270]
mechanisms, in this document, support not only hash algorithm agility
but also signature algorithm agility. However, these attacks indicate the possibility of future real-world
attacks. Therefore, we have to take into account that future attacks
will be improved and provide a support for multiple hash algorithms.
Our mechanisms, in this document, support not only hash algorithm
agility but also signature algorithm agility.
The support for hash agility within CGAs has been defined in The support for hash agility within CGAs has been defined in
[RFC4982]. The usage of CGAs in this document SHOULD also obey [RFC4982]. The usage of CGAs in this document SHOULD also obey
[RFC4982], too. [RFC4982], too.
The support for algorithm agility in this document is mainly
unilateral notification model from a sender to a receiver. If the
receiver cannot support the algorithm provided by the sender, it
takes the risk itself. Senders in a same network do not have to
upgrade to a new algorithm simultaneously.
5. Extensions for Secure DHCPv6 5. Extensions for Secure DHCPv6
This section extends DHCPv6. Two new options and a new DUID type have This section extends DHCPv6. Two new options and a new DUID type have
been defined. The new options MUST be supported, if the node has been been defined. The new options MUST be supported in the Secure DHCPv6
configured to use Secure DHCPv6. The new DUID type MUST be supported message exchanging. The new DUID type MUST be supported in the relay
in the relay scenarios. scenarios.
5.1. CGA Parameter Option 5.1. CGA Parameter Option
The CGA option allows the verification of the sender's CGAs. The The CGA option allows the verification of the sender's CGAs. The
format of the CGA option is described as follows: format of the CGA option is described as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CGA_PARAMETER | option-len | | OPTION_CGA_PARAMETER | option-len |
skipping to change at page 7, line 28 skipping to change at page 6, line 53
option-len Length of CGA Parameters in octets. option-len Length of CGA Parameters in octets.
CGA Parameters A variable-length field containing the CGA CGA Parameters A variable-length field containing the CGA
Parameters data structure described in Section 4 Parameters data structure described in Section 4
of [RFC3972]. This specification requires that of [RFC3972]. This specification requires that
the public key found from the CGA Parameters the public key found from the CGA Parameters
field in the CGA option MUST be that referred by field in the CGA option MUST be that referred by
the Key Hash field in the Signature option. the Key Hash field in the Signature option.
Packets received with two different keys MUST be Packets received with two different keys MUST be
silently discarded. Note that a future extension silently discarded.
MAY provide a mechanism allowing the owner of an
address and the signer to be different parties.
5.2. Signature Option 5.2. Signature Option
The Signature option allows public key-based signatures to be The Signature option allows public key-based signatures to be
attached to a DHCPv6 message. The Signature option COULD be any place attached to a DHCPv6 message. The Signature option could be any place
within the DHCPv6 message. It protects all the DHCPv6 header and within the DHCPv6 message. It protects all the DHCPv6 header and
options before it. Any options after the Signature option can be options, particularly including the CGA option, except for the
processed, but it should be noticed that they are not protected by Signature option and the Authentication Option. The format of the
this Signature option. The format of the Signature option is Signature option is described as follows:
described as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SIGNATURE | option-len | | OPTION_SIGNATURE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA-id | SA-id | | HA-id | SA-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA-id-KH | Reserved | | HA-id-KH | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 25 skipping to change at page 7, line 34
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Key Hash (128-bit) | | Key Hash (128-bit) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Signature (variable length) . . Signature (variable length) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Padding .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_SIGNATURE (TBA2). option-code OPTION_SIGNATURE (TBA2).
option-len 32 + Length of signature field in octets. option-len 32 + Length of Signature field and Padding field
in octets.
HA-id Hash Algorithm id. The hash algorithm is used HA-id Hash Algorithm id. The hash algorithm is used
for computing the signature result. RSA for computing the signature result. This design
signature [RSA] with SHA-1 [sha-1] is adopted. is adopted in order to provide hash algorithm
In order to provide hash algorithm agility, SHA- agility.
1 is assigned an initial value 0x0000 in this
document.
SA-id Signature Algorithm id. The signature algorithm SA-id Signature Algorithm id. The signature algorithm
is used for computing the signature result. RSA is used for computing the signature result. This
signature with RSASSA-PKCS1-v1_5 algorithm is design is adopted in order to provide hash
adopted. In order to provide algorithm agility, algorithm agility.
RSASSA_PKCS1-v1_5 is assigned an initial value
0x0000 in this document.
HA-id-KH Hash Algorithm id for Key Hash. Hash algorithm HA-id-KH Hash Algorithm id for Key Hash. Hash algorithm
used for producing the Key Hash field in the used for producing the Key Hash field in the
Signature option. SHA-1 is adopted. In order to Signature option. This design is adopted in
provide hash algorithm agility, SHA-1 is order to provide hash algorithm agility.
assigned an initial value 0x0000 in this
document.
Reserved A 16-bit field reserved for future use. The Reserved A 16-bit field reserved for future use. The
value MUST be initialized to zero by the sender, value MUST be initialized to zero by the sender,
and MUST be ignored by the receiver. and MUST be ignored by the receiver.
Timestamp The current time of day (NTP-format timestamp Timestamp The current time of day (NTP-format timestamp
[RFC5905], a 64-bit unsigned fixed-point number, [RFC5905], a 64-bit unsigned fixed-point number,
in seconds relative to 0h on 1 January 1900.). in seconds relative to 0h on 1 January 1900.).
It can reduce the danger of replay attacks. It can reduce the danger of replay attacks.
Key Hash A 128-bit field containing the most significant Key Hash A 128-bit field containing the most significant
(leftmost) 128 bits of a SHA-1 hash of the (leftmost) 128 bits of the hash value of the
public key used for constructing the signature. public key used for constructing the signature.
The SHA-1 hash is taken over the presentation The hash algorithm is indicated in the HA-id-KH
field. The field is taken over the presentation
used in the Public Key field of the CGA used in the Public Key field of the CGA
Parameters data structure carried in the CGA Parameters data structure carried in the CGA
option. Its purpose is to associate the option. Its purpose is to associate the
signature to a particular key known by the signature to a particular key known by the
receiver. Such a key can either be stored in the receiver. Such a key can either be stored in the
certificate cache of the receiver or be received certificate cache of the receiver or be received
in the CGA option in the same message. in the CGA option in the same message.
Signature A variable-length field containing a digital Signature A variable-length field containing a digital
signature. The signature value is computed with signature. The signature value is computed with
the hash algorithm and the signature algorithm, the hash algorithm and the signature algorithm,
as described in HA-id and SA-id. The signature as described in HA-id and SA-id. The signature
constructed by using the sender's private key constructed by using the sender's private key
over the following sequence of octets: protects the following sequence of octets:
1. The 128-bit CGA Message Type tag value for 1. The 128-bit CGA Message Type tag value for
Secure DHCPv6, 0x81be a1eb 0021 ce7e caa9 4090 Secure DHCPv6, 0x81be a1eb 0021 ce7e caa9 4090
0665 d2e0 02c2. (The tag value has been 0665 d2e0 02c2.
generated randomly by the editor of this
specification.).
2. The 128-bit Source IPv6 Address. 2. The 128-bit Source IPv6 Address.
3. The 128-bit Destination IPv6 Address. 3. The 128-bit Destination IPv6 Address.
4. The DHCPv6 message header. 4. The DHCPv6 message header.
5. All DHCPv6 options except for the Signature 5. All DHCPv6 options except for the Signature
option and the Authentication Option. option and the Authentication Option.
6. The content between the option-len field and 6. The content between the option-len field and
the signature field in this Signature option, in the signature field in this Signature option, in
the format described above. the format described above.
Padding This variable-length field contains padding, as
many bytes long as remain after the end of the
signature.
5.3. DUID-SA Type 5.3. DUID-SA Type
Server Address Type DUID (DUID-SA) allows IP address of DHCPv6 Server Address Type DUID (DUID-SA) allows IP address of DHCPv6
servers can be carried in DHCPv6 message payload. servers can be carried in DHCPv6 message payload.
The following diagram illustrates the format of a DUID-SA: The following diagram illustrates the format of a DUID-SA:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBA3 | Reserved | | TBA3 | Reserved |
skipping to change at page 10, line 30 skipping to change at page 9, line 34
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type-code DUID-SA Type (TBA3) Type-code DUID-SA Type (TBA3)
Reserved A 16-bit field reserved for future use. The Reserved A 16-bit field reserved for future use. The
value MUST be initialized to zero by the sender, value MUST be initialized to zero by the sender,
and MUST be ignored by the receiver. and MUST be ignored by the receiver.
Server Address The 128-bit IPv6 address of the DHCPv6 server. Server Address The 128-bit IPv6 address of the DHCPv6 server.
In the secure DHCPv6 solution, the Server Address field of DUID-SA, The Server Address field of DUID-SA, which is the IPv6 address of the
which is the IPv6 address of the DHCPv6 server, MUST be a CGA. DHCPv6 server, MUST be a CGA.
In the secure DHCPv6 solution, all the payloads, including DUID-SA, In the server-relay-client scenarios, a DHCPv6 server knows a client
are protected by signature option by the definition of section 5.1 is behind relay(s) if it receives a Relay-forward DHCPv6 message.
and 5.2. Then it will reply a Relay-reply message with the server's source CGA
address being carried in the Server Address Type DUID, which is in
the payload. In this way, the receiver, a DHCPv6 client can get the
server's source CGA address for CGA verification.
All the payloads, including DUID-SA, are protected by signature
option by the definition of section 5.1 and 5.2.
6. Processing Rules and Behaviors 6. Processing Rules and Behaviors
6.1. Processing Rules of Sender 6.1. Processing Rules of Sender
A DHCPv6 node, which could be a server, relay agent or client, can be The sender of a Secure DHCPv6 message could be a DHCPv6 server, a
configured to send Secure DHCPv6 messages only if CGAs have been DHCPv6 relay agent or a DHCPv6 client.
configured on it.
The node MUST record the following configuration information: The node MUST have the following information in order to create
Secure DHCPv6 messages:
CGA parameters Any information required to construct CGAs, as CGA parameters Any information required to construct CGAs, as
described in [RFC3972]. described in [RFC3972].
Keypair A public-private key pair. The public key used Keypair A public-private key pair. The public key used
for constructing the signature MUST be the same for constructing the signature MUST be the same
in CGA parameters. in CGA parameters.
CGA flag A flag that indicates whether CGA is used or CGA flag A flag that indicates whether CGA is used or
not. not.
If a node has been configured to use Secure DHCPv6, the node MUST To support Secure DHCPv6, the Secure DHCPv6 enabled sender MUST
send a DHCPv6 message using a CGA, which be constructed as specified construct the DHCPv6 message following the rules defined in [RFC3315].
in Section 4 of [RFC3972], as the source address unless they are sent The sender MUST use a CGA, which be constructed as specified in
with the unspecified source address. This DHCPv6 message MUST be Section 4 of [RFC3972], as the source address, unless they are sent
signed by the private key of the sender. In the message, both the CGA with the unspecified source address.
option and the Signature option MUST be present. The CGA Parameter
field in the CGA option is filled according to the rules presented
above and in [RFC3972]. The public key in the field is taken from the
configuration used to generate the CGA, typically from a data
structure associated with the source address. The Signature option
MUST be constructed as explained in Section 5.2 and be the last
DHCPv6 option.
In relay scenario, a DHCPv6 server MUST include an OPTION_SERVERID A Secure DHCPv6 message MUST contains both the CGA option and the
[RFC3315] in Relay-reply message and put its CGA in the Server Signature option.
Address field of the DUID in the OPTION_SERVERID. The CGA of DHCPv6
server will not lose during relaying so that the client can verify
CGA address and signature.
6.2. Processing Rules of Receiver The CGA option is constructed according to the rules presented in
Section 5.1 and in [RFC3972]. The public key in the field is the one
associated with the CGA, which is also the source address in the
message header.
The node that supports the verification of the Secure DHCPv6 messages The Signature option MUST be constructed as explained in Section 5.2.
MUST record the following configuration information: It protects all DHCPv6 options (including the CGA option) except for
the Signature option itself and the Authentication Option, the
message header and the message payload
Minbits The minimum acceptable key length for public When constructing a Relay-reply message, a DHCPv6 server MUST include
keys used in the generation of CGAs. The default an OPTION_SERVERID [RFC3315] and put its CGA in the Server Address
SHOULD be 1024 bits. Implementations MAY also field of the DUID in the OPTION_SERVERID. By applying this rule, the
set an upper limit for the amount of computation CGA of the DHCPv6 server will not be lost when the Relay-reply
needed when verifying packets that use these message passes relay agents so that the client can verify CGA address
security associations. Any implementation SHOULD and signature.
follow prudent cryptographic practice in
determining the appropriate key lengths.
On a node that has been configured to use Secure DHCPv6, DHCPv6 6.2. Processing Rules of Receiver
message without either the CGA option or the Signature option MUST be
treated as unsecured. Note the Secure DHCPv6 nodes MAY simply discard By receiving a DHCPv6 message, a Secure DHCPv6 enabled receiver MUST
the unsecured messages. discard the DHCPv6 message if either the CGA option or the Signature
option absents.
The receiving node MUST verify the source CGA address of the DHCPv6 The receiving node MUST verify the source CGA address of the DHCPv6
message by using the public key of the DHCPv6 message sender, CGA message by using the public key of the DHCPv6 message sender, CGA
Parameters and the algorithm described in Section 5 of [RFC3972]. The Parameters and the algorithm described in Section 5 of [RFC3972]. The
inputs to the algorithm are the source address, as used in IP header, inputs to the algorithm are the source address, as used in IP header,
and the CGA Parameters field. and the CGA Parameters field. In the relay scenarios, a DHCPv6 server
obtains the CGA of a client from the peer address field in the Relay-
forward message. A DHCPv6 client obtains the CGA of a server from the
Server Address field of the DUID in the OPTION_SERVERID.
If the CGA verification is successful, the recipient proceeds with a If the CGA verification is successful, the recipient proceeds with a
more time-consuming cryptographic check of the signature. Note that more time-consuming cryptographic check of the signature. Note that
even if the CGA verification succeeds, no claims about the validity even if the CGA verification succeeds, no claims about the validity
of the use can be made until the signature has been checked. of the use can be made until the signature has been checked.
The processing on the receiving node also includes the verification
on signed data by using the public key of the DHCPv6 message sender.
The receiving node MUST verify the Signature option as follows: the The receiving node MUST verify the Signature option as follows: the
Key Hash field MUST indicate the use of a known public key, either Key Hash field MUST indicate the use of a known public key, the one
one learned from a preceding CGA option in the same message, or one learned from a preceding CGA option in the same message. The
known by other means. The signature field verification MUST show that signature field verification MUST show that the signature has been
the signature has been calculated as specified in the previous calculated as specified in Section 5.2.
section.
Only the messages that get through both CGA and signature Only the messages that get through both CGA and signature
verifications are accepted as secured DHCPv6 messages and continue to verifications are accepted as secured DHCPv6 messages and continue to
be handled for their contained DHCPv6 options. be handled for their contained DHCPv6 options as defined in [RFC3315].
Messages that do not pass all the above tests MUST be discarded.
Messages that do not pass all the above tests MUST be silently Furthermore, the node that supports the verification of the Secure
discarded if the host has been configured to accept only secured DHCPv6 messages MAY record the following information:
DHCPv6 messages. The messages MAY be accepted if the host has been
configured to accept both secured and unsecured messages but MUST be
treated as an unsecured message. The receiver MAY also otherwise
silently discard packets.
In the relay scenarios, a DHCPv6 server obtains the CGA of a client Minbits The minimum acceptable key length for public
from the peer address field in the Relay-forward message. A DHCPv6 keys used in the generation of CGAs. An upper
client obtains the CGA of a server from the Server Address field of limit MAY also be set for the amount of
the DUID in the OPTION_SERVERID. computation needed when verifying packets that
use these security associations. The appropriate
lengths SHOULD be set according to the signature
algorithm and also following prudent
cryptographic practice. For example, minimum
length 1024 and upper limit 2048 may be used for
RSA [RSA].
6.3. Processing Rules of Relay Agent 6.3. Processing Rules of Relay Agent
To support secure DHCPv6, Relay Agents follow the same processing To support Secure DHCPv6, Relay Agents MUST follow the same
rules defined in [RFC3315]. processing rules defined in [RFC3315].
By current definition: "The relay agent copies the source address A relay agent MAY verify the CGA and signature as a receiver before
from the IP datagram in which the message was received from the relay the DHCPv6 message further, following verification procedure
client into the peer-address field in the Relay-forward message". The define in Section 6.2. In the case of failure, it MUST discard the
CGA of a client will not lose during relaying. DHCPv6 message.
A relay will not change the OPTION_SERVERID when processing Relay- In the relay scenarios, because relay agent restructures the DHCPv6
reply message from a DHCPv6 server, CGA of the DHCPv6 server will not messages, a downstream receiver would not find the sender's source
lose. CGA address in the DHCPv6 message header.
In the client-relay-server scenarios, "The relay agent copies the
source address from the IP datagram in which the message was received
from the client into the peer-address field in the Relay-forward
message" [RFC3315]. Therefore, the CGA of a client will not be lost
during the relay processing from the client to the server. The
receiver, a DHCPv6 server, can find the sender's source CGA address
in the peer-address field for CGA verification.
During the relay processing from the server to the client, when the
relay agent constructs the Relay-reply message the server's IP
address is replaced by the relay's IP address. In order to make the
CGA of the DHCPv6 server reach the client, DUID-SA, described in
Section 5.3, MUST be used. A relay will not change the
OPTION_SERVERID when processing Relay-reply message from a DHCPv6
server, so that the CGA of the DHCPv6 server will not be lost when
the Relay-reply message passes the Relay Agent.
Relay agents MAY also added its own CGA option and signature option
in the Relay-forward or Relay-reply messages. By receiving such
messages, the downstream receiver MUST verify CGA and signature from
the relay agent, and CGA and signature from the original sender.
7. Security Considerations 7. Security Considerations
This document provides new security features to the DHCPv6 protocol. This document provides new security features to the DHCPv6 protocol.
Using CGA as source addresses of DHCPv6 servers, relays or, also in Using CGA as source addresses of DHCPv6 servers, relays or, also in
DHCPv6 message exchanging provides the source address ownership DHCPv6 message exchanging provides the source address ownership
verification and data integrity protection. verification and data integrity protection.
Without other pre-configured security mechanism, like pre-notified The Secure DHCPv6 mechanism is based on the precondition that the
DHCPv6 server address, using host-based CGA by DHCPv6 servers could receiver has known the CGA of senders. For example, to prevent DHCPv6
not prevent attacks claiming to be a DHCPv6 server. Furthermore, CGAs server spoofing, the clients should be pre-notified the DHCPv6 server
of DHCPv6 servers may be pre-notified to hosts. Then, hosts may CGA. The clients may decline the DHCPv6 messages from other servers,
decline the DHCPv6 messages from other servers, which may be fake which may be fake servers. The pre-notification operation also needs
servers. But in this case the address will be fixed. It may increase to be protected, which is out of scope.
the vulnerability to, e.g., brute force attacks. The pre-notification
operation also needs to be protected, which is out of scope.
DHCPv6 nodes without CGAs or the DHCPv6 messages that use unspecific DHCPv6 nodes without CGAs or the DHCPv6 messages that use unspecific
addresses cannot be protected. addresses cannot be protected.
Downgrade attacks cannot be avoided if nodes are configured to accept Downgrade attacks cannot be avoided if nodes are configured to accept
both secured and unsecured messages. A future specification MAY both secured and unsecured messages. A future specification may
provide a mechanism on how to treat unsecured DHCPv6 messages. One provide a mechanism on how to treat unsecured DHCPv6 messages. One
simple solution MAY be that Secure DHCPv6 is mandated on all servers, simple solution may be that Secure DHCPv6 is mandated on all servers,
reply agents and clients if a certain link has been deployed Secure relay agents and clients on a certain link.
DHCPv6.
As stated in CGA definition [RFC3972], link-local CGAs are more As stated in CGA definition [RFC3972], link-local CGAs are more
vulnerable because the same prefix is used by all IPv6 nodes. vulnerable because the same prefix is used by all IPv6 nodes.
Therefore, when link-local CGAs are used by the DHCPv6 clients, it is Therefore, when link-local CGAs are used by the DHCPv6 clients, it is
recommended to use a slightly higher Sec value. When higher Sec recommended to use a slightly higher Sec value, for example Sec=1 for
values are used, the relative advantage of attacking link-local now. When higher Sec values are used, the relative advantage of
addresses becomes insignificant. attacking link-local addresses becomes insignificant.
Impacts of collision attacks on current uses of CGAs are analyzed in Impacts of collision attacks on current uses of CGAs are analyzed in
[RFC4982]. The basic idea behind collision attacks, as described in [RFC4982]. The basic idea behind collision attacks, as described in
Section 4 of [RFC4270], is on the non-repudiation feature of hash Section 4 of [RFC4270], is on the non-repudiation feature of hash
algorithms. However, CGAs do not provide non-repudiation features. algorithms. However, CGAs do not provide non-repudiation features.
Therefore, as [RFC4982] points out CGA-based protocols, including Therefore, as [RFC4982] points out CGA-based protocols, including
Secure DHCPv6 defined in this document, are not affected by collision Secure DHCPv6 defined in this document, are not affected by collision
attacks on hash functions. attacks on hash functions.
[RFC6273] has analyzed possible threats to the hash algorithms used [RFC6273] has analyzed possible threats to the hash algorithms used
in SEND. Since the Secure DHCPv6 defined in this document uses the in SEND. Since the Secure DHCPv6 defined in this document uses the
same hash algorithms in similar way like SEND (except that Secure same hash algorithms in similar way like SEND (except that Secure
DHCPv6 has not used PKIX Certificate), analysis results could be DHCPv6 has not used PKIX Certificate), analysis results could be
applied as well: current attacks on hash functions do not constitute applied as well: current attacks on hash functions do not constitute
any practical threat to the digital signatures used in the RSA any practical threat to the digital signatures used in the signature
signature in Secure. Attacks on CGAs, as described in [RFC4982], will algorithm in the Secure DHCPv6. Attacks on CGAs, as described in
compromise the security of Secure DHCPv6 and they need to be [RFC4982], will compromise the security of Secure DHCPv6 and they
addressed by encoding the hash algorithm information into the CGA as need to be addressed by encoding the hash algorithm information into
specified in [RFC4982]. the CGA as specified in [RFC4982].
8. IANA Considerations 8. IANA Considerations
This document defines two new DHCPv6 [RFC3315] options, which MUST be This document defines two new DHCPv6 [RFC3315] options, which MUST be
assigned Option Type values within the option numbering space for assigned Option Type values within the option numbering space for
DHCPv6 messages: DHCPv6 messages:
The CGA Parameter Option (TBA1), described in Section 5.1. The CGA Parameter Option (TBA1), described in Section 5.1.
The Signature Option (TBA2), described in Section 5.2. The Signature Option (TBA2), described in Section 5.2.
skipping to change at page 14, line 27 skipping to change at page 14, line 4
[RFC5226]. Assignments for each registry consist of a name, a value [RFC5226]. Assignments for each registry consist of a name, a value
and a RFC number where the registry is defined. and a RFC number where the registry is defined.
Hash Algorithm id (HA-id). The values in this name space are 16-bit Hash Algorithm id (HA-id). The values in this name space are 16-bit
unsigned integers. The following initial values are assigned for HA- unsigned integers. The following initial values are assigned for HA-
id in this document: id in this document:
Name | Value | RFCs Name | Value | RFCs
-------------------+---------+------------ -------------------+---------+------------
SHA-1 | 0x0000 | this document SHA-1 | 0x0000 | this document
Signature Algorithm id (SA-id). The values in this name space are 16- Signature Algorithm id (SA-id). The values in this name space are 16-
bit unsigned integers. The following initial values are assigned for bit unsigned integers. The following initial values are assigned for
SA-id in this document: SA-id in this document:
Name | Value | RFCs Name | Value | RFCs
-------------------+---------+------------ -------------------+---------+------------
SHA-1 | 0x0000 | this document RSASSA-PKCS1-v1_5 | 0x0000 | this document
Hash Algorithm id for Key Hash (HA-id-KH). The values in this name Hash Algorithm id for Key Hash (HA-id-KH). The values in this name
space are 16-bit unsigned integers. The following initial values are space are 16-bit unsigned integers. The following initial values are
assigned for HA-id-KH in this document: assigned for HA-id-KH in this document:
Name | Value | RFCs Name | Value | RFCs
-------------------+---------+------------ -------------------+---------+------------
RSASSA-PKCS1-v1_5 | 0x0000 | this document SHA-1 | 0x0000 | this document
This document defines a new 128-bit value under the CGA Message Type This document defines a new 128-bit value under the CGA Message Type
[RFC3972] namespace, 0x81be a1eb 0021 ce7e caa9 4090 0665 d2e0 02c2. [RFC3972] namespace, 0x81be a1eb 0021 ce7e caa9 4090 0665 d2e0 02c2.
(The tag value has been generated randomly by the editor of this
specification. It may replaced by any IANA-allocated value when the
specification is published.)
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Bernie Volz, Ted Lemon, Ralph Dorms, The authors would like to thank Bernie Volz, Ted Lemon, Ralph Dorms,
Jari Arkko, Sean Turner and other members of the IETF DHC & CSI Jari Arkko, Sean Turner, Stephen Kent and other members of the IETF
working groups for their valuable comments. DHC & CSI working groups for their valuable comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for
IPv6", RFC3315, July 2003. IPv6", RFC3315, July 2003.
[RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972, [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972,
March 2005. March 2005.
skipping to change at page 15, line 41 skipping to change at page 15, line 18
[RFC5226] T. Narten and H. Alvestrand, "Guidelines for Writing an [RFC5226] T. Narten and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, May 2008. IANA Considerations Section in RFCs", RFC 5226, May 2008.
[RFC6273] A. Kukec, S. Krishnan and S. Jiang "The Secure Neighbor [RFC6273] A. Kukec, S. Krishnan and S. Jiang "The Secure Neighbor
Discovery (SEND) Hash Threat Analysis", RFC 6274, June Discovery (SEND) Hash Threat Analysis", RFC 6274, June
2011. 2011.
[NewHash] S.Bellovin and E. Rescorla, "Deploying a New Hash [NewHash] S.Bellovin and E. Rescorla, "Deploying a New Hash
Algorithm", November 2005. Algorithm", November 2005.
[I-D.draft-ietf-dhc-cga-config-dhcpv6]
S. Jiang and S. Xia, "Configuring Cryptographically
Generated Addresses (CGA) using DHCPv6", draft-ietf-dhc-
cga-config-dhcpv6, working in progress, October 2011.
[I-D.draft-ietf-csi-dhcpv6-cga-ps]
S. Jiang, S. Shen and T. Chown, "DHCPv6 and CGA
Interaction: Problem Statement", draft-ietf-csi-dhcpv6-
cga-ps, work in progress, May 2011.
[RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1", [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1",
PKCS 1, November 2002. PKCS 1, November 2002.
[sha-1] National Institute of Standards and Technology, "Secure [sha-1] National Institute of Standards and Technology, "Secure
Hash Standard", FIBS PUB 180-1, April 1995, Hash Standard", FIBS PUB 180-1, April 1995,
http://www.itl.nist.gov/fipspubs/fip180-1.htm. http://www.itl.nist.gov/fipspubs/fip180-1.htm.
Author's Addresses Author's Addresses
Sheng Jiang Sheng Jiang
 End of changes. 73 change blocks. 
258 lines changed or deleted 250 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--Boundary_(ID_7PoVbMYukNNVeFUW0G0ZhA) Content-type: text/plain; name=draft-ietf-dhc-secure-dhcpv6-05.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-ietf-dhc-secure-dhcpv6-05.txt; size=38172; creation-date="Tue, 28 Feb 2012 09:35:58 GMT"; modification-date="Tue, 28 Feb 2012 09:45:17 GMT" Content-description: draft-ietf-dhc-secure-dhcpv6-05.txt DHC Working Group Sheng Jiang Internet Draft Huawei Technologies Co., Ltd Intended status: Standards Track Sean Shen Update: RFC3315 CNNIC Expires: September 15, 2012 March 10, 2012 Secure DHCPv6 Using CGAs draft-ietf-dhc-secure-dhcpv6-05.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 15, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Jiang & Shen Expires September 15, 2012 [Page 1] Internet-Draft draft-ietf-dhc-secure-dhcpv6-05.txt March 2011 Abstract The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly spoofing attack. This document analyzes the security issues of DHCPv6 and specifies a Secure DHCPv6 mechanism based on using CGAs. Table of Contents 1. Introduction ................................................ 3 2. Terminology ................................................. 3 3. Security Overview of DHCPv6 ................................. 3 4. Secure DHCPv6 Overview ...................................... 4 4.1. New Components ......................................... 5 4.2. Support for algorithm agility .......................... 5 5. Extensions for Secure DHCPv6 ................................ 6 5.1. CGA Parameter Option ................................... 6 5.2. Signature Option ....................................... 7 5.3. DUID-SA Type ........................................... 9 6. Processing Rules and Behaviors .............................. 9 6.1. Processing Rules of Sender ............................. 9 6.2. Processing Rules of Receiver .......................... 10 6.3. Processing Rules of Relay Agent ....................... 11 7. Security Considerations .................................... 12 8. IANA Considerations ........................................ 13 9. Acknowledgments ............................................ 14 10. References ................................................ 14 10.1. Normative References ................................. 14 10.2. Informative References ............................... 14 Jiang & Shen Expires September 15, 2012 [Page 2] Internet-Draft draft-ietf-dhc-secure-dhcpv6-05.txt March 2011 1. Introduction The Dynamic Host Configuration Protocol for IPv6 (DHCPv6 [RFC3315]) enables DHCPv6 servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly spoofing attack. This document analyzes the security issues of DHCPv6 in details. This document is aiming to provide mechanisms for improving the security of DHCPv6, thus the address of a DHCPv6 message sender, which can be a DHCPv6 server, a relay agent or a client, is able to be verified by a receiver. It improves communication security of DHCPv6 interaction. The security mechanisms specified in this document is mainly based on the Cryptographically Generated Addresses (CGA [RFC3972]). Secure DHCPv6 is applicable in environments where physical security on the link is not assured (such as over wireless) and attacks on DHCPv6 are a concern. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Security Overview of DHCPv6 DHCPv6 is a client/server protocol that provides managed configuration of devices. It enables DHCPv6 server to auto-configure relevant network parameters on clients through the DHCPv6 message exchanging mechanisms. In the basic DHCPv6 specifications [RFC3315], security of DHCPv6 message can be improved in a few aspects. a) In the basic DHCPv6 specifications, the DHCPv6 server uses a "regular" IPv6 address for itself. It is possible for a malicious attacker to use a fake address to spoof or launch an attack. See Section 23, "Security Considerations" of [RFC3315] for more details. Furthermore, if DHCPv6 servers play the role of updating DNS and other directory services, attackers may spoof DHCPv6 servers to register incorrect information in those services. CGA-based security mechanism can provide source address ownership proofing, which prevents such attacks. b) The basic DHCPv6 specifications achieve message origin authentication and message integrity via an authentication option Jiang & Shen Expires September 15, 2012 [Page 3] Internet-Draft draft-ietf-dhc-secure-dhcpv6-05.txt March 2011 with a symmetric key pair. For the key of the hash function, there are two key management mechanisms. Firstly, the key management is out of band, usually manual, i.e. operators set up key database for both server and client before running DHCPv6. Usually multiple keys are deployed once a time and key id is used to specify which key is used. Manual key distribution runs counter to the goal of minimizing the configuration data needed at each host. Secondly, a DHCPv6 server sends a reconfigure key to the client in the initial exchange of DHCPv6 messages for future use, in this case security is not guaranteed because this key is transmitted in plaintext. Comparing to this, CGA-based security mechanism does not request any key management mechanisms. c) Communication between a server and a relay agent, and communication between relay agents, can be secured through the use of IPsec, as described in section 21.1 in [RFC3315]. However, IPsec is quite complicated. A simpler security mechanism may have better deploy ability. 4. Secure DHCPv6 Overview To solve the abovementioned security issues, we introduce CGAs into DHCPv6. CGAs are introduced in [RFC3972]. "CGAs are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure." This documentation introduces a Secure DHCPv6 mechanism that uses CGAs to secure the DHCPv6 protocol. It assumes the secured DHCPv6 message sender has already haven CGAs and their correspondent CGA parameters; and the receiver has already been given the CGAs of the sender. In this document, a CGA option with an address ownership proof mechanism and a signature option with a corresponding verification mechanism are introduced. A DHCPv6 message (from either a server, a relay agent or a client) with a CGA as source address, can carry the CGA Parameters data structure and a digital signature. The receiver of this DHCPv6 message, who has already known the CGA of the sender, can verify both the CGA and signature, then process the payload of the DHCPv6 message only if the validation is successful. Jiang & Shen Expires September 15, 2012 [Page 4] Internet-Draft draft-ietf-dhc-secure-dhcpv6-05.txt March 2011 can verify both the CGA and signature, then process the payload of the DHCPv6 message only if the validation is successful. With them, the receiver of a DHCPv6 message can verify the sender address of the DHCPv6 message, which improves communication security of DHCPv6 messages. The verification of data integrity and replay protections can also be achieved without the authentication option. The sender can be a DHCPv6 server, a relay agent or a client. So, the end-to-end security protection can be from DHCPv6 servers to relay agents or clients, or from clients to relay agent or DHCPv6 servers. Relay agents MAY add its own Secure DHCPv6 options, too. 4.1. New Components The components of the solution specified in this document are as follows: - CGAs are used to make sure that the sender of a DHCPv6 message is the "owner" of the claimed address. A public-private key pair has been generated by a node itself before it can claim an address. A new DHCPv6 option, the CGA Parameter Option, is used to carry the public key and associated parameters. - Public key signatures protect the integrity of the DHCPv6 messages and authenticate the identity of their sender. - Server Address type of DUID is used to carry server's source address in the relay scenarios. The receiver gets the server's source CGA address for CGA verification. 4.2. Support for algorithm agility Hash functions are the fundamental of security mechanisms, including CGAs in this document. "...they have two security properties: to be one way and collision free." "The recent attacks have demonstrated that one of those security properties is not true." [RFC4270] It is theoretically possible to perform collision attack Attacks against the "collision-free" property. Following the approach recommended by [RFC4270] and [NewHash], recent analysis shows none of these attacks are currently doable [RFC6273]. "The broken security property will not affect the overall security of many specific Internet protocols, the conservative security approach is to change hash algorithms." [RFC4270] However, these attacks indicate the possibility of future real-world attacks. Therefore, we have to take into account that future attacks will be improved and provide a support for multiple hash algorithms. Jiang & Shen Expires September 15, 2012 [Page 5] Internet-Draft draft-ietf-dhc-secure-dhcpv6-05.txt March 2011 Our mechanisms, in this document, support not only hash algorithm agility but also signature algorithm agility. The support for hash agility within CGAs has been defined in [RFC4982]. The usage of CGAs in this document SHOULD also obey [RFC4982], too. The support for algorithm agility in this document is mainly unilateral notification model from a sender to a receiver. If the receiver cannot support the algorithm provided by the sender, it takes the risk itself. Senders in a same network do not have to upgrade to a new algorithm simultaneously. 5. Extensions for Secure DHCPv6 This section extends DHCPv6. Two new options and a new DUID type have been defined. The new options MUST be supported in the Secure DHCPv6 message exchanging. The new DUID type MUST be supported in the relay scenarios. 5.1. CGA Parameter Option The CGA option allows the verification of the sender's CGAs. The format of the CGA option is described as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_CGA_PARAMETER | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . CGA Parameters (variable length) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_CGA_PARAMETER (TBA1). option-len Length of CGA Parameters in octets. CGA Parameters A variable-length field containing the CGA Parameters data structure described in Section 4 of [RFC3972]. This specification requires that the public key found from the CGA Parameters field in the CGA option MUST be that referred by the Key Hash field in the Signature option. Packets received with two different keys MUST be silently discarded. Jiang & Shen Expires September 15, 2012 [Page 6] Internet-Draft draft-ietf-dhc-secure-dhcpv6-05.txt March 2011 5.2. Signature Option The Signature option allows public key-based signatures to be attached to a DHCPv6 message. The Signature option could be any place within the DHCPv6 message. It protects all the DHCPv6 header and options, particularly including the CGA option, except for the Signature option and the Authentication Option. The format of the Signature option is described as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_SIGNATURE | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA-id | SA-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA-id-KH | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp (64-bit) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Key Hash (128-bit) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Signature (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Padding . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_SIGNATURE (TBA2). option-len 32 + Length of Signature field and Padding field in octets. HA-id Hash Algorithm id. The hash algorithm is used for computing the signature result. This design is adopted in order to provide hash algorithm agility. SA-id Signature Algorithm id. The signature algorithm is used for computing the signature result. This design is adopted in order to provide hash algorithm agility. Jiang & Shen Expires September 15, 2012 [Page 7] Internet-Draft draft-ietf-dhc-secure-dhcpv6-05.txt March 2011 HA-id-KH Hash Algorithm id for Key Hash. Hash algorithm used for producing the Key Hash field in the Signature option. This design is adopted in order to provide hash algorithm agility. Reserved A 16-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Timestamp The current time of day (NTP-format timestamp [RFC5905], a 64-bit unsigned fixed-point number, in seconds relative to 0h on 1 January 1900.). It can reduce the danger of replay attacks. Key Hash A 128-bit field containing the most significant (leftmost) 128 bits of the hash value of the public key used for constructing the signature. The hash algorithm is indicated in the HA-id-KH field. The field is taken over the presentation used in the Public Key field of the CGA Parameters data structure carried in the CGA option. Its purpose is to associate the signature to a particular key known by the receiver. Such a key can either be stored in the certificate cache of the receiver or be received in the CGA option in the same message. Signature A variable-length field containing a digital signature. The signature value is computed with the hash algorithm and the signature algorithm, as described in HA-id and SA-id. The signature constructed by using the sender's private key protects the following sequence of octets: 1. The 128-bit CGA Message Type tag value for Secure DHCPv6, 0x81be a1eb 0021 ce7e caa9 4090 0665 d2e0 02c2. 2. The 128-bit Source IPv6 Address. 3. The 128-bit Destination IPv6 Address. 4. The DHCPv6 message header. 5. All DHCPv6 options except for the Signature option and the Authentication Option. 6. The content between the option-len field and the signature field in this Signature option, in the format described above. Jiang & Shen Expires September 15, 2012 [Page 8] Internet-Draft draft-ietf-dhc-secure-dhcpv6-05.txt March 2011 Padding This variable-length field contains padding, as many bytes long as remain after the end of the signature. 5.3. DUID-SA Type Server Address Type DUID (DUID-SA) allows IP address of DHCPv6 servers can be carried in DHCPv6 message payload. The following diagram illustrates the format of a DUID-SA: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBA3 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Server Address (128-bit) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type-code DUID-SA Type (TBA3) Reserved A 16-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Server Address The 128-bit IPv6 address of the DHCPv6 server. The Server Address field of DUID-SA, which is the IPv6 address of the DHCPv6 server, MUST be a CGA. In the server-relay-client scenarios, a DHCPv6 server knows a client is behind relay(s) if it receives a Relay-forward DHCPv6 message. Then it will reply a Relay-reply message with the server's source CGA address being carried in the Server Address Type DUID, which is in the payload. In this way, the receiver, a DHCPv6 client can get the server's source CGA address for CGA verification. All the payloads, including DUID-SA, are protected by signature option by the definition of section 5.1 and 5.2. 6. Processing Rules and Behaviors 6.1. Processing Rules of Sender The sender of a Secure DHCPv6 message could be a DHCPv6 server, a DHCPv6 relay agent or a DHCPv6 client. Jiang & Shen Expires September 15, 2012 [Page 9] Internet-Draft draft-ietf-dhc-secure-dhcpv6-05.txt March 2011 The node MUST have the following information in order to create Secure DHCPv6 messages: CGA parameters Any information required to construct CGAs, as described in [RFC3972]. Keypair A public-private key pair. The public key used for constructing the signature MUST be the same in CGA parameters. CGA flag A flag that indicates whether CGA is used or not. To support Secure DHCPv6, the Secure DHCPv6 enabled sender MUST construct the DHCPv6 message following the rules defined in [RFC3315]. The sender MUST use a CGA, which be constructed as specified in Section 4 of [RFC3972], as the source address, unless they are sent with the unspecified source address. A Secure DHCPv6 message MUST contains both the CGA option and the Signature option. The CGA option is constructed according to the rules presented in Section 5.1 and in [RFC3972]. The public key in the field is the one associated with the CGA, which is also the source address in the message header. The Signature option MUST be constructed as explained in Section 5.2. It protects all DHCPv6 options (including the CGA option) except for the Signature option itself and the Authentication Option, the message header and the message payload When constructing a Relay-reply message, a DHCPv6 server MUST include an OPTION_SERVERID [RFC3315] and put its CGA in the Server Address field of the DUID in the OPTION_SERVERID. By applying this rule, the CGA of the DHCPv6 server will not be lost when the Relay-reply message passes relay agents so that the client can verify CGA address and signature. 6.2. Processing Rules of Receiver By receiving a DHCPv6 message, a Secure DHCPv6 enabled receiver MUST discard the DHCPv6 message if either the CGA option or the Signature option absents. The receiving node MUST verify the source CGA address of the DHCPv6 message by using the public key of the DHCPv6 message sender, CGA Parameters and the algorithm described in Section 5 of [RFC3972]. The inputs to the algorithm are the source address, as used in IP header, and the CGA Parameters field. In the relay scenarios, a DHCPv6 server Jiang & Shen Expires September 15, 2012 [Page 10] Internet-Draft draft-ietf-dhc-secure-dhcpv6-05.txt March 2011 obtains the CGA of a client from the peer address field in the Relay- forward message. A DHCPv6 client obtains the CGA of a server from the Server Address field of the DUID in the OPTION_SERVERID. If the CGA verification is successful, the recipient proceeds with a more time-consuming cryptographic check of the signature. Note that even if the CGA verification succeeds, no claims about the validity of the use can be made until the signature has been checked. The receiving node MUST verify the Signature option as follows: the Key Hash field MUST indicate the use of a known public key, the one learned from a preceding CGA option in the same message. The signature field verification MUST show that the signature has been calculated as specified in Section 5.2. Only the messages that get through both CGA and signature verifications are accepted as secured DHCPv6 messages and continue to be handled for their contained DHCPv6 options as defined in [RFC3315]. Messages that do not pass all the above tests MUST be discarded. Furthermore, the node that supports the verification of the Secure DHCPv6 messages MAY record the following information: Minbits The minimum acceptable key length for public keys used in the generation of CGAs. An upper limit MAY also be set for the amount of computation needed when verifying packets that use these security associations. The appropriate lengths SHOULD be set according to the signature algorithm and also following prudent cryptographic practice. For example, minimum length 1024 and upper limit 2048 may be used for RSA [RSA]. 6.3. Processing Rules of Relay Agent To support Secure DHCPv6, Relay Agents MUST follow the same processing rules defined in [RFC3315]. A relay agent MAY verify the CGA and signature as a receiver before relay the DHCPv6 message further, following verification procedure define in Section 6.2. In the case of failure, it MUST discard the DHCPv6 message. In the relay scenarios, because relay agent restructures the DHCPv6 messages, a downstream receiver would not find the sender's source CGA address in the DHCPv6 message header. In the client-relay-server scenarios, "The relay agent copies the source address from the IP datagram in which the message was received Jiang & Shen Expires September 15, 2012 [Page 11] Internet-Draft draft-ietf-dhc-secure-dhcpv6-05.txt March 2011 from the client into the peer-address field in the Relay-forward message" [RFC3315]. Therefore, the CGA of a client will not be lost during the relay processing from the client to the server. The receiver, a DHCPv6 server, can find the sender's source CGA address in the peer-address field for CGA verification. During the relay processing from the server to the client, when the relay agent constructs the Relay-reply message the server's IP address is replaced by the relay's IP address. In order to make the CGA of the DHCPv6 server reach the client, DUID-SA, described in Section 5.3, MUST be used. A relay will not change the OPTION_SERVERID when processing Relay-reply message from a DHCPv6 server, so that the CGA of the DHCPv6 server will not be lost when the Relay-reply message passes the Relay Agent. Relay agents MAY also added its own CGA option and signature option in the Relay-forward or Relay-reply messages. By receiving such messages, the downstream receiver MUST verify CGA and signature from the relay agent, and CGA and signature from the original sender. 7. Security Considerations This document provides new security features to the DHCPv6 protocol. Using CGA as source addresses of DHCPv6 servers, relays or, also in DHCPv6 message exchanging provides the source address ownership verification and data integrity protection. The Secure DHCPv6 mechanism is based on the precondition that the receiver has known the CGA of senders. For example, to prevent DHCPv6 server spoofing, the clients should be pre-notified the DHCPv6 server CGA. The clients may decline the DHCPv6 messages from other servers, which may be fake servers. The pre-notification operation also needs to be protected, which is out of scope. DHCPv6 nodes without CGAs or the DHCPv6 messages that use unspecific addresses cannot be protected. Downgrade attacks cannot be avoided if nodes are configured to accept both secured and unsecured messages. A future specification may provide a mechanism on how to treat unsecured DHCPv6 messages. One simple solution may be that Secure DHCPv6 is mandated on all servers, relay agents and clients on a certain link. As stated in CGA definition [RFC3972], link-local CGAs are more vulnerable because the same prefix is used by all IPv6 nodes. Therefore, when link-local CGAs are used by the DHCPv6 clients, it is recommended to use a slightly higher Sec value, for example Sec=1 for now. When higher Sec values are used, the relative advantage of attacking link-local addresses becomes insignificant. Jiang & Shen Expires September 15, 2012 [Page 12] Internet-Draft draft-ietf-dhc-secure-dhcpv6-05.txt March 2011 Impacts of collision attacks on current uses of CGAs are analyzed in [RFC4982]. The basic idea behind collision attacks, as described in Section 4 of [RFC4270], is on the non-repudiation feature of hash algorithms. However, CGAs do not provide non-repudiation features. Therefore, as [RFC4982] points out CGA-based protocols, including Secure DHCPv6 defined in this document, are not affected by collision attacks on hash functions. [RFC6273] has analyzed possible threats to the hash algorithms used in SEND. Since the Secure DHCPv6 defined in this document uses the same hash algorithms in similar way like SEND (except that Secure DHCPv6 has not used PKIX Certificate), analysis results could be applied as well: current attacks on hash functions do not constitute any practical threat to the digital signatures used in the signature algorithm in the Secure DHCPv6. Attacks on CGAs, as described in [RFC4982], will compromise the security of Secure DHCPv6 and they need to be addressed by encoding the hash algorithm information into the CGA as specified in [RFC4982]. 8. IANA Considerations This document defines two new DHCPv6 [RFC3315] options, which MUST be assigned Option Type values within the option numbering space for DHCPv6 messages: The CGA Parameter Option (TBA1), described in Section 5.1. The Signature Option (TBA2), described in Section 5.2. This document defines a new DHCPv6 DUID, which MUST be assigned DUID Type values within the DHCPv6 DUID Type numbering space: The DUID-SA (TBA3), described in Section 5.3. This document defines three new registries that have been created and are maintained by IANA. Initial values for these registries are given below. Future assignments are to be made through Standards Action [RFC5226]. Assignments for each registry consist of a name, a value and a RFC number where the registry is defined. Hash Algorithm id (HA-id). The values in this name space are 16-bit unsigned integers. The following initial values are assigned for HA- id in this document: Name | Value | RFCs -------------------+---------+------------ SHA-1 | 0x0000 | this document Jiang & Shen Expires September 15, 2012 [Page 13] Internet-Draft draft-ietf-dhc-secure-dhcpv6-05.txt March 2011 Signature Algorithm id (SA-id). The values in this name space are 16- bit unsigned integers. The following initial values are assigned for SA-id in this document: Name | Value | RFCs -------------------+---------+------------ RSASSA-PKCS1-v1_5 | 0x0000 | this document Hash Algorithm id for Key Hash (HA-id-KH). The values in this name space are 16-bit unsigned integers. The following initial values are assigned for HA-id-KH in this document: Name | Value | RFCs -------------------+---------+------------ SHA-1 | 0x0000 | this document This document defines a new 128-bit value under the CGA Message Type [RFC3972] namespace, 0x81be a1eb 0021 ce7e caa9 4090 0665 d2e0 02c2. (The tag value has been generated randomly by the editor of this specification. It may replaced by any IANA-allocated value when the specification is published.) 9. Acknowledgments The authors would like to thank Bernie Volz, Ted Lemon, Ralph Dorms, Jari Arkko, Sean Turner, Stephen Kent and other members of the IETF DHC & CSI working groups for their valuable comments. 10. References 10.1. Normative References [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for IPv6", RFC3315, July 2003. [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972, March 2005. [RFC4982] M. Bagnulo, J. Arkko, "Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)", RFC4982, July 2007. [RFC5905] D. Mills, J. Martin, Ed., J. Burbank and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. 10.2. Informative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", c, March 1997. Jiang & Shen Expires September 15, 2012 [Page 14] Internet-Draft draft-ietf-dhc-secure-dhcpv6-05.txt March 2011 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005. [RFC5226] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, May 2008. [RFC6273] A. Kukec, S. Krishnan and S. Jiang "The Secure Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6274, June 2011. [NewHash] S.Bellovin and E. Rescorla, "Deploying a New Hash Algorithm", November 2005. [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS 1, November 2002. [sha-1] National Institute of Standards and Technology, "Secure Hash Standard", FIBS PUB 180-1, April 1995, http://www.itl.nist.gov/fipspubs/fip180-1.htm. Author's Addresses Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China EMail: jiangsheng@huawei.com Sean Shen CNNIC 4, South 4th Street, Zhongguancun Beijing 100190 P.R. China EMail: shenshuo@cnnic.cn Jiang & Shen Expires September 15, 2012 [Page 15] --Boundary_(ID_7PoVbMYukNNVeFUW0G0ZhA)-- From carl@redhoundsoftware.com Tue Feb 28 05:00:12 2012 Return-Path: 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 12D5421F85C0 for ; Tue, 28 Feb 2012 05:00:12 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok6Px2A7CvjZ for ; Tue, 28 Feb 2012 05:00:11 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1820F21F8559 for ; Tue, 28 Feb 2012 05:00:10 -0800 (PST) Received: by vbbez10 with SMTP id ez10so2245944vbb.31 for ; Tue, 28 Feb 2012 05:00:10 -0800 (PST) Received-SPF: pass (google.com: domain of carl@redhoundsoftware.com designates 10.52.69.116 as permitted sender) client-ip=10.52.69.116; Authentication-Results: mr.google.com; spf=pass (google.com: domain of carl@redhoundsoftware.com designates 10.52.69.116 as permitted sender) smtp.mail=carl@redhoundsoftware.com Received: from mr.google.com ([10.52.69.116]) by 10.52.69.116 with SMTP id d20mr12855849vdu.58.1330434010574 (num_hops = 1); Tue, 28 Feb 2012 05:00:10 -0800 (PST) Received: by 10.52.69.116 with SMTP id d20mr10624911vdu.58.1330434010534; Tue, 28 Feb 2012 05:00:10 -0800 (PST) Received: from [192.168.1.4] (pool-173-79-172-61.washdc.fios.verizon.net. [173.79.172.61]) by mx.google.com with ESMTPS id ew2sm15916619vdc.16.2012.02.28.05.00.09 (version=SSLv3 cipher=OTHER); Tue, 28 Feb 2012 05:00:10 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 28 Feb 2012 08:00:03 -0500 From: Carl Wallace To: , Message-ID: Thread-Topic: secdir review of draft-ietf-netext-pmip-lr-08 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQmQGo5PC8ZhxGtu97VUwlppx07CMgxGNOzb8pi+a7vhIWOSKlMyaQhiJ0bWatQ7Gx+o40gz Cc: draft-ietf-netext-pmip-lr.all@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-netext-pmip-lr-08 X-BeenThere: secdir@ietf.org 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: Tue, 28 Feb 2012 13:00:12 -0000 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. This document proposes initiation, utilization and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain. The security considerations section introduces (for this document) the requirement for IPSec and the reuse of a security association described in RFC 5213. This text belongs in the body of the document in my opinion, with the security considerations possibly changed to simply reference RFC 4832 and RFC 5213 security considerations. From stephen.farrell@cs.tcd.ie Tue Feb 28 08:37:18 2012 Return-Path: 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 F09D221F86C4 for ; Tue, 28 Feb 2012 08:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usOq4DBT53pp for ; Tue, 28 Feb 2012 08:37:17 -0800 (PST) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 2189421F86C3 for ; Tue, 28 Feb 2012 08:37:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A241A171D1B for ; Tue, 28 Feb 2012 16:37:07 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1330447027; bh=vsGEX2FRWv7rqiD+YysRZOHy 3PQNnm3smelXb5ngoq4=; b=4EDq3rDKrwDwJftXAtU6O2DH0OQj8OWRKYiFtp0w 75/8pfhKjXd5KlEDFn2ZnB5VijlFNhSo1sf33DgEXjYUN7zk+5rOdr4iCEiPt4KI 2nbKHAdbiq7U+Pki3qunbIzP9Ow+Xy1STsZbmosSPp3v6tVI7ahlH9np1tFAkseZ r0j7u/qPrNMUhk3fMQ4MlDOSptE3WqIPABXNkrBTi3wn68PE3NYxUyZT7xYsIYkB vAfjv5kcuUV7Wv3qTTk4Jl+qosDH4UmPngF+SzUvUOYlnQpckYQPumWEf6kbNua+ PcGtSHGKN/DIDCIpeoaJYYNL0UxdRmXHrLZJixNlPqiKQw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id HhlwMgxgdx0z for ; Tue, 28 Feb 2012 16:37:07 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 589A2171C9B for ; Tue, 28 Feb 2012 16:37:06 +0000 (GMT) Message-ID: <4F4D02B3.4090109@cs.tcd.ie> Date: Tue, 28 Feb 2012 16:37:07 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "secdir@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] IEEE internet computing practical security article X-BeenThere: secdir@ietf.org 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: Tue, 28 Feb 2012 16:37:18 -0000 Hi, I've been contributing 3 of these per year for the last while but thanks to the day job and AD stuff don't really have time for it at the moment. If any of you are interested in writing one of these please let me know off-list. Its not peer-reviewed (some ed-board members just ok them) so a magazine style re-spin of an academic publication would be fine or just something that's worth publishing but might not make a conference paper. Its about 3000 words usually and any security topic is fine so long as its aimed at the right audience. You can take a look at old articles [1] to see the kind of thing. Ta, S. [1] http://www.google.com/search?q=ieee+internte+computing+practical+security From tlyu@mit.edu Tue Feb 28 19:58:13 2012 Return-Path: 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 0C12A21F871E; Tue, 28 Feb 2012 19:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.02 X-Spam-Level: X-Spam-Status: No, score=-105.02 tagged_above=-999 required=5 tests=[AWL=-1.421, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCTHPv2KvWgn; Tue, 28 Feb 2012 19:58:12 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4163621F871C; Tue, 28 Feb 2012 19:58:11 -0800 (PST) X-AuditID: 12074425-b7f4a6d0000008e0-96-4f4da252b6da Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 1D.27.02272.252AD4F4; Tue, 28 Feb 2012 22:58:10 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id q1T3w52r016581; Tue, 28 Feb 2012 22:58:10 -0500 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q1T3w1Z1024314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Feb 2012 22:58:02 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id q1T3w1bM001317; Tue, 28 Feb 2012 22:58:01 -0500 (EST) To: iesg@ietf.org, secdir@ietf.org, draft-ietf-adslmib-gbond-atm-mib.all@tools.ietf.org From: Tom Yu Date: Tue, 28 Feb 2012 22:58:01 -0500 Message-ID: Lines: 15 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixG6nohu0yNff4NtBeYtZj1eyWMz4M5HZ 4sPChywOzB5Llvxk8vhy+TNbAFMUl01Kak5mWWqRvl0CV8bNO0eZCg6yVXQeamFuYNzO2sXI ySEhYCLxZNs3FghbTOLCvfVsXYxcHEIC+xgljm3azw6SEBLYwCjxqD0RInGFSeLj+9vsEE4X o8SEaTuB2jk4RAQSJC6vyQJpEBawlTiwewcTSJhNQFri6OIykDCLgKpE/+pusJm8AhYSl06s BbN5BDglmpbsZoaIC0qcnPkE7CBmAS2JG/9eMk1g5JuFJDULSWoBI9MqRtmU3Crd3MTMnOLU ZN3i5MS8vNQiXQu93MwSvdSU0k2M4EBzUd3BOOGQ0iFGAQ5GJR5eaX5ffyHWxLLiytxDjJIc TEqivGbzgEJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeNMNgHK8KYmVValF+TApaQ4WJXFeTa13 fkIC6YklqdmpqQWpRTBZGQ4OJQneEwuBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGrwep4S0uSMwt zkyHyJ9iVJQS510OkhAASWSU5sH1whLBK0ZxoFeEeXeAVPEAkwhc9yugwUxAgwM4vUEGlyQi pKQaGJflcH7ZETI3/D6LdIVtrQZjTIqn4KN/nIouc7gS9YU+7c/ptp/2oMtsj4aMXWnbuv5m U6dX7zIeGVbev2A8fbWba/GWqzIzVurxd0S9bWO7GWS8M8q7h2PHHDtVgyNWabP+CzcdvN9f 9X6JfkOyjUKt/K9dH6U2CC38ur5wr55Digab8MR3SizFGYmGWsxFxYkAZDjKnt8CAAA= Subject: [secdir] secdir review of draft-ietf-adslmib-gbond-atm-mib-05 X-BeenThere: secdir@ietf.org 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: Wed, 29 Feb 2012 03:58:13 -0000 The Security Considerations section cites a number of informative references when describing some mandatory (RFC2119) behavior. I think that these should be normative references. These include RFC3410, RFC3414, RFC3826, RFC5591, RFC5592, and RFC6353. (I believe that draft-ietf-adslmib-gbond-mib-09 has similar issues.) The mention of gBondAtmPortConfTable when illustrating the sensitivity of read-write parameters was initially confusing to me because it is marked as having a MAX-ACCESS of not-accessible. I eventually figured out that was because it is a "conceptual table" in the sense of RFC2578, and that the individual read-write elements are the issue. This might not be a difficulty for someone who is already familiar with SMIv2. I believe the rest of the Security Considerations section is adequate. From d3e3e3@gmail.com Wed Feb 29 07:54:07 2012 Return-Path: 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 876CE21F86FD; Wed, 29 Feb 2012 07:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.352 X-Spam-Level: X-Spam-Status: No, score=-104.352 tagged_above=-999 required=5 tests=[AWL=-0.753, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPi6PU6p1r4v; Wed, 29 Feb 2012 07:54:07 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1EA21F8679; Wed, 29 Feb 2012 07:54:06 -0800 (PST) Received: by lagj5 with SMTP id j5so5596992lag.31 for ; Wed, 29 Feb 2012 07:54:05 -0800 (PST) Received-SPF: pass (google.com: domain of d3e3e3@gmail.com designates 10.152.123.68 as permitted sender) client-ip=10.152.123.68; Authentication-Results: mr.google.com; spf=pass (google.com: domain of d3e3e3@gmail.com designates 10.152.123.68 as permitted sender) smtp.mail=d3e3e3@gmail.com; dkim=pass header.i=d3e3e3@gmail.com Received: from mr.google.com ([10.152.123.68]) by 10.152.123.68 with SMTP id ly4mr823075lab.13.1330530845452 (num_hops = 1); Wed, 29 Feb 2012 07:54:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=2AxhMuu0C7ST91rm6mRp2RoWE7wupKIjqmloI0kguIY=; b=dOYbta+IBxCygtZm//b57mjiPiwIhdoyDJUVMSfelIf5EisIBrk3OWOySMhFYVoKtD +SQu0MTr8H5RDZONWyupI+88u5QDlGFYg3aDz4iXxo4QgegQzdSkpzTgQMrQLdDmz2k0 rvD/6oW7PEseH1nin5yauxiItQKr9Irri2jzc= Received: by 10.152.123.68 with SMTP id ly4mr678252lab.13.1330530845360; Wed, 29 Feb 2012 07:54:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.80.234 with HTTP; Wed, 29 Feb 2012 07:53:45 -0800 (PST) From: Donald Eastlake Date: Wed, 29 Feb 2012 10:53:45 -0500 Message-ID: To: iesg@ietf.org, draft-ietf-manet-packetbb-sec.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: secdir@ietf.org Subject: [secdir] draft-ietf-manet-packetbb-sec-08 SecDir review X-BeenThere: secdir@ietf.org 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: Wed, 29 Feb 2012 15:54:07 -0000 My apologies for getting this review in late. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. Overall, I do not have security concerns with this document. See comments below. This document describes "signature" and "time" building blocks for constructing messages/packets as described in RFC 5444. There is actually noticeable overlap with Section 7.1 of RFC 5444, enough that I am inclined to say that this draft should indicate the it Updates 5444. The Security Considerations Section says "... has the same security considerations as [RFC5444]." In turn, RFC 5444 says "This specification does not describe a protocol; it describes a packet format. As such, it does not specify any security considerations; these are matters for a protocol using this specification." :-) But, in fact, the Security Considerations Section of 5444 continues with design suggestions for authentication/integrity and confidentiality. Arguably, this draft provides a more detailed syntax with some processing rules for authentication/integrity with signatures extending 5444. But it still defers much to any specific MANET protocol making use of RFC 5444, this draft, and probably additional "building block" drafts or RFCs. It appears that the MANET WG is approaching all this through a series of overlapping documents each of which is of limited content but provides more details. For example, this draft sets up hash function and cryptographic function IANA registries but provides only the identity function as initial content for these registries. Presumably additional documents will request allocations from these registries for other functions. There is nothing inherently wrong with this approach and trying to produce large monolithic documents can have problems. But a swarm of smaller inter-related and partly overlapping documents can be confusing. Section 8.1 and 9.1: These sections provide that when adding a packet or message signature TLV, respectively, any pre-existing packet or messages signature "MUST" be removed, etc., before signature calculation bu= t only "SHOULD" be restored afterwards. I would have guessed that "SHOULD" would be a "MUST". In any case, it might be good to say when you don't need to restore a signature TLV, which I would assume would be if that signature TLV is not needed by the recipient. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From tobias.gondrom@gondrom.org Wed Feb 29 11:04:05 2012 Return-Path: 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 0FFF121F86DF for ; Wed, 29 Feb 2012 11:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.777 X-Spam-Level: X-Spam-Status: No, score=-96.777 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeECwHQckfuj for ; Wed, 29 Feb 2012 11:04:04 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id C1DF821F86F2 for ; Wed, 29 Feb 2012 11:04:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=ns4MUAUdEAD42e0uSFvxVjjqfzm9su7MkSXD/cJg+Yro/0/i4oc+8ufrbXJrNH73/jA26h550IPc5QRu+aH1yh04RqrIpssH+C6m8pLi4pnKCGrcSsOblgQQWIfKcp9H; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type; Received: (qmail 11713 invoked from network); 29 Feb 2012 20:03:40 +0100 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.68?) (94.194.102.93) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Feb 2012 20:03:40 +0100 Message-ID: <4F4E768B.7030302@gondrom.org> Date: Wed, 29 Feb 2012 19:03:39 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mext-mip6-tls.all@tools.ietf.org Content-Type: multipart/alternative; boundary="------------090206010604060406010402" Subject: [secdir] Secdir review of draft-ietf-mext-mip6-tls-03 X-BeenThere: secdir@ietf.org 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: Wed, 29 Feb 2012 19:04:05 -0000 This is a multi-part message in MIME format. --------------090206010604060406010402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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. This draft of the MEXT WG is experimental and aims at using Transport Layer Security-based Mobile IPv6 Security Framework for Mobile Node to Home Agent Communication instead of IPSEC. In general this can be feasible and the security considerations section is relatively extensive,however a number of issues come to mind, which can be grouped in four areas: 1. TLS: - risk of TLS downgrading (via renegotiation) - risk of TLS stripping (by a MitM) 2. trust and server certificates - as we saw in websec there are a number of risks with the handling/provisoning of certs through CAs. In this case the server landscape could be much better controlled by the operator, this may be easier here, but still the question remains: - as this uses certs for authentication, do we have to look at compromised certs / how to update trust-anchors in mobile nodes? - do we need to look into cert pinning to sustain trust relationships? 3. Cipher Suites (5.6.5. and following): the listed cipher suites seem limited and potentially not sufficiently secure and agile. - why are you not including AES-256 and SHA-2 (512bit)? - furthermore due to the list of ciphers it seems the spec is lacking algorithm agility, it might be apropriate to use a registry or even better refer to an existing registry for cipher suites? 4. Misc: - and on a personal note maybe a stupid question: why do you MUST set the sequence number to 0 at the start? Does this reduction in the range of expected sequence number values possibly open channels for attack, like increase the risk of an attacker guessing sequence numbers in the stream? In general I feel the draft could use the improvements in the above four areas, but as it is experimental, it may be sufficient. Best regards, Tobias --------------090206010604060406010402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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.


This draft of the MEXT WG is experimental and aims at using Transport Layer Security-based Mobile IPv6 Security Framework for Mobile Node to Home Agent Communication instead of IPSEC.

In general this can be feasible and the security considerations section is relatively extensive, however a number of issues come to mind, which can be grouped in four areas:

1. TLS:
- risk of TLS downgrading (via renegotiation)
- risk of TLS stripping (by a MitM)

2. trust and server certificates
- as we saw in websec there are a number of risks with the handling/provisoning of certs through CAs.
In this case the server landscape could be much better controlled by the operator, this may be easier here, but still the question remains:
- as this uses certs for authentication, do we have to look at compromised certs / how to update trust-anchors in mobile nodes?
- do we need to look into cert pinning to sustain trust relationships?

3. Cipher Suites (5.6.5. and following):
the listed cipher suites seem limited and potentially not sufficiently secure and agile.
- why are you not including AES-256 and SHA-2 (512bit)?
- furthermore due to the list of ciphers it seems the spec is lacking algorithm agility, it might be apropriate to use a registry or even better refer to an existing registry for cipher suites?

4. Misc:
- and on a personal note maybe a stupid question: why do you MUST set the sequence number to 0 at the start?
Does this reduction in the range of expected sequence number values possibly open channels for attack, like increase the risk of an attacker guessing sequence numbers in the stream?

In general I feel the draft could use the improvements in the above four areas, but as it is experimental, it may be sufficient.

Best regards, Tobias



 --------------090206010604060406010402-- From dharkins@lounge.org Wed Feb 29 11:46:06 2012 Return-Path: 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 3DA0F21F87FC; Wed, 29 Feb 2012 11:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.645 X-Spam-Level: X-Spam-Status: No, score=-5.645 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6C+KxqASAri; Wed, 29 Feb 2012 11:46:05 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id BB96521F87D5; Wed, 29 Feb 2012 11:46:05 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 810A81022404A; Wed, 29 Feb 2012 11:46:05 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 29 Feb 2012 11:46:05 -0800 (PST) Message-ID: Date: Wed, 29 Feb 2012 11:46:05 -0800 (PST) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-ietf-pcp-base.all@tools.ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [secdir] secdir review of draft-ietf-pcp-base X-BeenThere: secdir@ietf.org 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: Wed, 29 Feb 2012 19:46:06 -0000 My apologies for the tardiness of this review. The tracker says it's on the agenda for the next telechat so maybe this isn't completely useless. 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. This draft describes a simple request/response protocol to create and manage mappings on upstream devices (like NATs) to control how incoming packets get forwarded. It defines two threat models (a simple one and an advanced one) that seem reasonable for the different use cases. The Security Considerations are well-written and address all attacks I could think of. The draft is very well-written and complete. PCP has a THIRD_PARTY option in which a PCP client can create a mapping on a PCP server for a different device. This has the potential for abuse. The implications of this option are mentioned somewhat in passing in the section that describes the option ("Determining which PCP clients are authorized to use the THIRD_PARTY Option for which other hosts is deployment-dependent....A cryptographic authentication and authorization model is outside the scope of this specification") but it would be nice if they were addressed a bit more in the Security Considerations section. It would be nice to see mention of: a) what capabilities should a PCP server have to properly address authorization of requests that include the THIRD_PARTY option; and, b) what are the implications of enabling the THIRD_PARTY option on a PCP server? In other words, what does a user need to understand before he enables it? I understand that this is a very tardy request, my apologies again, so I understand if this comment is not resolved. regards, Dan. From paul.hoffman@vpnc.org Wed Feb 29 13:00:58 2012 Return-Path: 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 5FD6721E80A1 for ; Wed, 29 Feb 2012 13:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzC8WdJV50HG for ; Wed, 29 Feb 2012 13:00:58 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E496621E80A0 for ; Wed, 29 Feb 2012 13:00:57 -0800 (PST) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1TL0vjS064670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 29 Feb 2012 14:00:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Feb 2012 13:00:56 -0800 Message-Id: <9443352B-A653-4E07-BE90-9F64391F205C@vpnc.org> To: secdir Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [secdir] Secdir review of draft-reschke-http-status-308 X-BeenThere: secdir@ietf.org 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: Wed, 29 Feb 2012 21:00:58 -0000 This is a trivial document that specifies an new HTTP status code for = permanent redirects (HTTP already has status codes for permanent moves, = and temporary redirects). The security consideration section says "All = security considerations that apply to HTTP redirects apply to the 308 = status code as well", and that is sufficient here. --Paul Hoffman From suresh.krishnan@ericsson.com Wed Feb 29 20:18:52 2012 Return-Path: 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 3E22321F854D; Wed, 29 Feb 2012 20:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.202 X-Spam-Level: X-Spam-Status: No, score=-106.202 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kwhm9jpUgf29; Wed, 29 Feb 2012 20:18:51 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id B040221F8547; Wed, 29 Feb 2012 20:18:51 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q214IYvi020611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Feb 2012 22:18:35 -0600 Received: from [164.48.125.51] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 29 Feb 2012 23:18:33 -0500 Message-ID: <4F4EF893.1060201@ericsson.com> Date: Wed, 29 Feb 2012 23:18:27 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Carl Wallace References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "draft-ietf-netext-pmip-lr.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-netext-pmip-lr-08 X-BeenThere: secdir@ietf.org 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: Thu, 01 Mar 2012 04:18:52 -0000 Hi Carl, Thanks for your review. I will add the reference to RFC4832 like you stated. Is there a specific reason why you prefer the security related text be moved to the body of the document instead of the Security Considerations section? Regards Suresh On 02/28/2012 08:00 AM, Carl Wallace wrote: > 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. > > > This document proposes initiation, utilization and termination mechanisms > for localized routing between mobile access gateways within a proxy mobile > IPv6 domain. The security considerations section introduces (for this > document) the requirement for IPSec and the reuse of a security > association described in RFC 5213. This text belongs in the body of the > document in my opinion, with the security considerations possibly changed > to simply reference RFC 4832 and RFC 5213 security considerations. > > >