From vincent.roca@inria.fr Tue Apr 3 02:20:20 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 5E79E21F8691; Tue, 3 Apr 2012 02:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 nnj96vgaqD6P; Tue, 3 Apr 2012 02:20:19 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id F271A21F868C; Tue, 3 Apr 2012 02:20:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,362,1330902000"; d="scan'208";a="152448324" Received: from ral057r.vpn.inria.fr ([128.93.178.57]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 03 Apr 2012 11:20:16 +0200 From: Vincent Roca Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Apr 2012 11:18:29 +0200 Message-Id: <2BAEF3F1-9FDD-4D45-B03D-57A12CAF515F@inria.fr> To: IESG , secdir@ietf.org, draft-johansson-loa-registry.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] Secdir review of draft-johansson-loa-registry-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: Tue, 03 Apr 2012 09:20:20 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I have two comments WRT to section 7:=20 1/ It is said: "An implementor of MUST NOT treat the registry as a trust framework or federation [...]" As I understand the IANA registry is a record of LOA definitions that = are part of a trust framework. So that's a different concept, I agree. But = why is this sentence in the "Security Considerations" section? It could be = moved to section 3 for instance. 2/ The rest of the sentence is confusing IMHO: "An implementor [...] MUST NOT make any assumptions about the = properties of any of the listed level of assurance URIs or their associated trust frameworks or federations based on their presense in the IANA = registry." Do you mean that the fact an IANA registry exists, by itself, does not = garranty the trust framework actually provides the expected security features = (i.e. the IANA registry is merely a definition record)? I don't like the term "any assumption". If a LOA tells me I can achieve = some security level by using it, I'll first **assume** it's true and in a = second step I'll verify it's indeed the case. Typos and general comments: ** section 7: =20 - In the first sentence, something is missing: "An implementor of MUST NOT" Of what? - Later: "...based on their presense in the IANA registry" Don't you mean presence (with a "c")? ** section 3.1: in the example, it is said: "Defines Level 1 of FAF" I didn't understand what FAF stands for. I think you'd better avoid = using an acronym here. ** section 3. There's a missing "." before "This" in: "URI: A URI referencing a Level of Assurance Profile This is the registry key." Regards, Vincent= From leifj@sunet.se Tue Apr 3 03:32: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 A309821F8575; Tue, 3 Apr 2012 03:32:24 -0700 (PDT) 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 lBYPX7Et-EJf; Tue, 3 Apr 2012 03:32:24 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 9C52121F8570; Tue, 3 Apr 2012 03:32:23 -0700 (PDT) Received: from [109.105.104.225] (dhcp90.se-tug.nordu.net [109.105.104.225] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q33AWG8m008508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2012 12:32:19 +0200 (CEST) Message-ID: <4F7AD1AF.3020004@sunet.se> Date: Tue, 03 Apr 2012 12:32:15 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Vincent Roca References: <2BAEF3F1-9FDD-4D45-B03D-57A12CAF515F@inria.fr> In-Reply-To: <2BAEF3F1-9FDD-4D45-B03D-57A12CAF515F@inria.fr> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-johansson-loa-registry.all@tools.ietf.org, IESG , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-johansson-loa-registry-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: Tue, 03 Apr 2012 10:32:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/03/2012 11:18 AM, Vincent Roca wrote: > Hello, > > I have reviewed this document as part of the security > directorate's ongoing effort to review all IETF documents being > processed by the IESG. These comments were written primarily for > the benefit of the security area directors. Document editors and WG > chairs should treat these comments just like any other last call > comments. > > I have two comments WRT to section 7: > > 1/ It is said: "An implementor of MUST NOT treat the registry as a > trust framework or federation [...]" > > As I understand the IANA registry is a record of LOA definitions > that are part of a trust framework. So that's a different concept, > I agree. But why is this sentence in the "Security Considerations" > section? It could be moved to section 3 for instance. I guess it could. > > 2/ The rest of the sentence is confusing IMHO: "An implementor > [...] MUST NOT make any assumptions about the properties of any of > the listed level of assurance URIs or their associated trust > frameworks or federations based on their presense in the IANA > registry." > > Do you mean that the fact an IANA registry exists, by itself, does > not garranty the trust framework actually provides the expected > security features (i.e. the IANA registry is merely a definition > record)? Yes thats the intent! > I don't like the term "any assumption". If a LOA tells me I can > achieve some security level by using it, I'll first **assume** it's > true and in a second step I'll verify it's indeed the case. > What I want to say is that the fact that the entry exists doesn't imply any quality of the underlying trust framework. > > Typos and general comments: > > ** section 7: - In the first sentence, something is missing: "An > implementor of MUST NOT" Of what? > I got this from gen-art too. I'm changing it to ".. of software that consumes the registry" > - Later: "...based on their presense in the IANA registry" Don't > you mean presence (with a "c")? > > yup > ** section 3.1: in the example, it is said: "Defines Level 1 of > FAF" I didn't understand what FAF stands for. I think you'd better > avoid using an acronym here. > It was an attempt at humor - FAF is the Foo Assurance Framework. > ** section 3. There's a missing "." before "This" in: "URI: A URI > referencing a Level of Assurance Profile This is the registry > key." > excellent, thx! > > Regards, > > Vincent Thanks for a great review! Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk960asACgkQ8Jx8FtbMZneMQwCeKEPZXGHTUr5cTuKpLsogOnCh v38AoKrG9h8+AP1raEuyblLHP7s29GLz =vwLH -----END PGP SIGNATURE----- From weiler+secdir@watson.org Tue Apr 3 07:20:38 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 D75DC11E80C6 for ; Tue, 3 Apr 2012 07:20:38 -0700 (PDT) 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 2wTkPfsxV1g7 for ; Tue, 3 Apr 2012 07:20:37 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACD811E80BF for ; Tue, 3 Apr 2012 07:20:37 -0700 (PDT) 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 q33EKami078189 for ; Tue, 3 Apr 2012 10:20:36 -0400 (EDT) (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 q33EKah7078186 for ; Tue, 3 Apr 2012 10:20:36 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 3 Apr 2012 10:20:36 -0400 (EDT) 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]); Tue, 03 Apr 2012 10:20:37 -0400 (EDT) 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: Tue, 03 Apr 2012 14:20:39 -0000 There are some new assignments of docs scheduled for the 12 April telechat. The last assignment message was 16 March, well before the Paris meeting. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Scott Kelly is next in the rotation. For telechat 2012-04-12 Reviewer LC end Draft Rob Austein T 2012-03-30 draft-ietf-ancp-pon-02 Dave Cridland T 2012-03-30 draft-ietf-dnsext-rfc2671bis-edns0-08 Shawn Emery T 2012-04-12 draft-ietf-conex-concepts-uses-04 Tobias Gondrom T 2012-04-11 draft-ietf-dhc-dhcpv6-reconfigure-rebind-09 Charlie Kaufman T 2012-04-11 draft-ietf-tcpm-3517bis-02 Catherine Meadows T 2012-03-22 draft-ietf-avtcore-ecn-for-rtp-07 Alexey Melnikov T 2012-03-22 draft-ietf-behave-nat64-learn-analysis-03 Tim Polk T 2012-02-07 draft-ietf-oauth-v2-bearer-18 Eric Rescorla T 2012-03-20 draft-ietf-savi-dhcp-12 Yaron Sheffer T 2012-03-26 draft-ietf-avtcore-feedback-supression-rtp-16 Ondrej Sury T 2012-03-26 draft-ietf-bmwg-ipflow-meth-09 Sam Weiler TR2012-03-06 draft-george-travel-faq-05 Brian Weis T 2012-04-09 draft-jivsov-openpgp-ecc-11 For telechat 2012-04-26 Reviewer LC end Draft Derek Atkins T 2012-04-16 draft-dbider-sha2-mac-for-ssh-05 Donald Eastlake T 2012-04-13 draft-ietf-appsawg-greylisting-06 Steve Hanna T 2012-04-12 draft-ietf-emu-chbind-14 Russ Mundy T 2012-03-20 draft-ietf-fecframe-raptor-10 Last calls and special requests: Reviewer LC end Draft Richard Barnes 2012-03-30 draft-ietf-dhc-dhcpv6-redundancy-consider-02 Alan DeKok 2012-04-17 draft-claise-export-application-info-in-ipfix-05 Phillip Hallam-Baker 2012-04-18 draft-ietf-ecrit-lost-sync-17 Dan Harkins 2012-04-11 draft-ietf-ipfix-flow-selection-tech-10 Sam Hartman 2012-04-11 draft-ietf-ippm-reporting-metrics-08 Paul Hoffman 2012-04-08 draft-ietf-krb-wg-des-die-die-die-04 Jeffrey Hutzelman 2012-03-21 draft-betts-itu-oam-ach-code-point-03 Jeffrey Hutzelman 2012-04-16 draft-ietf-manet-nhdp-mib-12 Leif Johansson 2012-04-12 draft-ietf-netmod-smi-yang-04 Tim Polk 2012-03-21 draft-ietf-pwe3-redundancy-bit-06 Eric Rescorla 2012-02-08 draft-ietf-sieve-notify-sip-message-08 Vincent Roca 2012-02-06 draft-ietf-simple-chat-14 Joe Salowey 2012-04-18 draft-templin-aero-10 Carl Wallace - draft-ietf-roll-minrank-hysteresis-of-07 Sam Weiler 2012-03-23 draft-sakane-dhc-dhcpv6-kdc-option-14 Klaas Wierenga - draft-ietf-httpbis-p4-conditional-19 Nico Williams - draft-ietf-httpbis-p5-range-19 Tom Yu - draft-ietf-httpbis-p6-cache-19 Glen Zorn - draft-ietf-httpbis-p7-auth-19 From paul.hoffman@vpnc.org Tue Apr 3 07:54:36 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 1E0E721F877E for ; Tue, 3 Apr 2012 07:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 x3ySCmnO92d9 for ; Tue, 3 Apr 2012 07:54:35 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3B021F8764 for ; Tue, 3 Apr 2012 07:54:35 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q33EsP3H008690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Apr 2012 07:54:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Apr 2012 07:54:25 -0700 Message-Id: <163224DA-DA44-4C9C-84D8-6DD4C0856918@vpnc.org> To: secdir Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: draft-ietf-krb-wg-des-die-die-die.all@tools.ietf.org Subject: [secdir] SecDir review of draft-ietf-krb-wg-des-die-die-die 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, 03 Apr 2012 14:54:36 -0000 This is the SecDir review of "Deprecate DES, RC4-HMAC-EXP, and other = weak cryptographic algorithms in Kerberos", better known as = draft-ietf-krb-wg-des-die-die-die. The security considerations for this = document are actually throughout the document, and all seem to be just = fine. --Paul Hoffman From tobias.gondrom@gondrom.org Tue Apr 3 10:50:21 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 7CC0811E8085 for ; Tue, 3 Apr 2012 10:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.158 X-Spam-Level: X-Spam-Status: No, score=-96.158 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, RCVD_IN_SORBS_WEB=0.619, 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 JJPgKorE3q9m for ; Tue, 3 Apr 2012 10:50:20 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id F010011E8075 for ; Tue, 3 Apr 2012 10:50:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=aCoRBHJo/VPAVfbFasZnH9YGWqDfyzuZRRLFLsSfHkGClhDJi5BMacuPP3UtmYxYJ6APqjqQrkudO654XtdSBr2JIfns9bEiKayovJsP/1WmRgAAVCvJAFIchCUFxIkW; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type; Received: (qmail 24176 invoked from network); 3 Apr 2012 19:50:17 +0200 Received: from 94-175-239-226.static.virginmedia.net (HELO ?10.6.0.85?) (94.175.239.226) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 3 Apr 2012 19:50:17 +0200 Message-ID: <4F7B3859.4020902@gondrom.org> Date: Tue, 03 Apr 2012 18:50:17 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="------------090904000802070508090902" Cc: draft-ietf-dhc-dhcpv6-reconfigure-rebind.all@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-dhc-dhcpv6-reconfigure-rebind-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: Tue, 03 Apr 2012 17:50:21 -0000 This is a multi-part message in MIME format. --------------090904000802070508090902 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. The I-D updates RFC 3315 to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message; and clarifies how a DHCPv6 client responds to a received Reconfigure message. The existing Security Considerations section is a bit soft/vague. It speaks correctly of the possible risk of an attacker induced disconnect and relink. And it states these attacks may be prevented by using the AUTH option or Secure DHCPv6. However it is vague in the overall system risks / preconditions under which the risks arise and should also be more clear about when these mitigation strategies should/SHOULD be used (instead of "may"). Best regards, Tobias --------------090904000802070508090902 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.

The I-D updates RFC 3315 to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message; and clarifies how a DHCPv6 client responds to a received Reconfigure message.
 
The existing Security Considerations section is a bit soft/vague.
It speaks correctly of the possible risk of an attacker induced disconnect and relink. And it states these attacks may be prevented by using the AUTH option or Secure DHCPv6.
However it is vague in the overall system risks / preconditions under which the risks arise and should also be more clear about when these mitigation strategies should/SHOULD be used (instead of "may").

Best regards, Tobias

 --------------090904000802070508090902-- From hartmans@mit.edu Tue Apr 3 13:08:21 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 A67CD11E81B3; Tue, 3 Apr 2012 13:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[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 zvZ3bXgZ0NTW; Tue, 3 Apr 2012 13:08:21 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 39EC611E81AF; Tue, 3 Apr 2012 13:08:21 -0700 (PDT) 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 030C820127; Tue, 3 Apr 2012 16:07:29 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4C6244766; Tue, 3 Apr 2012 16:08:12 -0400 (EDT) From: Sam Hartman To: iesg@ietf.org,secdir@ietf.org Date: Tue, 03 Apr 2012 16:08:12 -0400 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-ietf-ippm-reporting-metrics 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, 03 Apr 2012 20:08:21 -0000 This memo gives advice on how to report information about the network to those either trying to characterize the network or to understand impacts on application performance. While the security considerations of the individual metrics apply, I agree with the authors' belief that this memo does not introduce any significant new considerations. The memo is well written but outside my area of expertise. From vincent.roca@inria.fr Wed Apr 4 06:53:37 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 DE41821F84FE; Wed, 4 Apr 2012 06:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.18 X-Spam-Level: X-Spam-Status: No, score=-109.18 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HELO_EQ_FR=0.35, 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 JKCPjnfTi9IC; Wed, 4 Apr 2012 06:53:37 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 8288621F84C4; Wed, 4 Apr 2012 06:53:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,369,1330902000"; d="scan'208";a="152697866" Received: from unknown (HELO [192.168.43.137]) ([90.84.144.75]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 04 Apr 2012 15:53:28 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Vincent Roca In-Reply-To: <4F7AD1AF.3020004@sunet.se> Date: Wed, 4 Apr 2012 08:21:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <226B9393-7AFF-4082-BCC7-5433DD0D99FE@inria.fr> References: <2BAEF3F1-9FDD-4D45-B03D-57A12CAF515F@inria.fr> <4F7AD1AF.3020004@sunet.se> To: Leif Johansson X-Mailer: Apple Mail (2.1084) Cc: draft-johansson-loa-registry.all@tools.ietf.org, IESG , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-johansson-loa-registry-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: Wed, 04 Apr 2012 13:53:38 -0000 Hi Leif, >> 2/ The rest of the sentence is confusing IMHO: "An implementor >> [...] MUST NOT make any assumptions about the properties of any of >> the listed level of assurance URIs or their associated trust=20 >> frameworks or federations based on their presense in the IANA >> registry." >>=20 >> Do you mean that the fact an IANA registry exists, by itself, does >> not garranty the trust framework actually provides the expected >> security features (i.e. the IANA registry is merely a definition >> record)? >=20 > Yes thats the intent! >=20 >> I don't like the term "any assumption". If a LOA tells me I can >> achieve some security level by using it, I'll first **assume** it's >> true and in a second step I'll verify it's indeed the case. >>=20 >=20 > What I want to say is that the fact that the entry exists doesn't > imply any quality of the underlying trust framework. So it's just a matter of presentation. I prefer your sentence ("does not = imply any quality...") to what is said in the I-D ("must not make any = assumptions..."). > Thanks for a great review! You're welcome. Cheers, Vincent From vincent.roca@inria.fr Wed Apr 4 06:53:40 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 78EB221F8470; Wed, 4 Apr 2012 06:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.715 X-Spam-Level: X-Spam-Status: No, score=-109.715 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 bOH-C4ztgp3C; Wed, 4 Apr 2012 06:53:40 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 6D78421F8796; Wed, 4 Apr 2012 06:53:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,369,1330902000"; d="scan'208";a="152697882" Received: from unknown (HELO [192.168.43.137]) ([90.84.144.75]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 04 Apr 2012 15:53:30 +0200 From: Vincent Roca Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 4 Apr 2012 15:50:10 +0200 Message-Id: <51DE5E2E-1D51-4025-B55C-4B09EFA62468@inria.fr> To: IESG IESG , secdir@ietf.org, draft-ietf-simple-chat.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] Secdir review of draft-ietf-simple-chat-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, 04 Apr 2012 13:53:40 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. General: The authors, in section 11, discuss several simple security issues. However I have the feeling that there aren't enough details on how to avoid/mitigate them. Additionally, I'm not sure the section provides a comprehensive analysis of security aspects. What about intelligent, more elaborate attacks? Details for section 11 "Security considerations" --------------------------------------------------------------- ** The second paragraph explains several situations where a message can be sent to several recipients without the sender knowing. It's a good point to identify this problem, but I'd like to know how it can be avoided (if possible). ** It is said: "It's up to the policy of the MSRP switch if the messages are forwarded to the other participant's in the chat room using TLS [RFC5246] transport." I'm surprised to see that a participant has no way to enforce a secure end-to-end connection. At a minimum, can the participant know the situation in order to take a decision? ** It is said: "To avoid takeovers the MSRP switch MUST make sure that a nickname is unique inside a chat room." Do you mean the protocol does not guaranty by design that a nickname is unique at some point of time in a chat room? If this is the case it's clearly a flaw that should be addressed within the protocol description, not in the security considerations section. Another remark: it's not sufficient to guaranty the uniqueness of the nickname. Phishing attacks show us that two close URLs can mislead a user, even if the URLs differ by at least one character. It would be wiser to recommend that nicknames be significantly different (the MSRP can probably check the distance between a proposed nickname and those already registered in the chat session). ** last sentence: The following sentence is a bit strange and unclear: "If a nickname can be reserved if it previously has been used by another participant in the chat room, is up to the policy of the chat room." I suggest: NEW: It is up to the policy of the chat room to determine if a nickname that has been previously used by another participant of the chat room can be reserved or not. ** General: Several threats are missing in this document. In particular, what about attacks where some traffic is intercepted and modified on-the-fly by the attacker? What about faked messages sent by an attacker to the MSRP? Can a participant use some integrity service? This is not discussed. I'd like to see guidelines on how a participant or MSRP administrator can define a secure mode of operation. If not possible, I'd like to see a detailed discussion of existing risks. Cheers, Vincent From new-work-bounces@ietf.org Thu Apr 5 06:19:22 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 DD22C21F8805; Thu, 5 Apr 2012 06:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333631962; bh=BhFcYNQcPdT/dSTPPMm9p8UpiiOn9KtSXUxpzXucZOU=; 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=YaDguWspdJdFBxBCVXZMMz/ojKcDKHhOQZscmUi29ooB21ywanbM3LB5s9PRSlmcd oHLtFPGEQhMnR13dYFoVTiKHvnka/ixdVWDMQ5CmDCy9zRUnFHjlgEiqtZVCBv8zz6 X69h9Hl5pilZxiGWmsil8wpbbNjx8kKR6Lhrygj8= 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 1CF3A21F8805 for ; Thu, 5 Apr 2012 06:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.185 X-Spam-Level: X-Spam-Status: No, score=-8.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 lJ0dNkrlvEzL for ; Thu, 5 Apr 2012 06:19:21 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD5421F8759 for ; Thu, 5 Apr 2012 06:19:21 -0700 (PDT) Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1SFmau-0006pM-HS; Thu, 05 Apr 2012 09:19:20 -0400 From: Ian Jacobs Date: Thu, 5 Apr 2012 08:19:19 -0500 To: new-work@ietf.org Message-Id: <56BC78AD-A00A-4BB6-B903-D7FB5930ED52@w3.org> 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: Thu, 05 Apr 2012 06:26:52 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Linked Data Platform Working Group (until 2012-05-07) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 13:19:23 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Semantic Web [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Linked Data Platform Working Group: http://www.w3.org/2012/ldp/charter 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-05-07 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 Ivan Herman, Semantic Web Activity Lead . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2001/sw/ [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 stbryant@cisco.com Thu Apr 5 10:03:35 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 B1A6B21F8775; Thu, 5 Apr 2012 10:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.479 X-Spam-Level: X-Spam-Status: No, score=-110.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 rTNtwB8SW4VQ; Thu, 5 Apr 2012 10:03:35 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BD87721F8767; Thu, 5 Apr 2012 10:03:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2567; q=dns/txt; s=iport; t=1333645415; x=1334855015; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=nh3VLII6ax8/QTKFtpL5/VSr+/L/qpOrvOt2Lkrmf3Q=; b=iC6R4W3VVxKGgoJpphzNWUWxHbmq+j02YPSedViarUF0hJa/Ddb3/XJb BQOAxcCTdVA5cuztbipPC0dKUBFLB+gnvf1ynxwQvUoqZAymYOrEK6I8V gtIuW3y0rU1clrZ1gxfI0jb6nvSal3Z9a56Cm6lRI/sJpGQ7qhL+Okhpe 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAL/PfU+Q/khM/2dsb2JhbABFuG+BB4IJAQEBBBIBAhILAQVAARALGAkWDwkDAgECAUUGDQEHAQEeh2wLmwSDPBCcI5BaBJVrjkuBAmeCaA X-IronPort-AV: E=Sophos;i="4.75,377,1330905600"; d="scan'208";a="70236693" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 05 Apr 2012 17:03:33 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q35H3XK9008509; Thu, 5 Apr 2012 17:03:33 GMT Received: from dhcp-bdlk10-data-vlan300-64-103-107-147.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q35H3XXq028868; Thu, 5 Apr 2012 18:03:33 +0100 (BST) Message-ID: <4F7DD065.3030105@cisco.com> Date: Thu, 05 Apr 2012 18:03:33 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Radia Perlman References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-pwe3-redundancy.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-pwe3-redundancy-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 17:03:35 -0000 Authors Please can you answer or address these comments Thanks Stewart On 19/03/2012 22:22, Radia Perlman 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 is a requirements document (intended as informational) for a > routing protocol. > > > > At this level of abstraction, I don’t think there are any interesting > security issues. There are some messages in the protocol that need to > be communicated securely, and the security considerations section > references some other RFCs and says the new messages will “inherit at > least the same security properties” as the messages in those other > RFCs. I didn’t look up what kind of protection existed there. > > > > The interesting routing protocol issue has to do with nesting of > routing algorithms and the needed multipliers in timeouts. It would > appear that pseudo-wires run over a conventional routed infrastructure > and also connect parts of a conventional routed infrastructure. The > spec assumes that failures within the inner routed infrastructure will > heal themselves quickly enough to not be noticed by the pwe3 > redundancy protocol (if they are capable of healing at all), and that > pseudo-wire failover (triggered by this inner failure) will happen > quickly enough to not disrupt the routing protocol that is running > over the pseudo-wires. > > > > But that requirement is not explicitly acknowledged in the document, > and it intuitively seems like a significant challenge. > > > > Micro-level issues: > > > > In terminology (section 2), the Primary PW is defined as the one that > will be used when any one will do, and that if it goes down and comes > back the PW will revert to it. But it also defines non-revertive > protection switching as an option where the traffic will not switch > back to the primary unless the secondary fails, and in section 4.1 it > says that non-revertive protection MUST be supported and revertive is > optional. > > > > Typos: > > > > Section 4.1: > > besupported -> be supported > > suported -> supported > > > > Section 4.2: > > Orphaned bullet > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From acmorton@att.com Fri Apr 6 08:54:15 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 EDF6C21F85C2; Fri, 6 Apr 2012 08:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.196 X-Spam-Level: X-Spam-Status: No, score=-104.196 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, 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 v45Mt3t9uu6I; Fri, 6 Apr 2012 08:54:10 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id E675A21F85A1; Fri, 6 Apr 2012 08:54:09 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 1a11f7f4.0.586322.00-324.1623159.nbfkord-smmo03.seg.att.com (envelope-from ); Fri, 06 Apr 2012 15:54:10 +0000 (UTC) X-MXL-Hash: 4f7f11a26a92ad75-585a877889d8f4699ce311f12150af9cf856e916 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q36Fs6kT029708; Fri, 6 Apr 2012 11:54:09 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q36Frx6a029576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2012 11:54:01 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor); Fri, 6 Apr 2012 11:53:18 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q36FrInc008191; Fri, 6 Apr 2012 11:53:18 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q36FrBRV007699; Fri, 6 Apr 2012 11:53:12 -0400 Message-Id: <201204061553.q36FrBRV007699@alpd052.aldc.att.com> Received: from acmt.att.com (dn135-16-251-71.dhcpn.ugn.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20120406155014gw1004or2ee>; Fri, 6 Apr 2012 15:50:16 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 06 Apr 2012 11:54:19 -0400 To: "Adrian Farrel" , Samuel Weiler , The IESG From: Al Morton In-Reply-To: <20120406144445.4188.3196.idtracker@ietfa.amsl.com> References: <20120406144445.4188.3196.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_16846153==_" X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=dit6Jc5sqrAA:10 a=PLurumnWQikA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=EMLI_BE5mvm9JbZNRLYA:9 a=oeBJXHtBx7puNK96VC] X-AnalysisOut: [wA:7 a=CjuIK1q_8ugA:10 a=mYAOWqAtFUkA:10 a=zQP7CpKOAAAA:8 ] X-AnalysisOut: [a=KI9qLmWpAAAA:20 a=bN6E18yrVWTlGgkc5MIA:9 a=cMiAqtFLv3t6Y] X-AnalysisOut: [XRXfw8A:7 a=JlbW2Bu-4FEA:10 a=uOmZzfvve58A:10 a=ISSXQUU-yz] X-AnalysisOut: [IA:10 a=Hz7IrDYlS0cA:10 a=gBHw4jxdwhUfQ-f6:21 a=mByhXr5mLi] X-AnalysisOut: [flxYEd:21 a=bmb9Z_KCjwIdY-NzA44A:9 a=osKTAfFAxhsyI6CC-WoA:] X-AnalysisOut: [7 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=vgu2m8Mm752vdwO0:2] X-AnalysisOut: [1 a=Q5K-Iz6U6mBRZnxG:21] Cc: "secdir@ietf.org" , "Murphy, Sandra" , Dan Frost , ippm-chairs@tools.ietf.org, draft-ietf-ippm-rt-loss@tools.ietf.org Subject: Re: [secdir] Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT) 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, 06 Apr 2012 15:54:16 -0000 --=====================_16846153==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Adrian and Sam, This preliminary revision of the -rt-loss-draft addresses DISCUSSes, Comments, Rtg-area and sec-dir reviews. The diff to 03 and 04 prelim are attached. Also, see replies below (to both Adrian's and Sandy's messages). regards, Al At 10:44 AM 4/6/2012, Adrian Farrel wrote: >Adrian Farrel has entered the following ballot position for >draft-ietf-ippm-rt-loss-03: Discuss > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > > >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >The Routing Diretorate review by Dan Frost missed the IETF Last Call >period by two days, but I would like the following points from his >review to be considered as part of this Discuss. Other smaller issues >are recorded as Comments. > > > General observation: It's not clear to me what the IPPM WG strategy > > is for security considerations sections in metric definition > > documents. For example, the security section of this document more or > > less repeats the one in (for example) RFC 2681, which itself > > duplicates verbatim the one in RFC 2680, and the issues discussed are > > general ones with measurement protocols rather than specific ones with > > the metric that is the subject of the document. There's probably a > > better way to organize this. Although IPPM has never formalized a strategy, we have been repeating security material in metrics RFCs. This allows new folks to read and improve the text, rather than be referred to a fixed reference. It seems to work. > > 3. Section 9.3 mentions the use of cryptographic hashing "to > > discourage the kind of interference mentioned above"; while this > > would mitigate the second form of interference, it wouldn't help > > with the first. > >I would add that "discourage" might not be an appropriate word. New paragraph addresses Sandy and Dan's points. >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >Other comments coming from Dan Frost's review > > > 1. Although it's probably obvious to most readers, it would be helpful > > to provide a brief informal definition of "round-trip loss" early in > > the introduction. A mention of the venerable "ping" procedure would > > also not be amiss. Did both. > > 2. Most of the text seems to assume an "active" or test-based > > measurement approach, but Section 9.2 refers to passive measurement. > > It would be helpful to discuss the applicability of the latter > > approach. Clarified the scope for passive. > > Nits: > > > > 1. The phrase "as immediately as possible" that appears a couple of > > times in the text (and that seems to originate in RFC 5357) is a bit > > unfortunate. "Immediately" or "as quickly as possible" are better. This odd turn of phrase resulted from many hours of discussion dating back to TWAMP's development. We wear the scar proudly. > > > > 2. Section 5.4, second paragraph: s/affects/effects/ > > > > 3. Section 8, second paragraph: s/Two key features ... is described/ > > Two key features ... are described/ > > > > 4. Section 9.3, first paragraph: > > OLD > > it is possible to change the processing of the packets (e.g. > > increasing or decreasing delay) that may distort the measured > > performance. > > NEW > > it is possible to change the processing of the packets (e.g. > > increasing or decreasing delay) in a way that may distort the > > measured performance. > > END thanks for pointing out the above. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- At 01:23 PM 3/15/2012, Murphy, Sandra 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 draft-ietf-ippm-rt-loss-03 draft defines a round trip loss >metric. A round trip loss measurement capability is specified in >RFC5357 ("Two-Way Active Measurement Protocol (TWAMP)"), but no >metric has been defined in the defined RFC2330 framework. > >As this draft defines a new metric, not the means to implement >measurements with the metric, I do not see that security >considerations apply. But I see no problem with discussion of the >considerations that should guide implementations. > >(Indeed, RFC2861 which defines a delay metric says much the same: > Conducting Internet measurements raises both security and privacy > concerns. This memo does not specify an implementation of the > metrics, so it does not directly affect the security of the Internet > nor of applications which run on the Internet. However, > implementations of these metrics must be mindful of security and > privacy concerns.) > >I have a few comments about the security considerations section. > >The section mentions both active and passive use of the metric. But >the abstract and intro imply this metric is for use in TWAMP, which >is active. Is use of the metric possible in passive measurements as well? Yes, but it is beyond the scope for adding the many additional considerations needed when using a passive scenario. However, we leave the door open to do this work in the future. >In section 9.3, it says: > > It may be possible to identify that a certain packet or stream of > packets is part of a sample. With that knowledge at the destination > and/or the intervening networks, it is possible to change the > processing of the packets (e.g. increasing or decreasing delay) that > may distort the measured performance. It may also be possible to > generate additional packets that appear to be part of the sample > metric. These additional packets are likely to perturb the results > of the sample measurement. > > To discourage the kind of interference mentioned above, packet > interference checks, such as cryptographic hash, may be used. > >How would a simple crypto hash prevent either the distortion of >performance (delaying a packet will not change its hash) or the >injection of additional packets (a cryptographic hash can be >computed for the injected packets as well). > >RFC2861 mentions similar injection concerns and recommends: > > Authentication techniques, such as digital signatures, may > be used where appropriate to guard against injected traffic attacks. > > >Is there reason to suggest authentication in this metric definition as well? Yes, as you point out: > TWAMP provides (but does not mandate) both authentication and > encryption. If TWAMP is the only use of the metric, those features > should be mentioned. If TWAMP is just one important use of the > metric, it could be good to mention the features here. The new paragraph mentions TWAMP as well, but it is only one of many protocols that can/will make this measurement. >--Sandy --=====================_16846153==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-ippm-rt-loss-04prelim.txt" Network Working Group A. Morton Internet-Draft AT&T Labs Intended status: Standards Track April 6, 2012 Expires: October 8, 2012 Round-trip Loss Metrics draft-ietf-ippm-rt-loss-04prelim Abstract Many user applications (and the transport protocols that make them possible) require two-way communications. To assess this capability, and to achieve test system simplicity, round-trip loss measurements are frequently conducted in practice. The Two-Way Active Measurement Protocol specified in RFC 5357 establishes a round-trip loss measurement capability for the Internet. However, there is currently no metric specified according to the RFC 2330 framework. This memo adds round-trip loss to the set of IP Performance Metrics (IPPM). Requirements Language 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 RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on October 8, 2012. Copyright Notice Morton Expires October 8, 2012 [Page 1] Internet-Draft Round-trip Loss April 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Common Specifications for Round-trip Metrics . . . . . . . . . 4 3.1. Name: Type-P-* . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 5 3.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 5 3.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 5 4. A Singleton Round-trip Loss Metric . . . . . . . . . . . . . . 6 4.1. Name: Type-P-Round-trip-Loss . . . . . . . . . . . . . . . 6 4.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 6 4.3. Definition and Metric Units . . . . . . . . . . . . . . . 6 4.4. Discussion and other details . . . . . . . . . . . . . . . 7 5. A Sample Round-trip Loss Metric . . . . . . . . . . . . . . . 7 5.1. Name: Type-P-Round-trip-Loss--Stream . . . . . . . 7 5.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 8 5.3. Definition and Metric Units . . . . . . . . . . . . . . . 8 5.4. Discussion and other details . . . . . . . . . . . . . . . 8 6. Round-trip Loss Statistic . . . . . . . . . . . . . . . . . . 9 6.1. Type-P-Round-trip-Loss--Ratio . . . . . . . . . . 9 7. Round-trip Testing and One-way Reporting . . . . . . . . . . . 9 8. Measurement Considerations and Calibration . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 10 9.2. User Data Confidentiality . . . . . . . . . . . . . . . . 11 9.3. Interference with the metrics . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Morton Expires October 8, 2012 [Page 2] Internet-Draft Round-trip Loss April 2012 1. Introduction This memo defines a metric to quantify an IP network's ability to transfer packets in both directions from one host to another host. Two-way communication is almost always needed, thus failure to transfer a packet in either direction constitutes a round-trip loss. This memo defines a metric for round-trip loss on Internet paths. It builds on the notions and conventions introduced in the IP Performance Metrics (IPPM) framework [RFC2330]. Also, the specifications of the One-way Loss metric [RFC2680] and the Round- trip Delay metric [RFC2681] are frequently referenced and modified to match the round-trip circumstances addressed here. However, this memo assumes that the reader is familiar with the references, and does not repeat material as was done in [RFC2681]. This memo uses the terms "two-way" and "round-trip" synonymously. 1.1. Motivation Many user applications and the transport protocols that make them possible require two-way communications. For example, the TCP SYN->, <-SYN-ACK, ACK-> three-way handshake attempted billions of times each day cannot be completed without two-way connectivity in a near- simultaneous time interval. Thus, measurements of Internet round- trip loss performance provide a basis to infer application performance more easily. Measurement system designers have also recognized advantages of system simplicity when one host simply echoes or reflects test packets to the sender. Round-trip loss measurements are frequently conducted and reported in practice. The ubiquitous "ping" tools allow the measurement of round-trip loss and delay, but usually require ICMP Echo-Request/Reply support, and ICMP packets may encounter exceptional treatment on the measurement path (see Section 2.6 of [RFC2681]). The Two-Way Active Measurement Protocol (TWAMP) specified in [RFC5357] establishes a round-trip loss measurement capability for the Internet. However, there is currently no round- trip loss metric specified according to the [RFC2330] framework. [RFC2681] indicates that round-trip measurements may sometimes encounter "asymmetric" paths. When loss is observed using a round- trip measurement, there is often a desire to ascertain which of the two directional paths "lost" the packet. Under some circumstances, it is possible to make this inference. The round-trip measurement method raises a few complications when interpreting the embedded one- way results, and the user should be aware of them. Morton Expires October 8, 2012 [Page 3] Internet-Draft Round-trip Loss April 2012 [RFC2681] also points out that loss measurement conducted sequentially in both directions of a path and reported as a round- trip result may be exactly the desired metric. On the other hand, it may be difficult to derive the state of round-trip loss from one-way measurements conducted in each direction unless a method to match the appropriate one-way measurements has been pre-arranged. Finally, many measurement systems report statistics on a conditional delay distribution, where the condition is packet arrival at the destination. This condition is encouraged in [RFC3393], [RFC5481], and [draft-ietf-ippm-reporting-metrics]. As a result, lost packets need to be reported separately, according to a standardized metric. This memo defines such a metric. See Section 1.1 of[RFC2680] for additional motivation of the packet loss metric. 2. Scope This memo defines a round-trip loss metric using the conventions of the IPPM framework [RFC2330]. The memo defines a singleton metric, a sample metric, and a statistic, as per [RFC2330]. The [RFC2330] framework is for active measurement methods. Although this metric MAY be applicable in passive measurement as well, discussion of additional considerations for the passive scenario are beyond the normative scope of this memo. The memo also investigates the topic of one-way loss inference from a two-way measurement, and lists some key considerations. 3. Common Specifications for Round-trip Metrics To reduce the redundant information presented in the detailed metrics sections that follow, this section presents the specifications that are common to two or more metrics. The section is organized using the same subsections as the individual metrics, to simplify comparisons. 3.1. Name: Type-P-* All metrics use the Type-P convention as described in [RFC2330]. The rest of the name is unique to each metric. Morton Expires October 8, 2012 [Page 4] Internet-Draft Round-trip Loss April 2012 3.2. Metric Parameters o Src, the IP address of a host o Dst, the IP address of a host o T, a time (start of test interval) o Tf, a time (end of test interval) o lambda, a rate in reciprocal seconds (for Poisson Streams) o incT, the nominal duration of inter-packet interval, first bit to first bit (for Periodic Streams) o T0, a time that MUST be selected at random from the interval [T, T+dT] to start generating packets and taking measurements (for Periodic Streams) o TstampSrc, the wire time of the packet as measured at MP(Src) as it leaves for Dst. o TstampDst, the wire time of the packet as measured at MP(Dst), assigned to packets that arrive within a "reasonable" time. o Tmax, a maximum waiting time for packets to arrive, set sufficiently long to disambiguate packets with long delays from packets that are discarded (lost). o M, the total number of packets sent between T0 and Tf o N, the total number of packets received at Dst (sent between T0 and Tf) o Type-P, as defined in [RFC2330], which includes any field that may affect a packet's treatment as it traverses the network 3.3. Metric Definition This section is specific to each metric. 3.4. Metric Units The metric units are logical (1 or 0) when describing a single packet's loss performance, where a 0 indicates successful packet transmission and a 1 indicates packet loss. Units of time are as specified in [RFC2330]. Morton Expires October 8, 2012 [Page 5] Internet-Draft Round-trip Loss April 2012 Other units used are defined in the associated section. 4. A Singleton Round-trip Loss Metric 4.1. Name: Type-P-Round-trip-Loss 4.2. Metric Parameters See section 3.2. 4.3. Definition and Metric Units Type-P-Round-trip-Loss SHALL be represented by the binary logical values (or their equivalents) when the following conditions are met: Type-P-Round-trip-Loss = 0: o Src sent the first bit of a Type-P packet to Dst at wire-time TstampSrc, o that Dst received that packet, o the Dst sent a Type-P packet back to the Src as immediately as possible, and o that Src received the last bit of the reflected packet prior to wire-time TstampSrc + Tmax. Type-P-Round-trip-Loss = 1: o Src sent the first bit of a Type-P packet to Dst at wire-time TstampSrc, o that Src did not receive the last bit of the reflected packet before the waiting time lapsed at TstampSrc + Tmax. Possible causes for the Loss = 1 outcome are: o the Dst did not receive that packet, o the Dst did not send a Type-P packet back to the Src, or o the Src did not receive a reflected Type-P packet sent from the Dst. Following the precedent of[RFC2681], we make the simplifying assertion: Morton Expires October 8, 2012 [Page 6] Internet-Draft Round-trip Loss April 2012 Type-P-Round-trip-Loss(Src->Dst) = Type-P-Round-trip-Loss(Dst->Src) (and agree with the rationale presented there, that the ambiguity introduced is a small price to pay for measurement efficiency). Therefore, each singleton can be represented by pairs of elements as follows: o TstampSrc, the wire time of the packet at the Src (beginning the round-trip journey). o L, either zero or one (or some logical equivalent), where L=1 indicates loss and L=0 indicates successful round-trip arrival prior to TstampSrc + Tmax. 4.4. Discussion and other details See [RFC2680] and [RFC2681] for extensive discussion, methods of measurement, errors and uncertainties, and other fundamental considerations that need not be repeated here. 5. A Sample Round-trip Loss Metric Given the singleton metric Type-P-Round-trip-Loss, we now define one particular sample of such singletons. The idea of the sample is to select a particular binding of the parameters Src, Dst, and Type-P, then define a sample of values of parameter TstampSrc. This can be done in several ways, including: 1. Poisson: a pseudo-random Poisson process of rate lambda, whose values fall between T and Tf. The time interval between successive values of TstampSrc will then average 1/lambda, as per [RFC2330]. 2. Periodic: a periodic stream process with pseudo-random start time T0 between T and dT, and nominal inter-packet interval incT, as per [RFC3432]. In the metric name, the variable SHALL be replaced with the process used to define the sample, using one of the above processes (or other process, the details of which MUST be specified if used). 5.1. Name: Type-P-Round-trip-Loss--Stream Morton Expires October 8, 2012 [Page 7] Internet-Draft Round-trip Loss April 2012 5.2. Metric Parameters See section 3.2. 5.3. Definition and Metric Units Given one of the methods for defining the test interval, the sample of times (TstampSrc) and other metric parameters, we obtain a sequence of Type-P-Round-trip-Loss singletons as defined in section 4.3. Type-P-Round-trip-Loss--Stream SHALL be a sequence of pairs with elements as follows: o TstampSrc, as above o L, either zero or one (or some logical equivalent), where L=1 indicates loss and L=0 indicates successful round-trip arrival prior to TstampSrc + Tmax. where SHALL be replaced with "Poisson", "Periodic", or an appropriate term to designate another sample method meeting the criteria of [RFC2330]. 5.4. Discussion and other details See [RFC2680] and [RFC2681] for extensive discussion, methods of measurement, errors and uncertainties, and other fundamental considerations that need not be repeated here. However, when these references were approved, the packet reordering metrics in [RFC4737] had not yet been defined, nor had reordering been addressed in IPPM methodologies. [RFC4737] defines packets that arrive "late" with respect to their sending order as reordered. For example, when packets arrive with sequence numbers 4, 7, 5, 6, then packets 5 and 6 are reordered, and they are obviously not lost because they have arrived within some reasonable waiting time threshold. The presence of reordering on a round-trip path has several likely effects on the measurement. 1. Methods of measurement should continue to wait the specified time for packets, and avoid prematurely declaring round-trip loss when a sequence gap or error is observed. 2. The time distribution of the singletons in the sample has been significantly changed. Morton Expires October 8, 2012 [Page 8] Internet-Draft Round-trip Loss April 2012 3. Either the original packet stream or the reflected packet stream experienced path instability, and the original conditions may no longer be present. Measurement implementations MUST address the possibility for packet reordering and avoid related errors in their processes. 6. Round-trip Loss Statistic This section gives the primary and overall statistic for loss performance. Additional statistics and metrics originally prepared for One-way loss MAY also be applicable. 6.1. Type-P-Round-trip-Loss--Ratio Given a Type-P-Round-trip-Loss--Stream, the average of all the logical values, L, in the Stream is the Type-P-Round-trip-Loss- -Ratio. This ratio is in units of lost packets per round- trip transmissions actually attempted. In addition, the Type-P-Round-trip-Loss--Ratio is undefined if the sample is empty. 7. Round-trip Testing and One-way Reporting This section raises considerations for results collected using a round-trip measurement architecture, such as in TWAMP [RFC5357]. The sampling process for the reverse path (Dst->Src) is a conditional process that depends on successful packet arrival at the Dst and correct operation at the Dst to generate the reflected packet. Therefore, the sampling process for the reverse path will be significantly affected when appreciable loss occurs on the Src->Dst path, making an attempt to assess the reverse path performance invalid (for loss or possibly any metric). Further, the sampling times for the reverse path (Dst->Src) are a random process that depends on the original sample times (TstampSrc), the one-way-delay for successful packet arrival at the Dst, and time taken at the Dst to generate the reflected packet. Therefore, the sampling process for the reverse path will be significantly affected when appreciable delay variation occurs on the Src->Dst path, making an attempt to assess the reverse path performance invalid (for loss or possibly any metric). As discussed above, packet reordering is always a possibility. In Morton Expires October 8, 2012 [Page 9] Internet-Draft Round-trip Loss April 2012 addition to the severe delay variation that usually accompanies it, reordering on the Src->Dst path will cause a mis-alignment of sequence numbers applied at the reflector when compared to the sender numbers. Measurement implementations SHOULD address this possible outcome. 8. Measurement Considerations and Calibration Prior to conducting this measurement, the participating hosts MUST be configured to send and receive test packets of the chosen Type-P. Standard measurement protocols are capable of this task [RFC5357], but any reliable method is sufficient. Two key features of the host that receives test packets and returns them to the originating host are described in section 4.2 of [RFC5357] . Every received test packet MUST result in a responding packet, and the response MUST be generated as immediately as possible. This implies that interface buffers will be serviced promptly, and that buffer discards will be extremely rare. These features of the measurement equipment MUST be calibrated according to Section 3.7.3 of [RFC2679], when operating under a representative measurement load (as defined by the user). Both unexpected test packet discards and the systematic and random errors and uncertainties MUST be recorded. We note that Section 4.2.1 of [RFC5357] specifies a method to collect all four significant time-stamps needed to describe a packet's round- trip delay [RFC2681] and remove the processing time incurred at the responding host. This information supports the measurement of the corresponding One-way Delays encountered on the round-trip path, which can identify path asymmetry or unexpected processing time at the responding host. 9. Security Considerations 9.1. Denial of Service Attacks This metric requires a stream of packets sent from one host (source) to another host (destination) through intervening networks, and back. This method could be abused for denial of service attacks directed at the destination and/or the intervening network(s). Administrators of source, destination, and the intervening network(s) should establish bilateral or multi-lateral agreements regarding the timing, size, and frequency of collection of sample metrics. Use of this method in excess of the terms agreed between the participants Morton Expires October 8, 2012 [Page 10] Internet-Draft Round-trip Loss April 2012 may be cause for immediate rejection or discard of packets or other escalation procedures defined between the affected parties. 9.2. User Data Confidentiality Active use of this method generates packets for a sample, rather than taking samples based on user data, and does not threaten user data confidentiality. Passive measurement must restrict attention to the headers of interest. Since user payloads may be temporarily stored for length analysis, suitable precautions MUST be taken to keep this information safe and confidential. In most cases, a hashing function will produce a value suitable for payload comparisons. 9.3. Interference with the metrics It may be possible to identify that a certain packet or stream of packets is part of a sample. With that knowledge at the destination and/or the intervening networks, it is possible to change the processing of the packets (e.g. increasing or decreasing delay) in a way that may distort the measured performance. It may also be possible to generate additional packets that appear to be part of the sample metric. These additional packets are likely to perturb the results of the sample measurement. Authentication or encryption techniques, such as digital signatures, MAY be used where appropriate to guard against injected traffic attacks. [RFC5357] includes both authentication and encryption features. 10. IANA Considerations Metrics previously defined in IETF were registered in the IANA IPPM METRICS REGISTRY, however this process was discontinued when the registry structure was found to be inadequate, and the registry was declared Obsolete [RFC6248]. Although the metrics in this draft may be considered for some form of registration in the future, no IANA Action is requested at this time. 11. Acknowledgements The author thanks Tiziano Ionta for his careful review of this memo, primarily resulting in the development of measurement considerations using TWAMP [RFC5357] as an example method. Morton Expires October 8, 2012 [Page 11] Internet-Draft Round-trip Loss April 2012 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, November 2002. [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008. 12.2. Informative References [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009. [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete", RFC 6248, April 2011. Morton Expires October 8, 2012 [Page 12] Internet-Draft Round-trip Loss April 2012 Author's Address Al Morton AT&T Labs 200 Laurel Avenue South Middletown,, NJ 07748 USA Phone: +1 732 420 1571 Fax: +1 732 368 1192 Email: acmorton@att.com URI: http://home.comcast.net/~acmacm/ Morton Expires October 8, 2012 [Page 13] --=====================_16846153==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="rfcdiff-rt-loss-03-04prelim.htm" Diff: draft-ietf-ippm-rt-loss-03.txt - draft-ietf-ippm-rt-loss-04prelim.txt
< draft-ietf-ippm-rt-loss-03.txt   draft-ietf-ippm-rt-loss-04prelim.txt >
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Standards Track March 1, 2012 Intended status: Standards Track April 6, 2012
Expires: September 2, 2012 Expires: October 8, 2012
Round-trip Loss Metrics Round-trip Loss Metrics
draft-ietf-ippm-rt-loss-03 draft-ietf-ippm-rt-loss-04prelim
Abstract Abstract
Many user applications (and the transport protocols that make them Many user applications (and the transport protocols that make them
possible) require two-way communications. To assess this capability, possible) require two-way communications. To assess this capability,
and to achieve test system simplicity, round-trip loss measurements and to achieve test system simplicity, round-trip loss measurements
are frequently conducted in practice. The Two-Way Active Measurement are frequently conducted in practice. The Two-Way Active Measurement
Protocol specified in RFC 5357 establishes a round-trip loss Protocol specified in RFC 5357 establishes a round-trip loss
measurement capability for the Internet. However, there is currently measurement capability for the Internet. However, there is currently
no metric specified according to the RFC 2330 framework. no metric specified according to the RFC 2330 framework.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on September 2, 2012. This Internet-Draft will expire on October 8, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Common Specifications for Round-trip Metrics . . . . . . . . . 4 3. Common Specifications for Round-trip Metrics . . . . . . . . . 4
3.1. Name: Type-P-* . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Name: Type-P-* . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 4 3.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 5
3.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 5 3.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 5
3.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 5
4. A Singleton Round-trip Loss Metric . . . . . . . . . . . . . . 5 4. A Singleton Round-trip Loss Metric . . . . . . . . . . . . . . 6
4.1. Name: Type-P-Round-trip-Loss . . . . . . . . . . . . . . . 5 4.1. Name: Type-P-Round-trip-Loss . . . . . . . . . . . . . . . 6
4.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 6 4.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 6
4.3. Definition and Metric Units . . . . . . . . . . . . . . . 6 4.3. Definition and Metric Units . . . . . . . . . . . . . . . 6
4.4. Discussion and other details . . . . . . . . . . . . . . . 7 4.4. Discussion and other details . . . . . . . . . . . . . . . 7
5. A Sample Round-trip Loss Metric . . . . . . . . . . . . . . . 7 5. A Sample Round-trip Loss Metric . . . . . . . . . . . . . . . 7
5.1. Name: Type-P-Round-trip-Loss-<Sample>-Stream . . . . . . . 7 5.1. Name: Type-P-Round-trip-Loss-<Sample>-Stream . . . . . . . 7
5.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 7 5.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 8
5.3. Definition and Metric Units . . . . . . . . . . . . . . . 7 5.3. Definition and Metric Units . . . . . . . . . . . . . . . 8
5.4. Discussion and other details . . . . . . . . . . . . . . . 8 5.4. Discussion and other details . . . . . . . . . . . . . . . 8
6. Round-trip Loss Statistic . . . . . . . . . . . . . . . . . . 9 6. Round-trip Loss Statistic . . . . . . . . . . . . . . . . . . 9
6.1. Type-P-Round-trip-Loss-<Sample>-Ratio . . . . . . . . . . 9 6.1. Type-P-Round-trip-Loss-<Sample>-Ratio . . . . . . . . . . 9
7. Round-trip Testing and One-way Reporting . . . . . . . . . . . 9 7. Round-trip Testing and One-way Reporting . . . . . . . . . . . 9
8. Measurement Considerations and Calibration . . . . . . . . . . 10 8. Measurement Considerations and Calibration . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 10 9.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 10
9.2. User Data Confidentiality . . . . . . . . . . . . . . . . 10 9.2. User Data Confidentiality . . . . . . . . . . . . . . . . 11
9.3. Interference with the metrics . . . . . . . . . . . . . . 11 9.3. Interference with the metrics . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This memo defines a metric to quantify an IP network's ability to
transfer packets in both directions from one host to another host.
Two-way communication is almost always needed, thus failure to
transfer a packet in either direction constitutes a round-trip loss.
This memo defines a metric for round-trip loss on Internet paths. It This memo defines a metric for round-trip loss on Internet paths. It
builds on the notions and conventions introduced in the IP builds on the notions and conventions introduced in the IP
Performance Metrics (IPPM) framework [RFC2330]. Also, the Performance Metrics (IPPM) framework [RFC2330]. Also, the
specifications of the One-way Loss metric [RFC2680] and the Round- specifications of the One-way Loss metric [RFC2680] and the Round-
trip Delay metric [RFC2681] are frequently referenced and modified to trip Delay metric [RFC2681] are frequently referenced and modified to
match the round-trip circumstances addressed here. However, this match the round-trip circumstances addressed here. However, this
memo assumes that the reader is familiar with the references, and memo assumes that the reader is familiar with the references, and
does not repeat material as was done in [RFC2681]. does not repeat material as was done in [RFC2681].
This memo uses the terms "two-way" and "round-trip" synonymously. This memo uses the terms "two-way" and "round-trip" synonymously.
skipping to change at page 3, line 31 skipping to change at page 3, line 36
possible require two-way communications. For example, the TCP SYN->, possible require two-way communications. For example, the TCP SYN->,
<-SYN-ACK, ACK-> three-way handshake attempted billions of times each <-SYN-ACK, ACK-> three-way handshake attempted billions of times each
day cannot be completed without two-way connectivity in a near- day cannot be completed without two-way connectivity in a near-
simultaneous time interval. Thus, measurements of Internet round- simultaneous time interval. Thus, measurements of Internet round-
trip loss performance provide a basis to infer application trip loss performance provide a basis to infer application
performance more easily. performance more easily.
Measurement system designers have also recognized advantages of Measurement system designers have also recognized advantages of
system simplicity when one host simply echoes or reflects test system simplicity when one host simply echoes or reflects test
packets to the sender. Round-trip loss measurements are frequently packets to the sender. Round-trip loss measurements are frequently
conducted and reported in practice. The Two-Way Active Measurement conducted and reported in practice. The ubiquitous "ping" tools
Protocol (TWAMP) specified in [RFC5357] establishes a round-trip loss allow the measurement of round-trip loss and delay, but usually
measurement capability for the Internet. However, there is currently require ICMP Echo-Request/Reply support, and ICMP packets may
no round-trip loss metric specified according to the [RFC2330] encounter exceptional treatment on the measurement path (see Section
framework. 2.6 of [RFC2681]). The Two-Way Active Measurement Protocol (TWAMP)
specified in [RFC5357] establishes a round-trip loss measurement
capability for the Internet. However, there is currently no round-
trip loss metric specified according to the [RFC2330] framework.
[RFC2681] indicates that round-trip measurements may sometimes [RFC2681] indicates that round-trip measurements may sometimes
encounter "asymmetric" paths. When loss is observed using a round- encounter "asymmetric" paths. When loss is observed using a round-
trip measurement, there is often a desire to ascertain which of the trip measurement, there is often a desire to ascertain which of the
two directional paths "lost" the packet. Under some circumstances, two directional paths "lost" the packet. Under some circumstances,
it is possible to make this inference. The round-trip measurement it is possible to make this inference. The round-trip measurement
method raises a few complications when interpreting the embedded one- method raises a few complications when interpreting the embedded one-
way results, and the user should be aware of them. way results, and the user should be aware of them.
[RFC2681] also points out that loss measurement conducted [RFC2681] also points out that loss measurement conducted
skipping to change at page 4, line 19 skipping to change at page 4, line 28
See Section 1.1 of[RFC2680] for additional motivation of the packet See Section 1.1 of[RFC2680] for additional motivation of the packet
loss metric. loss metric.
2. Scope 2. Scope
This memo defines a round-trip loss metric using the conventions of This memo defines a round-trip loss metric using the conventions of
the IPPM framework [RFC2330]. the IPPM framework [RFC2330].
The memo defines a singleton metric, a sample metric, and a The memo defines a singleton metric, a sample metric, and a
statistic, as per [RFC2330]. statistic, as per [RFC2330]. The [RFC2330] framework is for active
measurement methods. Although this metric MAY be applicable in
passive measurement as well, discussion of additional considerations
for the passive scenario are beyond the normative scope of this memo.
The memo also investigates the topic of one-way loss inference from a The memo also investigates the topic of one-way loss inference from a
two-way measurement, and lists some key considerations. two-way measurement, and lists some key considerations.
3. Common Specifications for Round-trip Metrics 3. Common Specifications for Round-trip Metrics
To reduce the redundant information presented in the detailed metrics To reduce the redundant information presented in the detailed metrics
sections that follow, this section presents the specifications that sections that follow, this section presents the specifications that
are common to two or more metrics. The section is organized using are common to two or more metrics. The section is organized using
the same subsections as the individual metrics, to simplify the same subsections as the individual metrics, to simplify
skipping to change at page 8, line 33 skipping to change at page 8, line 42
considerations that need not be repeated here. However, when these considerations that need not be repeated here. However, when these
references were approved, the packet reordering metrics in [RFC4737] references were approved, the packet reordering metrics in [RFC4737]
had not yet been defined, nor had reordering been addressed in IPPM had not yet been defined, nor had reordering been addressed in IPPM
methodologies. methodologies.
[RFC4737] defines packets that arrive "late" with respect to their [RFC4737] defines packets that arrive "late" with respect to their
sending order as reordered. For example, when packets arrive with sending order as reordered. For example, when packets arrive with
sequence numbers 4, 7, 5, 6, then packets 5 and 6 are reordered, and sequence numbers 4, 7, 5, 6, then packets 5 and 6 are reordered, and
they are obviously not lost because they have arrived within some they are obviously not lost because they have arrived within some
reasonable waiting time threshold. The presence of reordering on a reasonable waiting time threshold. The presence of reordering on a
round-trip path has several likely affects on the measurement. round-trip path has several likely effects on the measurement.
1. Methods of measurement should continue to wait the specified time 1. Methods of measurement should continue to wait the specified time
for packets, and avoid prematurely declaring round-trip loss when for packets, and avoid prematurely declaring round-trip loss when
a sequence gap or error is observed. a sequence gap or error is observed.
2. The time distribution of the singletons in the sample has been 2. The time distribution of the singletons in the sample has been
significantly changed. significantly changed.
3. Either the original packet stream or the reflected packet stream 3. Either the original packet stream or the reflected packet stream
experienced path instability, and the original conditions may no experienced path instability, and the original conditions may no
skipping to change at page 10, line 13 skipping to change at page 10, line 18
outcome. outcome.
8. Measurement Considerations and Calibration 8. Measurement Considerations and Calibration
Prior to conducting this measurement, the participating hosts MUST be Prior to conducting this measurement, the participating hosts MUST be
configured to send and receive test packets of the chosen Type-P. configured to send and receive test packets of the chosen Type-P.
Standard measurement protocols are capable of this task [RFC5357], Standard measurement protocols are capable of this task [RFC5357],
but any reliable method is sufficient. but any reliable method is sufficient.
Two key features of the host that receives test packets and returns Two key features of the host that receives test packets and returns
them to the originating host is described in section 4.2 of [RFC5357] them to the originating host are described in section 4.2 of
. Every received test packet MUST result in a responding packet, and [RFC5357] . Every received test packet MUST result in a responding
the response MUST be generated as immediately as possible. This packet, and the response MUST be generated as immediately as
implies that interface buffers will be serviced promptly, and that possible. This implies that interface buffers will be serviced
buffer discards will be extremely rare. These features of the promptly, and that buffer discards will be extremely rare. These
measurement equipment MUST be calibrated according to Section 3.7.3 features of the measurement equipment MUST be calibrated according to
of [RFC2679], when operating under a representative measurement load Section 3.7.3 of [RFC2679], when operating under a representative
(as defined by the user). Both unexpected test packet discards and measurement load (as defined by the user). Both unexpected test
the systematic and random errors and uncertainties MUST be recorded. packet discards and the systematic and random errors and
uncertainties MUST be recorded.
We note that Section 4.2.1 of [RFC5357] specifies a method to collect We note that Section 4.2.1 of [RFC5357] specifies a method to collect
all four significant time-stamps needed to describe a packet's round- all four significant time-stamps needed to describe a packet's round-
trip delay [RFC2681] and remove the processing time incurred at the trip delay [RFC2681] and remove the processing time incurred at the
responding host. This information supports the measurement of the responding host. This information supports the measurement of the
corresponding One-way Delays encountered on the round-trip path, corresponding One-way Delays encountered on the round-trip path,
which can identify path asymmetry or unexpected processing time at which can identify path asymmetry or unexpected processing time at
the responding host. the responding host.
9. Security Considerations 9. Security Considerations
skipping to change at page 11, line 14 skipping to change at page 11, line 22
headers of interest. Since user payloads may be temporarily stored headers of interest. Since user payloads may be temporarily stored
for length analysis, suitable precautions MUST be taken to keep this for length analysis, suitable precautions MUST be taken to keep this
information safe and confidential. In most cases, a hashing function information safe and confidential. In most cases, a hashing function
will produce a value suitable for payload comparisons. will produce a value suitable for payload comparisons.
9.3. Interference with the metrics 9.3. Interference with the metrics
It may be possible to identify that a certain packet or stream of It may be possible to identify that a certain packet or stream of
packets is part of a sample. With that knowledge at the destination packets is part of a sample. With that knowledge at the destination
and/or the intervening networks, it is possible to change the and/or the intervening networks, it is possible to change the
processing of the packets (e.g. increasing or decreasing delay) that processing of the packets (e.g. increasing or decreasing delay) in a
may distort the measured performance. It may also be possible to way that may distort the measured performance. It may also be
generate additional packets that appear to be part of the sample possible to generate additional packets that appear to be part of the
metric. These additional packets are likely to perturb the results sample metric. These additional packets are likely to perturb the
of the sample measurement. results of the sample measurement.
To discourage the kind of interference mentioned above, packet Authentication or encryption techniques, such as digital signatures,
interference checks, such as cryptographic hash, may be used. MAY be used where appropriate to guard against injected traffic
attacks. [RFC5357] includes both authentication and encryption
features.
10. IANA Considerations 10. IANA Considerations
Metrics previously defined in IETF were registered in the IANA IPPM Metrics previously defined in IETF were registered in the IANA IPPM
METRICS REGISTRY, however this process was discontinued when the METRICS REGISTRY, however this process was discontinued when the
registry structure was found to be inadequate, and the registry was registry structure was found to be inadequate, and the registry was
declared Obsolete [RFC6248]. declared Obsolete [RFC6248].
Although the metrics in this draft may be considered for some form of Although the metrics in this draft may be considered for some form of
registration in the future, no IANA Action is requested at this time. registration in the future, no IANA Action is requested at this time.
 End of changes. 15 change blocks. 
35 lines changed or deleted 49 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/
--=====================_16846153==_-- From new-work-bounces@ietf.org Fri Apr 6 12:11:34 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 B886B21F84F9; Fri, 6 Apr 2012 12:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333739494; bh=++LwR0CednJ5YdSS3jQDEbNjVNxVL+6BLA48ZCRap0c=; 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=jvnGTGx0EB6hRF1UU7K+hnlmUPkssSIypcdLxXfU9mh6E7Ee4SNpZ76PMPiO4FCMp QZqX1jsuewIslnqvrPMEO+H4akM8ALSPlmNnOPDY2YfHzx0XHMUQmS6dmlHgM998S1 EBtvJ6hUDbbmHPYHbPAA+7YiB5LpGM9EfnRb+NVg= 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 D411B21F84F9 for ; Fri, 6 Apr 2012 12:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.392 X-Spam-Level: X-Spam-Status: No, score=-9.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 EwbUx+HN2PWR for ; Fri, 6 Apr 2012 12:11:33 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD3E21F84F4 for ; Fri, 6 Apr 2012 12:11:33 -0700 (PDT) Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1SGEZI-0005il-H9; Fri, 06 Apr 2012 15:11:32 -0400 From: Ian Jacobs Date: Fri, 6 Apr 2012 14:11:31 -0500 To: new-work@ietf.org Message-Id: <9821BDCA-7F1D-44FF-A8B6-B60AB3DB2487@w3.org> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 06 Apr 2012 12:15:18 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Timed Text Working Group (until 2012-05-04) 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, 06 Apr 2012 19:11:34 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Video in the Web Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Timed Text Working Group: http://www.w3.org/2012/02/timed-text-wg-charter 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-05-04 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 Philippe Le H=E9garet, Interaction Domain Lead . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2008/WebVideo/ [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 adrian@olddog.co.uk Sat Apr 7 10:02:57 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 BE3D521F84FA; Sat, 7 Apr 2012 10:02:57 -0700 (PDT) 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 dbtB84RANZuX; Sat, 7 Apr 2012 10:02:57 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 4244A21F84F7; Sat, 7 Apr 2012 10:02:56 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q37H2n7E031354; Sat, 7 Apr 2012 18:02:49 +0100 Received: from 950129200 (AGrenoble-551-1-55-195.w86-197.abo.wanadoo.fr [86.197.14.195]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q37H2FrE031266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 7 Apr 2012 18:02:22 +0100 From: "Adrian Farrel" To: "'Al Morton'" , "'Samuel Weiler'" , "'The IESG'" References: <20120406144445.4188.3196.idtracker@ietfa.amsl.com> <201204061553.q36FrBRV007699@alpd052.aldc.att.com> In-Reply-To: <201204061553.q36FrBRV007699@alpd052.aldc.att.com> Date: Sat, 7 Apr 2012 18:02:17 +0100 Message-ID: <07e001cd14e0$41b408c0$c51c1a40$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIbFLUL4L9fmeWqHCNmPVdbYjLawgGKVkKalec/IsA= Content-Language: en-gb Cc: ippm-chairs@tools.ietf.org, draft-ietf-ippm-rt-loss@tools.ietf.org, 'Dan Frost' , "'Murphy, Sandra'" , secdir@ietf.org Subject: Re: [secdir] Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 17:02:57 -0000 Hi Al, Thanks for the response. > >Adrian Farrel has entered the following ballot position for > >draft-ietf-ippm-rt-loss-03: Discuss > > > > > General observation: It's not clear to me what the IPPM WG strategy > > > is for security considerations sections in metric definition > > > documents. For example, the security section of this document more or > > > less repeats the one in (for example) RFC 2681, which itself > > > duplicates verbatim the one in RFC 2680, and the issues discussed are > > > general ones with measurement protocols rather than specific ones with > > > the metric that is the subject of the document. There's probably a > > > better way to organize this. > > Although IPPM has never formalized a strategy, we have been repeating > security material in metrics RFCs. This allows new folks to read > and improve the text, rather than be referred to a fixed reference. > It seems to work. I can see how that would lead to the verbatim reproduction of text. I have no problem with that per se, but I worry that the process has become formulaic without any new consideration of security for the specific document in hand. If you tell me that this is adequate for this document and no refinement is needed in this case, I will clear and let the Security ADs and Directorate worry about the security details. > > > 3. Section 9.3 mentions the use of cryptographic hashing "to > > > discourage the kind of interference mentioned above"; while this > > > would mitigate the second form of interference, it wouldn't help > > > with the first. > > > >I would add that "discourage" might not be an appropriate word. > > New paragraph addresses Sandy and Dan's points. Thanks. > >COMMENT: > > > >Other comments coming from Dan Frost's review > > > > > 1. Although it's probably obvious to most readers, it would be helpful > > > to provide a brief informal definition of "round-trip loss" early in > > > the introduction. A mention of the venerable "ping" procedure would > > > also not be amiss. > > Did both. > > > > 2. Most of the text seems to assume an "active" or test-based > > > measurement approach, but Section 9.2 refers to passive measurement. > > > It would be helpful to discuss the applicability of the latter > > > approach. > > Clarified the scope for passive. > > > > Nits: > > > > > > 1. The phrase "as immediately as possible" that appears a couple of > > > times in the text (and that seems to originate in RFC 5357) is a bit > > > unfortunate. "Immediately" or "as quickly as possible" are better. > > This odd turn of phrase resulted from many hours of discussion > dating back to TWAMP's development. We wear the scar proudly. Well, this is only a Comment, and you do not have to address it, but "as immediately as possible" is hogwash. It is a butchery of the language and means nothing! In fact, and as a general principle of writing standards, even "as quickly as possible" would be poor. The English would be fine, but it is a subjective statement against which conformance cannot be measured. > > > 2. Section 5.4, second paragraph: s/affects/effects/ > > > > > > 3. Section 8, second paragraph: s/Two key features ... is described/ > > > Two key features ... are described/ > > > > > > 4. Section 9.3, first paragraph: > > > OLD > > > it is possible to change the processing of the packets (e.g. > > > increasing or decreasing delay) that may distort the measured > > > performance. > > > NEW > > > it is possible to change the processing of the packets (e.g. > > > increasing or decreasing delay) in a way that may distort the > > > measured performance. > > > END > > thanks for pointing out the above. Cheers, Adrian From acmorton@att.com Sat Apr 7 17:18: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 072B921F85B4; Sat, 7 Apr 2012 17:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.796 X-Spam-Level: X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, 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 y7+YOHWlnKDz; Sat, 7 Apr 2012 17:18:55 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 262B521F85A8; Sat, 7 Apr 2012 17:18:55 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id e69d08f4.0.2436244.00-403.6738823.nbfkord-smmo04.seg.att.com (envelope-from ); Sun, 08 Apr 2012 00:18:55 +0000 (UTC) X-MXL-Hash: 4f80d96f7d417c7a-00de33143131ed23b01daebd12e059f8ad09cbab Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q380IsWY001138; Sat, 7 Apr 2012 20:18:54 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q380InPA001115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2012 20:18:50 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor); Sat, 7 Apr 2012 20:18:10 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q380I9Dx008153; Sat, 7 Apr 2012 20:18:10 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q380I1Wi007745; Sat, 7 Apr 2012 20:18:02 -0400 Message-Id: <201204080018.q380I1Wi007745@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-218-229.vpn.east.att.com[135.70.218.229](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20120408001459gw1004or31e>; Sun, 8 Apr 2012 00:15:05 +0000 X-Originating-IP: [135.70.218.229] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 07 Apr 2012 20:19:04 -0400 To: adrian@olddog.co.uk, "'Samuel Weiler'" , "'The IESG'" From: Al Morton In-Reply-To: <07e001cd14e0$41b408c0$c51c1a40$@olddog.co.uk> References: <20120406144445.4188.3196.idtracker@ietfa.amsl.com> <201204061553.q36FrBRV007699@alpd052.aldc.att.com> <07e001cd14e0$41b408c0$c51c1a40$@olddog.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=u9h4ZY5ZTRIA:10 a=ZswZ2TFLv48A:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=yHZoGYZOrkWJAXPRocgA:9 a=7ZIazfIgaURd4f79Y] X-AnalysisOut: [E4A:7 a=CjuIK1q_8ugA:10] Cc: ippm-chairs@tools.ietf.org, draft-ietf-ippm-rt-loss@tools.ietf.org, 'Dan Frost' , "'Murphy, Sandra'" , secdir@ietf.org Subject: Re: [secdir] Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT) 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, 08 Apr 2012 00:18:56 -0000 Hi Adrian, Thanks for your reply. We've narrowed the discussion down to two issues. see below, At 01:02 PM 4/7/2012, Adrian Farrel wrote: > > > > General observation: It's not clear to me what the IPPM WG strategy > > > > is for security considerations sections in metric definition > > > > documents. For example, the security section of this document more or > > > > less repeats the one in (for example) RFC 2681, which itself > > > > duplicates verbatim the one in RFC 2680, and the issues discussed are > > > > general ones with measurement protocols rather than specific ones with > > > > the metric that is the subject of the document. There's probably a > > > > better way to organize this. > > > > Although IPPM has never formalized a strategy, we have been repeating > > security material in metrics RFCs. This allows new folks to read > > and improve the text, rather than be referred to a fixed reference. > > It seems to work. > >I can see how that would lead to the verbatim reproduction of text. I have no >problem with that per se, but I worry that the process has become formulaic >without any new consideration of security for the specific document in hand. > >If you tell me that this is adequate for this document and no refinement is >needed in this case, I will clear and let the Security ADs and >Directorate worry >about the security details. I think it is. We are essentially conducting a two-way version of RFC 2680 (one-way loss), so all the same considerations apply. We have exposure in two (possibly different) paths, but the threats are the same. >... > > > > Nits: > > > > > > > > 1. The phrase "as immediately as possible" that appears a couple of > > > > times in the text (and that seems to originate in RFC 5357) is a bit > > > > unfortunate. "Immediately" or "as quickly as possible" are better. > > > > This odd turn of phrase resulted from many hours of discussion > > dating back to TWAMP's development. We wear the scar proudly. > >Well, this is only a Comment, and you do not have to address it, but "as >immediately as possible" is hogwash. It is a butchery of the >language and means >nothing! > >In fact, and as a general principle of writing standards, even "as quickly as >possible" would be poor. The English would be fine, but it is a subjective >statement against which conformance cannot be measured. Under typical protocol development circumstances, we could write a real requirement: The response MUST be prepared and sent on the wire in 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 1346A21F84A1 for ; Sun, 8 Apr 2012 02:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.587 X-Spam-Level: X-Spam-Status: No, score=-1.587 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, TVD_SPACED_SUBJECT_WORD3=2.412] 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 nZkvgQceT7gu for ; Sun, 8 Apr 2012 02:11:33 -0700 (PDT) Received: from efes.iucc.ac.il (efes.iucc.ac.il [128.139.202.17]) by ietfa.amsl.com (Postfix) with ESMTP id 09BBB21F84AF for ; Sun, 8 Apr 2012 02:11:32 -0700 (PDT) Received: from hank-lenovo.efes.iucc.ac.il (adsl-v01-32a5522ebb.tau.ac.il [132.66.222.13]) by efes.iucc.ac.il (Postfix) with ESMTP id EA341318074; Sun, 8 Apr 2012 12:11:26 +0300 (IDT) Message-Id: <5.1.0.14.2.20120408115646.03793228@efes.iucc.ac.il> X-Sender: hank@efes.iucc.ac.il X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 08 Apr 2012 12:11:22 +0300 To: stephen.farrell@cs.tcd.ie,turners@ieca.com,secdir@ietf.org From: Hank Nussbacher Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-MimeHeaders-Plugin-Info: v2.03.00 X-Mailman-Approved-At: Sun, 08 Apr 2012 05:34:51 -0700 Subject: [secdir] WebRTC 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, 08 Apr 2012 09:14:53 -0000 Dear Security Area people, Quick intro: WebRTC http://www.webrtc.org/ is a free, open project that enables web browsers with Real-Time Communications (RTC) capabilities via simple Javascript APIs. It is supported by Google, Mozilla and Opera. One can test it already in Chrome. Basically, it is meant to be a Skype replacement technology (no app to download - all built-in to the browser). But there are many other ideas that can be used here with this technology. Now we get to the security part. As stated here: http://www.webrtc.org/blog/webrtcnowavailableinthechromedevchannel one has to specifically enable "--enable-media-stream" in order to get it to work. That is now, but the future plan is to have this "on" by default in FF and Chrome by the end of 2012. So what does the IETF have to say: Security Considerations for RTC-Web http://tools.ietf.org/html/draft-ietf-rtcweb-security-01 which caused: RTCWEB Security Architecture http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-01 Section 5.2: "Clients MAY permit the formation of data channels without any direct user approval." I can just see new apps all over the place using this technology opening a huge can of worms for data stealing from the PC running the app that did NOT ask permission for the formation of a data channel without the direct user's permission. This is similar in concept to ActiveX: http://en.wikipedia.org/wiki/ActiveX "This made the web "richer" but provoked objections (since such controls ran only on Windows) and security risks (especially given the lack of user intervention). Microsoft subsequently introduced security measures to make browsing including ActiveX safer[6] . For example: digital signing of installation packages (Cabinet files and executables) controls must explicitly declare themselves safe for scripting increasingly stringent default security settings Internet Explorer maintains a blacklist of bad controls" Microsoft didn't envision the security issues of a "lack of user intervention" and it took them 3 years to add the appropriate knobs to make ActiveX more secure. I am not involved in WebRTC or the IETF group - I only found out about this incidentally. I raise this issue to you guys and leave it the Security Area to decide whether section 5 needs to be changed or not. Regards, Hank Nussbacher From stephen.farrell@cs.tcd.ie Sun Apr 8 05:37: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 0731221F853E for ; Sun, 8 Apr 2012 05:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.187 X-Spam-Level: X-Spam-Status: No, score=-100.187 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, TVD_SPACED_SUBJECT_WORD3=2.412, 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 NJ0iG6IOr6p9 for ; Sun, 8 Apr 2012 05:37:38 -0700 (PDT) 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 C811421F84CD for ; Sun, 8 Apr 2012 05:37:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 2D026171478; Sun, 8 Apr 2012 13:37:36 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1333888655; bh=CN3nJTHG//yxN1 /Kyq1UAd4duWmBDhH+d1r0bPYYlYE=; b=OK4tzGXzRHu4bOwbo+Y1BqB7dvvZgI bkgbSdzqG5+A2KBwo09Da+0PrzRISGheZhUtjyqvrHUbdX9OK7W0ELkk1v+Mvoof RJEjqXwGCS52inPmBSxvDU/3FYrD2ixXXTv0JoALY12UmkZQlUXXbVbcJ2R6QQWF o3bO9wBwoGDBP0ALwKTVPp9XGEgQ8eDbR9d6kuZ78lV4IIlQY9KJ0gJtL0JIXvT7 HbghVtQq01PrWCvD5jpJLnkjSzf7bbFwQ71GzFqjmriGbS7puJuGnv0D2G2ZgHir m3NBu2WWrkwoeRaJgap89MkEPlogMAVuZhIdMDsuQWjx/0J7QDMzPqlw== 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 j2LcLJdIErCp; Sun, 8 Apr 2012 13:37:35 +0100 (IST) Received: from [10.87.48.4] (unknown [86.45.57.41]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 55202171471; Sun, 8 Apr 2012 13:37:32 +0100 (IST) Message-ID: <4F81868C.3090601@cs.tcd.ie> Date: Sun, 08 Apr 2012 13:37:32 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Hank Nussbacher References: <5.1.0.14.2.20120408115646.03793228@efes.iucc.ac.il> In-Reply-To: <5.1.0.14.2.20120408115646.03793228@efes.iucc.ac.il> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org Subject: Re: [secdir] WebRTC 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, 08 Apr 2012 12:37:39 -0000 Hi Hank, This might be more appropriate for the security area list [1] rather than the security directorate list. (This one.) Cheers, S. [1] https://www.ietf.org/mailman/listinfo/saag On 04/08/2012 10:11 AM, Hank Nussbacher wrote: > Dear Security Area people, > > Quick intro: > > WebRTC http://www.webrtc.org/ is a free, open project that enables web > browsers with Real-Time Communications (RTC) capabilities via simple > Javascript APIs. It is supported by Google, Mozilla and Opera. One can > test it already in Chrome. Basically, it is meant to be a Skype > replacement technology (no app to download - all built-in to the > browser). But there are many other ideas that can be used here with this > technology. > > Now we get to the security part. As stated here: > http://www.webrtc.org/blog/webrtcnowavailableinthechromedevchannel > one has to specifically enable "--enable-media-stream" in order to get > it to work. That is now, but the future plan is to have this "on" by > default in FF and Chrome by the end of 2012. > > So what does the IETF have to say: > > Security Considerations for RTC-Web > http://tools.ietf.org/html/draft-ietf-rtcweb-security-01 > which caused: > RTCWEB Security Architecture > http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-01 > Section 5.2: > "Clients MAY permit the formation of data channels without any direct > user approval." > > I can just see new apps all over the place using this technology opening > a huge can of worms for data stealing from the PC running the app that > did NOT ask permission for the formation of a data channel without the > direct user's permission. This is similar in concept to ActiveX: > http://en.wikipedia.org/wiki/ActiveX > "This made the web "richer" but provoked objections (since such controls > ran only on Windows) and security risks (especially given the lack of > user intervention). Microsoft subsequently introduced security measures > to make browsing including ActiveX safer[6] . For example: > > digital signing of installation packages (Cabinet files and executables) > controls must explicitly declare themselves safe for scripting > increasingly stringent default security settings > Internet Explorer maintains a blacklist of bad controls" > > Microsoft didn't envision the security issues of a "lack of user > intervention" and it took them 3 years to add the appropriate knobs to > make ActiveX more secure. > > I am not involved in WebRTC or the IETF group - I only found out about > this incidentally. I raise this issue to you guys and leave it the > Security Area to decide whether section 5 needs to be changed or not. > > Regards, > Hank Nussbacher > > From paul.hoffman@vpnc.org Sun Apr 8 06:53: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 8A8FB21F8512 for ; Sun, 8 Apr 2012 06:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 8qYg6H5QOF1F for ; Sun, 8 Apr 2012 06:53:47 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 18E9A21F850D for ; Sun, 8 Apr 2012 06:53:47 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q38Dp1el003834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 Apr 2012 06:51:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F81868C.3090601@cs.tcd.ie> Date: Sun, 8 Apr 2012 06:51:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5.1.0.14.2.20120408115646.03793228@efes.iucc.ac.il> <4F81868C.3090601@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1257) Cc: Hank Nussbacher , secdir@ietf.org Subject: Re: [secdir] WebRTC 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, 08 Apr 2012 13:53:47 -0000 It also might be more appropriate for the rtcweb WG, which has been = discussing this actively since the beginning. Instead of security folks = forming opinions based on a post like this, it might be beneficial for = us to look through the WG archives first. --Paul Hoffman From adrian@olddog.co.uk Sun Apr 8 11:04: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 21B2321F853E; Sun, 8 Apr 2012 11:04:16 -0700 (PDT) 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=[AWL=0.000, 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 OJAoHbk9MIuN; Sun, 8 Apr 2012 11:04:15 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF7321F8503; Sun, 8 Apr 2012 11:04:14 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q38I44PA023289; Sun, 8 Apr 2012 19:04:08 +0100 Received: from 950129200 (AGrenoble-551-1-55-195.w86-197.abo.wanadoo.fr [86.197.14.195]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q38I40Qa023275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 Apr 2012 19:04:02 +0100 From: "Adrian Farrel" To: "'Al Morton'" , "'Samuel Weiler'" , "'The IESG'" References: <20120406144445.4188.3196.idtracker@ietfa.amsl.com> <201204061553.q36FrBRV007699@alpd052.aldc.att.com> <07e001cd14e0$41b408c0$c51c1a40$@olddog.co.uk> <201204080018.q380I1VK007743@alpd052.aldc.att.com> In-Reply-To: <201204080018.q380I1VK007743@alpd052.aldc.att.com> Date: Sun, 8 Apr 2012 19:04:01 +0100 Message-ID: <099701cd15b1$fc18c990$f44a5cb0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIbFLUL4L9fmeWqHCNmPVdbYjLawgGKVkKaAd6sRCwBimPGyZXNnLSA Content-Language: en-gb Cc: ippm-chairs@tools.ietf.org, draft-ietf-ippm-rt-loss@tools.ietf.org, 'Dan Frost' , "'Murphy, Sandra'" , secdir@ietf.org Subject: Re: [secdir] Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 18:04:16 -0000 Hello Al, > > > Although IPPM has never formalized a strategy, we have been repeating > > > security material in metrics RFCs. This allows new folks to read > > > and improve the text, rather than be referred to a fixed reference. > > > It seems to work. > > > >I can see how that would lead to the verbatim reproduction of text. I have no > >problem with that per se, but I worry that the process has become formulaic > >without any new consideration of security for the specific document in hand. > > > >If you tell me that this is adequate for this document and no refinement is > >needed in this case, I will clear and let the Security ADs and > >Directorate worry > >about the security details. > > I think it is. We are essentially conducting a two-way version of RFC 2680 > (one-way loss), so all the same considerations apply. We have exposure in > two (possibly different) paths, but the threats are the same. OK. I cleared my Discuss. > > > > > 1. The phrase "as immediately as possible" that appears a couple of > > > > > times in the text (and that seems to originate in RFC 5357) is a bit > > > > > unfortunate. "Immediately" or "as quickly as possible" are better. > > > > > > This odd turn of phrase resulted from many hours of discussion > > > dating back to TWAMP's development. We wear the scar proudly. > > > >Well, this is only a Comment, and you do not have to address it, but "as > >immediately as possible" is hogwash. It is a butchery of the > >language and means > >nothing! > > > >In fact, and as a general principle of writing standards, even "as quickly as > >possible" would be poor. The English would be fine, but it is a subjective > >statement against which conformance cannot be measured. > > Under typical protocol development circumstances, we could write a > real requirement: > The response MUST be prepared and sent on the wire in > But that's not the case here. Instead we have desire that the response > will be sent immediately, yet we understand that measurement systems will: > > - occasionally execute higher priority processes that delay the response > (processing routing updates comes to mind) > - carry 2 time stamps that allow the tester to determine if the response > was generated fast enough for the intended purpose > - serve purposes with greater or lesser need for immediacy > - either meet the variable needs for measurement immediacy or not, and > this is a judgement that can be made on each and every measurement packet > > Is it useful to explain some/all of this in the memo? I don't think so. I would just fix the text to say what you mean! I found key text in your mail to be: > allow the tester to determine if the response > was generated fast enough for the intended purpose Surely it is not enough to have the tester discard all response because they were not fast enough. Surely it is a good idea to give *meaningful* advice to the responder about how to respond so that the response is "fast enough for the intended purpose." Clearly "immediately" is not what is meant since it is allowed for this to be a background process. So perhaps the correct thing to do is warn the implementer of the responder about the expectations of the tester. Something like: A tester will normally find that a response that was not generated within 3 weeks is inadequate for the purposes of a realistic test and will discard such responses. Therefore, a responder needs to ensure that at least 67.2% of responses are generated within 1 hour of receiving the request. A responder that is unable to satisfy this requirement SHOULD log the fact so that an operator can adjust the load and priorities as necessary. A tester that finds that responses regularly are not generated in a timely fashion SHOULD notify the operator that the responder is compromising the tests, and SHOULD suspend sending requests to the responder since it is clearly overloaded. Ciao, Adrian From acmorton@att.com Mon Apr 9 06:44:41 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 EA6A421F8730; Mon, 9 Apr 2012 06:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, 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 IJJYQa84N+Ew; Mon, 9 Apr 2012 06:44:41 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 000F321F872D; Mon, 9 Apr 2012 06:44:40 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 8c7e28f4.0.217180.00-413.574673.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 09 Apr 2012 13:44:41 +0000 (UTC) X-MXL-Hash: 4f82e7c963cf6b99-077fb75ad523a386d37f952ba8e964db280c505b Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q39DieeX031645; Mon, 9 Apr 2012 09:44:40 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q39DiZEv031630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Apr 2012 09:44:36 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor); Mon, 9 Apr 2012 09:44:12 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q39DiBEW003302; Mon, 9 Apr 2012 09:44:12 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q39Di1hp002727; Mon, 9 Apr 2012 09:44:01 -0400 Message-Id: <201204091344.q39Di1hp002727@alpd052.aldc.att.com> Received: from acmt.att.com (dn135-16-251-71.dhcpn.ugn.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20120409134102gw1004or3be>; Mon, 9 Apr 2012 13:41:03 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Apr 2012 09:45:09 -0400 To: adrian@olddog.co.uk, "'Samuel Weiler'" , "'The IESG'" From: Al Morton In-Reply-To: <099701cd15b1$fc18c990$f44a5cb0$@olddog.co.uk> References: <20120406144445.4188.3196.idtracker@ietfa.amsl.com> <201204061553.q36FrBRV007699@alpd052.aldc.att.com> <07e001cd14e0$41b408c0$c51c1a40$@olddog.co.uk> <201204080018.q380I1VK007743@alpd052.aldc.att.com> <099701cd15b1$fc18c990$f44a5cb0$@olddog.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=dit6Jc5sqrAA:10 a=ZswZ2TFLv48A:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=qC9bzmnWH6raC_HTLtwA:9 a=x26R20QU5c1DXOaTW] X-AnalysisOut: [ZEA:7 a=CjuIK1q_8ugA:10 a=O1HhnQeX7jb0MREE:21 a=syYVULWv_0] X-AnalysisOut: [LOc0yk:21] Cc: ippm-chairs@tools.ietf.org, draft-ietf-ippm-rt-loss@tools.ietf.org, 'Dan Frost' , "'Murphy, Sandra'" , secdir@ietf.org Subject: Re: [secdir] Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT) 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, 09 Apr 2012 13:44:42 -0000 Hi Adrian, Thanks for clearing your DISCUSS. As always, the memo reads better owing to your efforts, and those of Dan and Sandra. Here's what I added in section 4.4, with supporting modifications elsewhere: We add the following guidance regarding the responder process to "send a Type-P packet back to the Src as quickly as possible". A response that was not generated within Tmax is inadequate for any realistic test, and the Src will discard such responses. A responder that serves typical round-trip loss testing (which is relevant to higher-layer application performance) SHOULD produce a response in 1 second or less. A responder that is unable to satisfy this requirement SHOULD log the fact so that an operator can adjust the load and priorities as necessary. Analysis of responder time-stamps [RFC5357] that finds responses are not generated in a timely fashion SHOULD result in operator notification, and the operator SHOULD suspend tests to the responder since it may be overloaded. Additional measurement considerations are described in Section 8, below. Ciao, Al At 02:04 PM 4/8/2012, Adrian Farrel wrote: >Hello Al, > > > > > Although IPPM has never formalized a strategy, we have been repeating > > > > security material in metrics RFCs. This allows new folks to read > > > > and improve the text, rather than be referred to a fixed reference. > > > > It seems to work. > > > > > >I can see how that would lead to the verbatim reproduction of > text. I have no > > >problem with that per se, but I worry that the process has > become formulaic > > >without any new consideration of security for the specific > document in hand. > > > > > >If you tell me that this is adequate for this document and no > refinement is > > >needed in this case, I will clear and let the Security ADs and > > >Directorate worry > > >about the security details. > > > > I think it is. We are essentially conducting a two-way version of RFC 2680 > > (one-way loss), so all the same considerations apply. We have exposure in > > two (possibly different) paths, but the threats are the same. > >OK. I cleared my Discuss. > > > > > > > 1. The phrase "as immediately as possible" that appears a couple of > > > > > > times in the text (and that seems to originate in RFC > 5357) is a bit > > > > > > unfortunate. "Immediately" or "as quickly as possible" are better. > > > > > > > > This odd turn of phrase resulted from many hours of discussion > > > > dating back to TWAMP's development. We wear the scar proudly. > > > > > >Well, this is only a Comment, and you do not have to address it, but "as > > >immediately as possible" is hogwash. It is a butchery of the > > >language and means > > >nothing! > > > > > >In fact, and as a general principle of writing standards, even > "as quickly as > > >possible" would be poor. The English would be fine, but it is a subjective > > >statement against which conformance cannot be measured. > > > > Under typical protocol development circumstances, we could write a > > real requirement: > > The response MUST be prepared and sent on the wire in > > > But that's not the case here. Instead we have desire that the response > > will be sent immediately, yet we understand that measurement systems will: > > > > - occasionally execute higher priority processes that delay the response > > (processing routing updates comes to mind) > > - carry 2 time stamps that allow the tester to determine if the response > > was generated fast enough for the intended purpose > > - serve purposes with greater or lesser need for immediacy > > - either meet the variable needs for measurement immediacy or not, and > > this is a judgement that can be made on each and every > measurement packet > > > > Is it useful to explain some/all of this in the memo? > >I don't think so. I would just fix the text to say what you mean! > >I found key text in your mail to be: > > > allow the tester to determine if the response > > was generated fast enough for the intended purpose > >Surely it is not enough to have the tester discard all response because they >were not fast enough. Surely it is a good idea to give *meaningful* advice to >the responder about how to respond so that the response is "fast >enough for the >intended purpose." > >Clearly "immediately" is not what is meant since it is allowed for >this to be a >background process. So perhaps the correct thing to do is warn the implementer >of the responder about the expectations of the tester. Something like: > >A tester will normally find that a response that was not generated within 3 >weeks is inadequate for the purposes of a realistic test and will discard such >responses. Therefore, a responder needs to ensure that at least 67.2% of >responses are generated within 1 hour of receiving the request. A >responder that >is unable to satisfy this requirement SHOULD log the fact so that an operator >can adjust the load and priorities as necessary. A tester that finds that >responses regularly are not generated in a timely fashion SHOULD notify the >operator that the responder is compromising the tests, and SHOULD suspend >sending requests to the responder since it is clearly overloaded. > > >Ciao, >Adrian From alexey.melnikov@isode.com Tue Apr 10 05:35:33 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 33BE821F85CF; Tue, 10 Apr 2012 05:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.135 X-Spam-Level: X-Spam-Status: No, score=-102.135 tagged_above=-999 required=5 tests=[AWL=0.464, 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 Mxg+tDZnm3MQ; Tue, 10 Apr 2012 05:35:32 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 019DE21F85CC; Tue, 10 Apr 2012 05:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334061330; d=isode.com; s=selector; i=@isode.com; bh=IqqdOZbULxsTWwwTPG1ukQ6gJnjxc0qr7Zf4aX18F3Q=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ghK12K98dlUnn8WowHUqG0cf6Vxlu9Mt0Exq4e5Qw7/n9usGMu9GaY++afuRZDpNSsG5/O jSexHGyaOoV6JQlU8wCXfNEjID/7NrP2hF2xRKKPe/DdAtdyfz7MSVVuIbMdmdyF5m/ayV IQ+i/tuj5loE2/fM13S7JTGEqJWK5fM=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 10 Apr 2012 13:35:30 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F842937.9050305@isode.com> Date: Tue, 10 Apr 2012 13:36:07 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: secdir@ietf.org, Jouni Korhonen , Teemu Savolainen MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IESG , Dan Wing Subject: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.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, 10 Apr 2012 12:35:33 -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. The document reviews possible solutions for the problem of allowing hosts and applications to learn if an IPv6 address is synthesized, which means a NAT64 is used to reach the IPv4 network or Internet. The document analyzes pros and cons of various approaches and also concludes with some recommendations about which approach is recommended. Overall I think the Security Considerations section is reasonable (see some minor comments below). I think it is reasonable for the document to point to RFC 6147 for DSN64 related Security Considerations. The document also talks about Man-in-the-middle and Denial-of-Service attacks caused by forging of information required for IPv6 synthesis from corresponding IPv4 addresses. Additionally, the document says: The DHCPv6 and RA based approaches are vulnerable for the forgery as the attacker may send forged RAs or act as a rogue DHCPv6 server (unless DHCPv6 authentication or SEND are used). I think some Informative references to relevant documents should be inserted here in order to help readers find relevant information. If the attacker is already able to modify and forge DNS responses (flags, addresses of know IPv4-only servers, records, etc), ability to influence local address synthesis is likely of low additional value. Also, a DNS-based mechanism is only as secure as the method used to configure the DNS server's IP addresses on the host. Therefore, if the host cannot trust e.g. DHCPv6 it cannot trust the DNS server learned via DHCPv6 either, unless the host has a way to authenticate all DNS responses. Maybe add an explicit DNSSEC reference here? One other possible issue that you should consider: 5.1.2. Analysis and discussion The CONs of the proposal are listed below: I don't know how much of an issue this is in a real world, but one thought: Can use of a well known IPv4-only FQDN be used for tracking applications/hosts which try to employ this algorithm? Such IPv4-only host might be an attractive target for compromise, if such information is valuable to an attacker. (This might also apply to other DNS methods.) Other comments (not really SecDir related): I found the Abstract to be quite hard to read. Maybe reword to use shorter/simpler sentences? 5.1.1. Solution description The Well-Known Name may be assigned by IANA or provided some third party, including application or operating system vendor. The IPv4 address corresponding to the Well-Known Name may be resolved via A query to Well-Known Name, assigned by IANA, or hard-coded. Is IANA already providing one of these? If not, why speculate about this, as there is no action for IANA specified in this document. From alexey.melnikov@isode.com Tue Apr 10 05:40: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 DCB1821F85D2 for ; Tue, 10 Apr 2012 05:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.181 X-Spam-Level: X-Spam-Status: No, score=-102.181 tagged_above=-999 required=5 tests=[AWL=0.418, 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 VHZDN+rZlMdE for ; Tue, 10 Apr 2012 05:40:10 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id E275A21F85D1 for ; Tue, 10 Apr 2012 05:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334061608; d=isode.com; s=selector; i=@isode.com; bh=5W48+2I3BYRwsr2Ga/GToQiXO53S24Qog8FPtYfQSqU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=wNpATuv/F6CViFPcStPRi3qlDpjT2m2EICrZg3yCC6jpF0HV5Z/EsVtdbEU386k/0YKhJ6 ACtNA+ujG5BCHDzztbZwNb4dfzCkfxPjqN3017weUsMi1zh/mrHzja4ze4DEMbASeL0EyP NbaSudlObW0fTnH6aJUxBNTI2YVa5pY=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 10 Apr 2012 13:40:08 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F842A4D.1000205@isode.com> Date: Tue, 10 Apr 2012 13:40:45 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: secdir@ietf.org References: <4F842937.9050305@isode.com> In-Reply-To: <4F842937.9050305@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.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, 10 Apr 2012 12:40:11 -0000 I have to admit that my knowledge of DNSSEC is lacking, so can somebody help me answer this question (which I didn't mention in my SecDir review): 5.2. EDNS0 option indicating AAAA Record synthesis and format 5.2.1. Solution description The third revision of "EDNS0 Option for Indicating AAAA Record Synthesis and Format", a draft document submitted to the behave WG in February 2011 by Jouni Korhonen and Teemu Savolainen, defined a new EDNS0 option [RFC2671], which contained 3 flag bits (called SY-bits). The EDNS0 option served as an implicit indication of the presence of DNS64 server and the NAT64 device. The EDNS0 option SY-bit values other than '000' and '111' explicitly told the NSP prefix length. Only the DNS64 server could insert the EDNS0 option and the required SY-bits combination into the synthesized AAAA Resource Record. Will DNS64 insertion of this option invalid DNSSEC signature? From afarrel@juniper.net Mon Apr 9 12:54: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 A557E21F87F4; Mon, 9 Apr 2012 12:54:06 -0700 (PDT) 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 GpVRBY-Pms9X; Mon, 9 Apr 2012 12:54:05 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 22B6E21F87EA; Mon, 9 Apr 2012 12:54:04 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q39JrtLE021935; Mon, 9 Apr 2012 20:53:59 +0100 Received: from 950129200 (AGrenoble-551-1-55-195.w86-197.abo.wanadoo.fr [86.197.14.195]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q39JrhAS021876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Apr 2012 20:53:50 +0100 From: "Adrian Farrel" To: "'Al Morton'" , , "'Samuel Weiler'" , "'The IESG'" References: <20120406144445.4188.3196.idtracker@ietfa.amsl.com> <201204061553.q36FrBRV007699@alpd052.aldc.att.com> <07e001cd14e0$41b408c0$c51c1a40$@olddog.co.uk> <201204080018.q380I1VK007743@alpd052.aldc.att.com> <099701cd15b1$fc18c990$f44a5cb0$@olddog.co.uk> <201204091344.q39Di1rK002725@alpd052.aldc.att.com> In-Reply-To: <201204091344.q39Di1rK002725@alpd052.aldc.att.com> Date: Mon, 9 Apr 2012 20:53:45 +0100 Message-ID: <0bea01cd168a$7ed8ae80$7c8a0b80$@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIbFLUL4L9fmeWqHCNmPVdbYjLawgGKVkKaAd6sRCwBimPGyQGdYPqzAfLYlEKVsqa4AA== Content-Language: en-gb X-Mailman-Approved-At: Tue, 10 Apr 2012 08:03:48 -0700 Cc: ippm-chairs@tools.ietf.org, draft-ietf-ippm-rt-loss@tools.ietf.org, 'Dan Frost' , "'Murphy, Sandra'" , secdir@ietf.org Subject: Re: [secdir] Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: afarrel@juniper.net List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 19:54:06 -0000 Al, As always, a reasoned response from you. A > -----Original Message----- > From: Al Morton [mailto:acmorton@att.com] > Sent: 09 April 2012 14:45 > To: adrian@olddog.co.uk; 'Samuel Weiler'; 'The IESG' > Cc: secdir@ietf.org; 'Murphy, Sandra'; 'Dan Frost'; ippm-chairs@tools.ietf.org; > draft-ietf-ippm-rt-loss@tools.ietf.org > Subject: RE: Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS > and COMMENT) > > Hi Adrian, > > Thanks for clearing your DISCUSS. As always, the memo reads better > owing to your efforts, and those of Dan and Sandra. > > Here's what I added in section 4.4, with supporting modifications > elsewhere: > > We add the following guidance regarding the responder process to > "send a Type-P packet back to the Src as quickly as possible". > > A response that was not generated within Tmax is inadequate for any > realistic test, and the Src will discard such responses. A responder > that serves typical round-trip loss testing (which is relevant to > higher-layer application performance) SHOULD produce a response in 1 > second or less. A responder that is unable to satisfy this > requirement SHOULD log the fact so that an operator > can adjust the load and priorities as necessary. Analysis of > responder time-stamps [RFC5357] that finds responses are not > generated in a timely fashion SHOULD result in operator notification, > and the operator SHOULD suspend tests to the responder since it may > be overloaded. Additional measurement considerations are described in > Section 8, below. > > Ciao, > Al > > > At 02:04 PM 4/8/2012, Adrian Farrel wrote: > >Hello Al, > > > > > > > Although IPPM has never formalized a strategy, we have been repeating > > > > > security material in metrics RFCs. This allows new folks to read > > > > > and improve the text, rather than be referred to a fixed reference. > > > > > It seems to work. > > > > > > > >I can see how that would lead to the verbatim reproduction of > > text. I have no > > > >problem with that per se, but I worry that the process has > > become formulaic > > > >without any new consideration of security for the specific > > document in hand. > > > > > > > >If you tell me that this is adequate for this document and no > > refinement is > > > >needed in this case, I will clear and let the Security ADs and > > > >Directorate worry > > > >about the security details. > > > > > > I think it is. We are essentially conducting a two-way version of RFC 2680 > > > (one-way loss), so all the same considerations apply. We have exposure in > > > two (possibly different) paths, but the threats are the same. > > > >OK. I cleared my Discuss. > > > > > > > > > 1. The phrase "as immediately as possible" that appears a couple of > > > > > > > times in the text (and that seems to originate in RFC > > 5357) is a bit > > > > > > > unfortunate. "Immediately" or "as quickly as possible" are better. > > > > > > > > > > This odd turn of phrase resulted from many hours of discussion > > > > > dating back to TWAMP's development. We wear the scar proudly. > > > > > > > >Well, this is only a Comment, and you do not have to address it, but "as > > > >immediately as possible" is hogwash. It is a butchery of the > > > >language and means > > > >nothing! > > > > > > > >In fact, and as a general principle of writing standards, even > > "as quickly as > > > >possible" would be poor. The English would be fine, but it is a subjective > > > >statement against which conformance cannot be measured. > > > > > > Under typical protocol development circumstances, we could write a > > > real requirement: > > > The response MUST be prepared and sent on the wire in > > > > > But that's not the case here. Instead we have desire that the response > > > will be sent immediately, yet we understand that measurement systems will: > > > > > > - occasionally execute higher priority processes that delay the response > > > (processing routing updates comes to mind) > > > - carry 2 time stamps that allow the tester to determine if the response > > > was generated fast enough for the intended purpose > > > - serve purposes with greater or lesser need for immediacy > > > - either meet the variable needs for measurement immediacy or not, and > > > this is a judgement that can be made on each and every > > measurement packet > > > > > > Is it useful to explain some/all of this in the memo? > > > >I don't think so. I would just fix the text to say what you mean! > > > >I found key text in your mail to be: > > > > > allow the tester to determine if the response > > > was generated fast enough for the intended purpose > > > >Surely it is not enough to have the tester discard all response because they > >were not fast enough. Surely it is a good idea to give *meaningful* advice to > >the responder about how to respond so that the response is "fast > >enough for the > >intended purpose." > > > >Clearly "immediately" is not what is meant since it is allowed for > >this to be a > >background process. So perhaps the correct thing to do is warn the > implementer > >of the responder about the expectations of the tester. Something like: > > > >A tester will normally find that a response that was not generated within 3 > >weeks is inadequate for the purposes of a realistic test and will discard such > >responses. Therefore, a responder needs to ensure that at least 67.2% of > >responses are generated within 1 hour of receiving the request. A > >responder that > >is unable to satisfy this requirement SHOULD log the fact so that an operator > >can adjust the load and priorities as necessary. A tester that finds that > >responses regularly are not generated in a timely fashion SHOULD notify the > >operator that the responder is compromising the tests, and SHOULD suspend > >sending requests to the responder since it is clearly overloaded. > > > > > >Ciao, > >Adrian From ekr@rtfm.com Tue Apr 10 08:11: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 A266511E810B for ; Tue, 10 Apr 2012 08:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.471 X-Spam-Level: X-Spam-Status: No, score=-100.471 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, TVD_SPACED_SUBJECT_WORD3=2.412, 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 lQqBhZqwpVMy for ; Tue, 10 Apr 2012 08:11:09 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AECD611E8108 for ; Tue, 10 Apr 2012 08:11:09 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3611598vbb.31 for ; Tue, 10 Apr 2012 08:11:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=No99xpMA9XmCmOJireNU8zJDSGjbQbFdiEimOyKOQ6s=; b=mVXNjElUywQczeS6qa/lWZ9gigFarB0Cppgj63k0UJyJ5fG/xjLnaFQVVnyzHbQpMD Pd6oj/wQMCKD3EBK0Ni7ml94G5GsH8+emke2Z2Vncp5feL7pmYJNHtrP/fTlpSLF9FJh N4QwFb5XYsiuOZzKL6ogyKdLS48R7JZNypusHWdt3nlcvlM3PMxyS/qa0kZM/Icjkp2m hEPN9fVP9SICXvFGF6kDd1bskBEIIm1SFKWUaQ+RJjyr0qmd72bfqfvXlXGdB9+jXq+z dpMqfC5EcELiCP8NC++QGtpUIDLXM8+L/t3m8W4oM8KSxp5RYmGqnzAvLhl6pp8s1/lA R6Uw== Received: by 10.52.69.100 with SMTP id d4mr5052337vdu.9.1334070669233; Tue, 10 Apr 2012 08:11:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Tue, 10 Apr 2012 08:10:28 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <5.1.0.14.2.20120408115646.03793228@efes.iucc.ac.il> References: <5.1.0.14.2.20120408115646.03793228@efes.iucc.ac.il> From: Eric Rescorla Date: Tue, 10 Apr 2012 08:10:28 -0700 Message-ID: To: Hank Nussbacher Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmuNbRiZ/orRAUVJqM5l0iO5QhCSTZ7oykTj17Ex4Il+N34eZCTxnyvQXgMiCV20/j6KC9O Cc: secdir@ietf.org Subject: Re: [secdir] WebRTC 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, 10 Apr 2012 15:11:10 -0000 On Sun, Apr 8, 2012 at 2:11 AM, Hank Nussbacher wrot= e: > Dear Security Area people, > > Quick intro: > > WebRTC http://www.webrtc.org/ is a free, open project that enables web > browsers with Real-Time Communications (RTC) capabilities via simple > Javascript APIs. =A0 It is supported by Google, Mozilla and Opera. =A0One= can > test it already in Chrome. Basically, it is meant to be a Skype replaceme= nt > technology (no app to download - all built-in to the browser). =A0But the= re > are many other ideas that can be used here with this technology. > > Now we get to the security part. =A0As stated here: > http://www.webrtc.org/blog/webrtcnowavailableinthechromedevchannel > one has to specifically enable "--enable-media-stream" in order to get it= to > work. That is now, but the future plan is to have this "on" by default in= FF > and Chrome by the end of 2012. > > So what does the IETF have to say: > > Security Considerations for RTC-Web > http://tools.ietf.org/html/draft-ietf-rtcweb-security-01 > which caused: > RTCWEB Security Architecture > http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-01 > Section 5.2: > "Clients MAY permit the formation of data channels without any direct use= r > approval." > > I can just see new apps all over the place using this technology opening = a > huge can of worms for data stealing from the PC running the app that did = NOT > ask permission for the formation of a data channel without the direct use= r's > permission. =A0This is similar in concept to ActiveX: > http://en.wikipedia.org/wiki/ActiveX > "This made the web "richer" but provoked objections (since such controls = ran > only on Windows) and security risks (especially given the lack of user > intervention). Microsoft subsequently introduced security measures to mak= e > browsing including ActiveX safer[6] . For example: > > =A0 =A0digital signing of installation packages (Cabinet files and execut= ables) > =A0 =A0controls must explicitly declare themselves safe for scripting > =A0 =A0increasingly stringent default security settings > =A0 =A0Internet Explorer maintains a blacklist of bad controls" > > Microsoft didn't envision the security issues of a "lack of user > intervention" and it took them 3 years to add the appropriate knobs to ma= ke > ActiveX more secure. > > I am not involved in WebRTC or the IETF group - I only found out about th= is > incidentally. =A0I raise this issue to you guys and leave it the Security= Area > to decide whether section 5 needs to be changed or not. FWIW, I am the person who wrote the text in question and though Hank doesn't say so he privately contacted me and the RTCWEB chairs, and what I told him is that the specific feature he is complaining about, the data channel, is simply a direct channel between the browsers in question. Since that channel is created and controlled by JavaScript under control of the Web site, that JS can just as easily tunnel data through the site via WebSockets/XHR, etc. I.e., this is just an optimization that allows a direct connection. Thus, requesting user consent for the use of this feature isn't really helpful, since this feature doesn't introduce new risks of data exfiltration. [0] Obviously, I'd be more than willing to listen to any security analysis that indicated that this was wrong, but the handwaving above about ActiveX doesn't really add anything as far as I can tell. -Ekr [0] Note that there are risks in terms of cross-protocol attacks, and thus we require a handshake to prevent them; see http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-01#section-5.3 Similarly, we require user consent prior to transmitting data derived from the camera and microphone because that data is not otherwise available prior to these features. http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-01#section-5.2 From dharkins@lounge.org Tue Apr 10 16:59: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 01DF711E811A; Tue, 10 Apr 2012 16:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.336 X-Spam-Level: X-Spam-Status: No, score=-5.336 tagged_above=-999 required=5 tests=[AWL=0.929, 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 Sz5adrNtT173; Tue, 10 Apr 2012 16:59:43 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 893E811E810C; Tue, 10 Apr 2012 16:59:43 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 4E6071022404A; Tue, 10 Apr 2012 16:59:43 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 10 Apr 2012 16:59:43 -0700 (PDT) Message-ID: <8b9118710c0f73581afe12789d16ae07.squirrel@www.trepanning.net> Date: Tue, 10 Apr 2012 16:59:43 -0700 (PDT) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ipfix-flow-selection-tech.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-ipfix-flow-selection-tech 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, 10 Apr 2012 23:59:44 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes techniques to select flows which are sets of packets with some common characteristics. The authors have accurately identified what constitutes an attack-- an adversary having the ability to influence flow selection-- and the Security Considerations give a couple examples of this. They seem fine. There is reference to a paper "[GoRe07]" which does not appear in the References and seems to give advice that I think is wrong: use a strong cryptographically strong random number generator to thwart an attack in which parameters of time-based sampling are discovered to predict the selection decision. This attack can be thwarted by using a value that the adversary cannot predict (sort of like an IV for CBC mode) instead of a cryptographically strong random number. That leaves the random number pool to applications that really need it (like a key exchange that does a Diffie-Hellman). I suggest removing the reference to the un-referenced paper and mention a weaker requirement to thwart that attack. regards, Dan. From bew@cisco.com Tue Apr 10 20:11:51 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 3B2EC21F84EB; Tue, 10 Apr 2012 20:11:51 -0700 (PDT) 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 UyJJdlsfb+sZ; Tue, 10 Apr 2012 20:11:50 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 95B9121F84DC; Tue, 10 Apr 2012 20:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=3353; q=dns/txt; s=iport; t=1334113910; x=1335323510; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=NZIITSJy5FdzCUhiVr7bSez9KU71cSoGDWOtl3CZYQc=; b=BDfku6AdlCrV+XAqQchCBfka94StOj3dOl4lq975vIXPjHat4zgceB1f AmE2rhwi6x3Wf8DqrDoqs7Eyl7WM8o/M/SUNdkWqJ+kQCXorPDjs02EJM 9ezm5LZHaCswRxY5L74Tf7DLfKciu84KRp2QJJlyXx71meErzUHGNcVr0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAKf1hE+rRDoJ/2dsb2JhbABFuT+BB4IiASc/gT4BNIdrmkmgI5BbYwSIWo0Sjk2BaYMH X-IronPort-AV: E=Sophos;i="4.75,402,1330905600"; d="scan'208";a="37385330" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 11 Apr 2012 03:11:50 +0000 Received: from stealth-10-32-244-214.cisco.com (stealth-10-32-244-214.cisco.com [10.32.244.214]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3B3BnxA011023; Wed, 11 Apr 2012 03:11:50 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Apr 2012 20:11:49 -0700 Message-Id: To: secdir@ietf.org, The IESG Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: draft-jivsov-openpgp-ecc.all@tools.ietf.org Subject: [secdir] Secdir review of draft-jivsov-openpgp-ecc-12 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, 11 Apr 2012 03:11:51 -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 adds support for the use of ECC as an authentication = method to OpenPGP. Two public key algorithms are supported: ECDSA and = ECDH. The document describes the supported ECC curves, how the public = key is represented in OpenPGP, and encodings for public and private = keys. For ECDH, it also specifies the KDF for creating a KEK from from = ECDH shared secret and the method for key wrapping a session key that is = used to protect data traffic. This seems to be standard OpenPGP practice = for DH public key algorithms. A stated goal is to conform to Suite B; as = far as I can tell this is achieved. I have the following comments/questions. Section 5: A reference to ECDSA is given for both RFC 6090 and [SEC1]. = The definition in RFC 6090 supersedes [SEC1], and it is preferable to = reference just the RFC. I suggest removing "and in [SEC1]". Section 6: RFC 6090 uses the notation "(@,@)" for the point at infinity = ("point O"), which would be better to use. This seems to be the only = term in this section specific to [SEC1], so making this change should = enable you to change your reference to RFC 6090 here too. Section 6: The reasoning for passing the point at infinity isn't clearly = defined. Can you explain when this would be done? Section 7: The use of "P" for parameters is confusing, since P was just = used in Section 6 to mean "Point". It would be helpful if it were = "Params" or something other name. Section 7: It would be helpful to the reader to explain that setting ZB = to "x" is using the "compact output" of the shared secret (see RFC 6090 = Section 4.2). Section 8: Are the "5 variable-length and fixed-length fields" meant to = be OtherInfo as defined in SP800-56A? If so, mentioning this would make = it easier on the reader. Section 8: This says "The key wrapping method is based on [RFC3394]". I = hope is it actually "conforming to [RFC3394]", which would be a clearer = statement. Is that so? If not, why? Section 8: This section gives an example of encoding a 32-octet ASE-256 = session key into 40 octets, which seems to be the input to the key wrap. = My understanding of the AES key wrap defined in RFC 3394 is that the key = input should be just 32 octets, where it is prepended with an 8 octet = IV. This doesn't match your example though. Can this be made to match = the inputs in the RFC? For example, see the example in Section 4.6 of = RFC 3394. (This would also remove the need for padding an AES-256 key, = and reduce the padding for the two smaller sizes.) Section 10: The statement "No changes in the format are needed for = ECDSA" seems true, but isn't it necessary to describe the Algorithm = Specific Fields for ECDSA? Is this actually defined in Section 9? Section 13: The table of equivalent algorithm strengths seems to match = claims in SP800-57-Part1-Rev3-May2011. It would be helpful to reference = this document here as a source for the information. Thanks, Brian= From leifj@sunet.se Wed Apr 11 01:14:35 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 A912D21F850C; Wed, 11 Apr 2012 01:14:35 -0700 (PDT) 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 doV+0IxtTRlK; Wed, 11 Apr 2012 01:14:35 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 239F321F86EF; Wed, 11 Apr 2012 01:14:33 -0700 (PDT) Received: from [109.105.104.178] (dhcp44.se-tug.nordu.net [109.105.104.178] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q3B8ERjd009780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 10:14:30 +0200 (CEST) Message-ID: <4F853D62.1090204@sunet.se> Date: Wed, 11 Apr 2012 10:14:26 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Leif Johansson , draft-ietf-netmod-smi-yang.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-ietf-netmod-smi-yang-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: Wed, 11 Apr 2012 08:14:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. The document specifies a translation between SMIv2 (and by reference to RFC 3584, SMIv1) and YANG. YANG is the information model language used in NETCONF. This draft is outside my subject-matter expertise but the core security issue seems to be around translation of the SMIv2 MAX-ACCESS macro to YANG. Since YANG doesn't define any corresponding element an extension to YANG is defined. However there doesn't seem to be any requirement to implement that extension. The security considerations section refers the reader to the security considerations sections for YANG, NETCONF, SMI etc but claims that "The translation itself has no security impact on the Internet.". I would have liked to see a clear normative statement to the effect that if you relied on MAX-ACCESS in the SMIv2 version of a MIB then you MUST implement the YANG extension for SMI and that the NETCONF implementation used MUST respect the resulting smiv2:max-access statements. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+FPV8ACgkQ8Jx8FtbMZnfIMgCeOzipy2p+7IaJvAdqrrAGw4JV 0pIAn3TEZK/JLl9kICv2KliJcGnQZ37n =/RIl -----END PGP SIGNATURE----- From j.schoenwaelder@jacobs-university.de Wed Apr 11 02:15:57 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 9F3B621F861B; Wed, 11 Apr 2012 02:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.12 X-Spam-Level: X-Spam-Status: No, score=-103.12 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 AAMFgqT6nqPW; Wed, 11 Apr 2012 02:15:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4F421F8610; Wed, 11 Apr 2012 02:15:53 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 400DB20BF0; Wed, 11 Apr 2012 11:15:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QQOmYjOBvp4f; Wed, 11 Apr 2012 11:15:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9433720BE6; Wed, 11 Apr 2012 11:15:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 401C81E5D39E; Wed, 11 Apr 2012 11:15:52 +0200 (CEST) Date: Wed, 11 Apr 2012 11:15:51 +0200 From: Juergen Schoenwaelder To: Leif Johansson Message-ID: <20120411091551.GA26732@elstar.local> Mail-Followup-To: Leif Johansson , Leif Johansson , draft-ietf-netmod-smi-yang.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" References: <4F853D62.1090204@sunet.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F853D62.1090204@sunet.se> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: draft-ietf-netmod-smi-yang.all@tools.ietf.org, "iesg@ietf.org" , Leif Johansson , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-netmod-smi-yang-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 09:15:57 -0000 On Wed, Apr 11, 2012 at 10:14:26AM +0200, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > 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. > > The document specifies a translation between SMIv2 (and by reference > to RFC 3584, SMIv1) and YANG. YANG is the information model language > used in NETCONF. > > This draft is outside my subject-matter expertise but the core > security issue seems to be around translation of the SMIv2 MAX-ACCESS > macro to YANG. Since YANG doesn't define any corresponding element > an extension to YANG is defined. > > However there doesn't seem to be any requirement to implement that > extension. The security considerations section refers the reader to > the security considerations sections for YANG, NETCONF, SMI etc but > claims that "The translation itself has no security impact on the > Internet.". > > I would have liked to see a clear normative statement to the effect > that if you relied on MAX-ACCESS in the SMIv2 version of a MIB then > you MUST implement the YANG extension for SMI and that the NETCONF > implementation used MUST respect the resulting smiv2:max-access > statements. Hi, the MAX-ACCESS in the SMIv2 really has nothing to do with access control. See section 7.3 of RFC 2578 for the details. Also note that the SMiv2 to YANG mapping is readonly, that is even if the SMIv2 MAX-ACCESS is "read-write" or "read-create", the corresponsing YANG leaf is read-only. Note that access control in the SNMP world is handled by VACM (RFC 3415) and in the NETCONF world by NACM (RFC 6536). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From leifj@sunet.se Wed Apr 11 02:27: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 B937F21F86F2; Wed, 11 Apr 2012 02:27:19 -0700 (PDT) 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=[AWL=0.000, 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 LT+oTsYggj5G; Wed, 11 Apr 2012 02:27:19 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id E083621F86E2; Wed, 11 Apr 2012 02:27:18 -0700 (PDT) Received: from [109.105.104.178] (dhcp44.se-tug.nordu.net [109.105.104.178] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q3B9RCS4022687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 11:27:16 +0200 (CEST) Message-ID: <4F854E70.4060900@sunet.se> Date: Wed, 11 Apr 2012 11:27:12 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Leif Johansson , draft-ietf-netmod-smi-yang.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" References: <4F853D62.1090204@sunet.se> <20120411091551.GA26732@elstar.local> In-Reply-To: <20120411091551.GA26732@elstar.local> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] secdir review of draft-ietf-netmod-smi-yang-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: Wed, 11 Apr 2012 09:27:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/11/2012 11:15 AM, Juergen Schoenwaelder wrote: > On Wed, Apr 11, 2012 at 10:14:26AM +0200, Leif Johansson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> >> 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. >> >> The document specifies a translation between SMIv2 (and by >> reference to RFC 3584, SMIv1) and YANG. YANG is the information >> model language used in NETCONF. >> >> This draft is outside my subject-matter expertise but the core >> security issue seems to be around translation of the SMIv2 >> MAX-ACCESS macro to YANG. Since YANG doesn't define any >> corresponding element an extension to YANG is defined. >> >> However there doesn't seem to be any requirement to implement >> that extension. The security considerations section refers the >> reader to the security considerations sections for YANG, NETCONF, >> SMI etc but claims that "The translation itself has no security >> impact on the Internet.". >> >> I would have liked to see a clear normative statement to the >> effect that if you relied on MAX-ACCESS in the SMIv2 version of a >> MIB then you MUST implement the YANG extension for SMI and that >> the NETCONF implementation used MUST respect the resulting >> smiv2:max-access statements. > > Hi, > > the MAX-ACCESS in the SMIv2 really has nothing to do with access > control. See section 7.3 of RFC 2578 for the details. Also note > that the SMiv2 to YANG mapping is readonly, that is even if the > SMIv2 MAX-ACCESS is "read-write" or "read-create", the > corresponsing YANG leaf is read-only. > > Note that access control in the SNMP world is handled by VACM (RFC > 3415) and in the NETCONF world by NACM (RFC 6536). > > /js > As I said this is somewhat outside my comfort-zone but I don't understand how MAX-ACCESS isn't related to access restrictions given the security considerations section of rfc 3584. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+FTnAACgkQ8Jx8FtbMZndR3wCgkVwon5aZb8HOCEW5fUWsy97C 4lgAn3VfT6Xw+3T48GUuLgffHF7GlEo9 =LZeH -----END PGP SIGNATURE----- From j.schoenwaelder@jacobs-university.de Wed Apr 11 02:42:35 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 500EB21F86E8; Wed, 11 Apr 2012 02:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.127 X-Spam-Level: X-Spam-Status: No, score=-103.127 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 WUXzV98vbmwI; Wed, 11 Apr 2012 02:42:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2329021F86D3; Wed, 11 Apr 2012 02:42:34 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A02820B6C; Wed, 11 Apr 2012 11:42:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CTI2hF9TcpgH; Wed, 11 Apr 2012 11:42:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 000B220AFA; Wed, 11 Apr 2012 11:42:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E91C41E5D612; Wed, 11 Apr 2012 11:42:34 +0200 (CEST) Date: Wed, 11 Apr 2012 11:42:34 +0200 From: Juergen Schoenwaelder To: Leif Johansson Message-ID: <20120411094234.GA26959@elstar.local> Mail-Followup-To: Leif Johansson , Leif Johansson , draft-ietf-netmod-smi-yang.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" References: <4F853D62.1090204@sunet.se> <20120411091551.GA26732@elstar.local> <4F854E70.4060900@sunet.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F854E70.4060900@sunet.se> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: draft-ietf-netmod-smi-yang.all@tools.ietf.org, "iesg@ietf.org" , Leif Johansson , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-netmod-smi-yang-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 09:42:35 -0000 On Wed, Apr 11, 2012 at 11:27:12AM +0200, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/11/2012 11:15 AM, Juergen Schoenwaelder wrote: > > On Wed, Apr 11, 2012 at 10:14:26AM +0200, Leif Johansson wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >> > >> > >> 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. > >> > >> The document specifies a translation between SMIv2 (and by > >> reference to RFC 3584, SMIv1) and YANG. YANG is the information > >> model language used in NETCONF. > >> > >> This draft is outside my subject-matter expertise but the core > >> security issue seems to be around translation of the SMIv2 > >> MAX-ACCESS macro to YANG. Since YANG doesn't define any > >> corresponding element an extension to YANG is defined. > >> > >> However there doesn't seem to be any requirement to implement > >> that extension. The security considerations section refers the > >> reader to the security considerations sections for YANG, NETCONF, > >> SMI etc but claims that "The translation itself has no security > >> impact on the Internet.". > >> > >> I would have liked to see a clear normative statement to the > >> effect that if you relied on MAX-ACCESS in the SMIv2 version of a > >> MIB then you MUST implement the YANG extension for SMI and that > >> the NETCONF implementation used MUST respect the resulting > >> smiv2:max-access statements. > > > > Hi, > > > > the MAX-ACCESS in the SMIv2 really has nothing to do with access > > control. See section 7.3 of RFC 2578 for the details. Also note > > that the SMiv2 to YANG mapping is readonly, that is even if the > > SMIv2 MAX-ACCESS is "read-write" or "read-create", the > > corresponsing YANG leaf is read-only. > > > > Note that access control in the SNMP world is handled by VACM (RFC > > 3415) and in the NETCONF world by NACM (RFC 6536). > > > > /js > > > > As I said this is somewhat outside my comfort-zone but I don't > understand how MAX-ACCESS isn't related to access restrictions > given the security considerations section of rfc 3584. The MAX-ACCESS documents whether an object from a data modeling perspective is in principle writable/creatable or always readonly. In other words, it documents that maximum possible access to an object from a data modeling perspective. There are objects (e.g., counters) that are inherently readonly and hence have a MAX-ACCESS readonly. Other objects may in principle be writable from a modeling perspective. There are two ways to constrain a MAX-ACCESS in the SNMP world: * First, implementation may implement writable objects as readonly objects. Sometimes there are specific conformance definitions that specifically allow for such implementations. Sometimes implementations do this on their own choice, ideally documented in so call AGENT-CAPABILITIES (a machine readable documentation of deviations from a conformance definition). * Second, an access control model (with a collection of access control rules) is used to determine at runtime whether the MAX-ACCESS should be restricted. The MIB security considerations boilerplate commonly used in MIB documents requires that MIB authors document which objects may be criticial to protect. This is essentially advise to people deploying MIB modules on how to construct their runtime access control rules. Coming back to the SMIv2 to YANG translation, it turned out that for various other technical reasons, the translation to YANG is readonly (or config false as we say in the YANG community). Hence, even if an SMIv2 object has a MAX-ACCESS of readwrite, the corresponding YANG leaf will be config false. Hence, the current text in the security considerations says: 13. Security Considerations This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only access to data objects defined in SMIv2 MIB modules via NETCONF. The translation itself has no security impact on the Internet. Does this help? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jouni.nospam@gmail.com Wed Apr 11 03:00:23 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 900A621F8528; Wed, 11 Apr 2012 03:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 sge9Y5CTDva9; Wed, 11 Apr 2012 03:00:22 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9594221F8526; Wed, 11 Apr 2012 03:00:22 -0700 (PDT) Received: by iazz13 with SMTP id z13so1271941iaz.31 for ; Wed, 11 Apr 2012 03:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=mYE0+mYhIw3KjPxBNX8N981br6e4aFP13hq4qHZacX8=; b=GUesUxI9L1LAFSuL+UsRgtuV6GZBoWZUHGoYLnFgs3Esuxfkv96LkQSxnRkCp3sbhs mnvR47EtHCLlvDohiEiwTGmTBcmvMcCmsOvTxuMeSCsTDyR1jn1oP3BmstqjjciiOWxK jq//CEcGji45Y80JgosBoQrm1X7m5RFCPLrsu4pVCT4M2+6s6Z2smy9k+KZ+5kpyDs6c WgYDEKDnNuEDwGGzvU7nn519u7NpOSVypDut1ACEP2i/ivjD0KaG5s+0KLPPZ5x35Nfo Uyns09TwNklnCajQxNDT9xzu2fiPET/VGA7lcra9wwjWYkEenCZysq+9HLKKtVKWl7ww Jk+Q== Received: by 10.50.168.8 with SMTP id zs8mr4977283igb.37.1334138422246; Wed, 11 Apr 2012 03:00:22 -0700 (PDT) Received: from [10.255.130.135] ([192.100.123.77]) by mx.google.com with ESMTPS id us6sm24456001igc.9.2012.04.11.03.00.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Apr 2012 03:00:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4F842937.9050305@isode.com> Date: Wed, 11 Apr 2012 13:00:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F842937.9050305@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: Teemu Savolainen , IESG , Dan Wing , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.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, 11 Apr 2012 10:00:23 -0000 Hi, Thank you for the review. See my comments inline. On Apr 10, 2012, at 3:36 PM, Alexey Melnikov wrote: > Hi, >=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 > The document reviews possible solutions for the problem of allowing = hosts and applications to learn if an IPv6 address is synthesized, which = means a NAT64 is used to reach the IPv4 network or Internet. The = document analyzes pros and cons of various approaches and also concludes = with some recommendations about which approach is recommended. >=20 > Overall I think the Security Considerations section is reasonable (see = some minor comments below). I think it is reasonable for the document to = point to RFC 6147 for DSN64 related Security Considerations. The = document also talks about Man-in-the-middle and Denial-of-Service = attacks caused by forging of information required for IPv6 synthesis = from corresponding IPv4 addresses. Good point. We'll add the reference. >=20 > Additionally, the document says: >=20 > The DHCPv6 and RA > based approaches are vulnerable for the forgery as the attacker may > send forged RAs or act as a rogue DHCPv6 server (unless DHCPv6 > authentication or SEND are used). >=20 > I think some Informative references to relevant documents should be = inserted here in order to help readers find relevant information. Will add references to RFC3315 and RFC3971. >=20 > If the attacker is already able to > modify and forge DNS responses (flags, addresses of know IPv4-only > servers, records, etc), ability to influence local address synthesis > is likely of low additional value. Also, a DNS-based mechanism is > only as secure as the method used to configure the DNS server's IP > addresses on the host. Therefore, if the host cannot trust e.g. > DHCPv6 it cannot trust the DNS server learned via DHCPv6 either, > unless the host has a way to authenticate all DNS responses. >=20 > Maybe add an explicit DNSSEC reference here? Will add a reference to RFC4033. >=20 >=20 > One other possible issue that you should consider: >=20 > 5.1.2. Analysis and discussion >=20 > The CONs of the proposal are listed below: >=20 > I don't know how much of an issue this is in a real world, but one = thought: >=20 > Can use of a well known IPv4-only FQDN be used for tracking = applications/hosts which try to employ this algorithm? Such IPv4-only = host might be an attractive target for compromise, if such information = is valuable to an attacker. I guess it could be possible in theory.. if we assume the DNS server hosting the IPv4-only FQDN would be hostile, which is not a realistic assumption imho. >=20 > (This might also apply to other DNS methods.) >=20 >=20 > Other comments (not really SecDir related): >=20 > I found the Abstract to be quite hard to read. Maybe reword to use = shorter/simpler sentences? Ok. We'll look into it. >=20 > 5.1.1. Solution description >=20 > The Well-Known Name may be assigned by IANA or provided some third > party, including application or operating system vendor. The IPv4 > address corresponding to the Well-Known Name may be resolved via A > query to Well-Known Name, assigned by IANA, or hard-coded. >=20 > Is IANA already providing one of these? If not, why speculate about = this, as there is no action for IANA specified in this document. IANA is going to provide one. I think it is good to have this part still in the document. It was a non-trivial issue who is going to host the well-known name. - Jouni >=20 From leifj@sunet.se Wed Apr 11 03:08: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 AA7B811E8086; Wed, 11 Apr 2012 03:08:48 -0700 (PDT) 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 0q3GeMaBsH6P; Wed, 11 Apr 2012 03:08:48 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 83C6621F866A; Wed, 11 Apr 2012 03:08:43 -0700 (PDT) Received: from [109.105.104.178] (dhcp44.se-tug.nordu.net [109.105.104.178] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q3BA8b4Z017721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 12:08:40 +0200 (CEST) Message-ID: <4F855825.1090409@sunet.se> Date: Wed, 11 Apr 2012 12:08:37 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Leif Johansson , draft-ietf-netmod-smi-yang.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" References: <4F853D62.1090204@sunet.se> <20120411091551.GA26732@elstar.local> <4F854E70.4060900@sunet.se> <20120411094234.GA26959@elstar.local> In-Reply-To: <20120411094234.GA26959@elstar.local> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] secdir review of draft-ietf-netmod-smi-yang-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: Wed, 11 Apr 2012 10:08:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/11/2012 11:42 AM, Juergen Schoenwaelder wrote: > On Wed, Apr 11, 2012 at 11:27:12AM +0200, Leif Johansson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 04/11/2012 11:15 AM, Juergen Schoenwaelder wrote: >>> On Wed, Apr 11, 2012 at 10:14:26AM +0200, Leif Johansson >>> wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> >>>> >>>> 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. >>>> >>>> The document specifies a translation between SMIv2 (and by >>>> reference to RFC 3584, SMIv1) and YANG. YANG is the >>>> information model language used in NETCONF. >>>> >>>> This draft is outside my subject-matter expertise but the >>>> core security issue seems to be around translation of the >>>> SMIv2 MAX-ACCESS macro to YANG. Since YANG doesn't define >>>> any corresponding element an extension to YANG is defined. >>>> >>>> However there doesn't seem to be any requirement to >>>> implement that extension. The security considerations section >>>> refers the reader to the security considerations sections for >>>> YANG, NETCONF, SMI etc but claims that "The translation >>>> itself has no security impact on the Internet.". >>>> >>>> I would have liked to see a clear normative statement to the >>>> effect that if you relied on MAX-ACCESS in the SMIv2 version >>>> of a MIB then you MUST implement the YANG extension for SMI >>>> and that the NETCONF implementation used MUST respect the >>>> resulting smiv2:max-access statements. >>> >>> Hi, >>> >>> the MAX-ACCESS in the SMIv2 really has nothing to do with >>> access control. See section 7.3 of RFC 2578 for the details. >>> Also note that the SMiv2 to YANG mapping is readonly, that is >>> even if the SMIv2 MAX-ACCESS is "read-write" or "read-create", >>> the corresponsing YANG leaf is read-only. >>> >>> Note that access control in the SNMP world is handled by VACM >>> (RFC 3415) and in the NETCONF world by NACM (RFC 6536). >>> >>> /js >>> >> >> As I said this is somewhat outside my comfort-zone but I don't >> understand how MAX-ACCESS isn't related to access restrictions >> given the security considerations section of rfc 3584. > > The MAX-ACCESS documents whether an object from a data modeling > perspective is in principle writable/creatable or always readonly. > In other words, it documents that maximum possible access to an > object from a data modeling perspective. There are objects (e.g., > counters) that are inherently readonly and hence have a MAX-ACCESS > readonly. Other objects may in principle be writable from a > modeling perspective. There are two ways to constrain a MAX-ACCESS > in the SNMP world: > > * First, implementation may implement writable objects as readonly > objects. Sometimes there are specific conformance definitions > that specifically allow for such implementations. Sometimes > implementations do this on their own choice, ideally documented in > so call AGENT-CAPABILITIES (a machine readable documentation of > deviations from a conformance definition). > > * Second, an access control model (with a collection of access > control rules) is used to determine at runtime whether the > MAX-ACCESS should be restricted. > > The MIB security considerations boilerplate commonly used in MIB > documents requires that MIB authors document which objects may be > criticial to protect. This is essentially advise to people > deploying MIB modules on how to construct their runtime access > control rules. > > Coming back to the SMIv2 to YANG translation, it turned out that > for various other technical reasons, the translation to YANG is > readonly (or config false as we say in the YANG community). Hence, > even if an SMIv2 object has a MAX-ACCESS of readwrite, the > corresponding YANG leaf will be config false. Hence, the current > text in the security considerations says: > > 13. Security Considerations > > This document defines a translation of SMIv2 MIB modules into YANG > modules, enabling read-only access to data objects defined in > SMIv2 MIB modules via NETCONF. The translation itself has no > security impact on the Internet. > > Does this help? > > /js > It helps me right now but how do we help future readers? I jumped to this conclusion just by tracing some of the security considerations sections. Perhaps you should add a a condensed version of your excellent explanation to the security considerations? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+FWCUACgkQ8Jx8FtbMZncLkgCfapCD+u5r5atcyG1v7b0fTNca FVMAn0V2cLrHYjhqRMTMzjnsNII1DPzn =2P16 -----END PGP SIGNATURE----- From ietfdbh@comcast.net Wed Apr 11 04:17: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 D870611E8095 for ; Wed, 11 Apr 2012 04:17:09 -0700 (PDT) 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 oSRddpUXANWh for ; Wed, 11 Apr 2012 04:17:09 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 005B211E808F for ; Wed, 11 Apr 2012 04:17:08 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta01.westchester.pa.mail.comcast.net with comcast id wbGc1i0070vyq2s51bH9Ej; Wed, 11 Apr 2012 11:17:09 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta05.westchester.pa.mail.comcast.net with comcast id wbGs1i0063Ecudz3RbGs2X; Wed, 11 Apr 2012 11:17:09 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 11 Apr 2012 07:16:49 -0400 From: David Harrington To: jouni korhonen , Alexey Melnikov Message-ID: Thread-Topic: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.txt In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: secdir@ietf.org, IESG , Dan Wing , Teemu Savolainen Subject: Re: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.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, 11 Apr 2012 11:17:10 -0000 Hi, For IANA to provide an assignment, a document usually needs to request such an assignment. Is this document requesting the assignment, or is another document doing so? If this document wants to mention such an IANA assignment, it should also provide a reference to the document that requests IANA to do so. -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 4/11/12 6:00 AM, "jouni korhonen" wrote: >Hi, > >Thank you for the review. See my comments inline. > >On Apr 10, 2012, at 3:36 PM, Alexey Melnikov 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. >> >> The document reviews possible solutions for the problem of allowing >>hosts and applications to learn if an IPv6 address is synthesized, which >>means a NAT64 is used to reach the IPv4 network or Internet. The >>document analyzes pros and cons of various approaches and also concludes >>with some recommendations about which approach is recommended. >> >> Overall I think the Security Considerations section is reasonable (see >>some minor comments below). I think it is reasonable for the document to >>point to RFC 6147 for DSN64 related Security Considerations. The >>document also talks about Man-in-the-middle and Denial-of-Service >>attacks caused by forging of information required for IPv6 synthesis >>from corresponding IPv4 addresses. > >Good point. We'll add the reference. > > >> >> Additionally, the document says: >> >> The DHCPv6 and RA >> based approaches are vulnerable for the forgery as the attacker may >> send forged RAs or act as a rogue DHCPv6 server (unless DHCPv6 >> authentication or SEND are used). >> >> I think some Informative references to relevant documents should be >>inserted here in order to help readers find relevant information. > >Will add references to RFC3315 and RFC3971. > >> >> If the attacker is already able to >> modify and forge DNS responses (flags, addresses of know IPv4-only >> servers, records, etc), ability to influence local address synthesis >> is likely of low additional value. Also, a DNS-based mechanism is >> only as secure as the method used to configure the DNS server's IP >> addresses on the host. Therefore, if the host cannot trust e.g. >> DHCPv6 it cannot trust the DNS server learned via DHCPv6 either, >> unless the host has a way to authenticate all DNS responses. >> >> Maybe add an explicit DNSSEC reference here? > >Will add a reference to RFC4033. > > >> >> >> One other possible issue that you should consider: >> >> 5.1.2. Analysis and discussion >> >> The CONs of the proposal are listed below: >> >> I don't know how much of an issue this is in a real world, but one >>thought: >> >> Can use of a well known IPv4-only FQDN be used for tracking >>applications/hosts which try to employ this algorithm? Such IPv4-only >>host might be an attractive target for compromise, if such information >>is valuable to an attacker. > >I guess it could be possible in theory.. if we assume the >DNS server hosting the IPv4-only FQDN would be hostile, >which is not a realistic assumption imho. > > >> >> (This might also apply to other DNS methods.) >> >> >> Other comments (not really SecDir related): >> >> I found the Abstract to be quite hard to read. Maybe reword to use >>shorter/simpler sentences? > >Ok. We'll look into it. > > >> >> 5.1.1. Solution description >> >> The Well-Known Name may be assigned by IANA or provided some third >> party, including application or operating system vendor. The IPv4 >> address corresponding to the Well-Known Name may be resolved via A >> query to Well-Known Name, assigned by IANA, or hard-coded. >> >> Is IANA already providing one of these? If not, why speculate about >>this, as there is no action for IANA specified in this document. > >IANA is going to provide one. I think it is good to have >this part still in the document. It was a non-trivial issue >who is going to host the well-known name. > >- Jouni > >> > >_______________________________________________ >secdir mailing list >secdir@ietf.org >https://www.ietf.org/mailman/listinfo/secdir >wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From jouni.nospam@gmail.com Wed Apr 11 05:21: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 BA7C611E808F; Wed, 11 Apr 2012 05:21:16 -0700 (PDT) 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 ekPTo7dtsKgx; Wed, 11 Apr 2012 05:21:16 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 574DD21F8526; Wed, 11 Apr 2012 05:21:15 -0700 (PDT) Received: by lbok13 with SMTP id k13so704810lbo.31 for ; Wed, 11 Apr 2012 05:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=TH6rQXPxSyTF2ifnDNkI/z6uyotD5XLKjugPTV6jD+A=; b=XvALsxCTjUDJCcC7hNnZPZnssypsWj0LBZqW4d5bEJdl4YoRmkJVvmKO+PHUIyEMyj U8mRvV422h8x4YQf9grB/FkFpo8t2i4ABVHfmAgu+ddZeE1m4AxvnKEqe6W6x3FlFCWu RV83mX9j+5LJG0eHo1eMUXNc38w3SAk68g1fgOz9BqGOYoDqQv79Vp6j3yONIVCA32PS /nRclM1U37JVchfz4B0m6W10qqhD4r757gIaFPaoGckp0qJnlbv/hOqocouS4lti61Xb DUXsciaKTcjM5qL6vhzC3jg7/5ovIGsoWcFU0MNyK43QbMO3iByk1JQPiabKfBMM/EBp 7J7Q== Received: by 10.152.112.132 with SMTP id iq4mr17729477lab.28.1334146874089; Wed, 11 Apr 2012 05:21:14 -0700 (PDT) Received: from [10.10.1.67] ([194.100.237.57]) by mx.google.com with ESMTPS id ng2sm3259523lbb.13.2012.04.11.05.21.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Apr 2012 05:21:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Wed, 11 Apr 2012 15:21:10 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: To: David Harrington X-Mailer: Apple Mail (2.1084) Cc: secdir@ietf.org, IESG , Dan Wing , Teemu Savolainen Subject: Re: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.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, 11 Apr 2012 12:21:16 -0000 Hi, On Apr 11, 2012, at 2:16 PM, David Harrington wrote: > Hi, > > For IANA to provide an assignment, a document usually needs to request > such an assignment. > Is this document requesting the assignment, or is another document doing > so? Another document. > If this document wants to mention such an IANA assignment, it should also > provide a reference to the document that requests IANA to do so. The document that requests the actual assignment is already referenced in the same section. - Jouni > > -- > David Harrington > Ietfdbh@comcast.net > +1-603-828-1401 > > > > > > On 4/11/12 6:00 AM, "jouni korhonen" wrote: > >> Hi, >> >> Thank you for the review. See my comments inline. >> >> On Apr 10, 2012, at 3:36 PM, Alexey Melnikov 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. >>> >>> The document reviews possible solutions for the problem of allowing >>> hosts and applications to learn if an IPv6 address is synthesized, which >>> means a NAT64 is used to reach the IPv4 network or Internet. The >>> document analyzes pros and cons of various approaches and also concludes >>> with some recommendations about which approach is recommended. >>> >>> Overall I think the Security Considerations section is reasonable (see >>> some minor comments below). I think it is reasonable for the document to >>> point to RFC 6147 for DSN64 related Security Considerations. The >>> document also talks about Man-in-the-middle and Denial-of-Service >>> attacks caused by forging of information required for IPv6 synthesis >>> from corresponding IPv4 addresses. >> >> Good point. We'll add the reference. >> >> >>> >>> Additionally, the document says: >>> >>> The DHCPv6 and RA >>> based approaches are vulnerable for the forgery as the attacker may >>> send forged RAs or act as a rogue DHCPv6 server (unless DHCPv6 >>> authentication or SEND are used). >>> >>> I think some Informative references to relevant documents should be >>> inserted here in order to help readers find relevant information. >> >> Will add references to RFC3315 and RFC3971. >> >>> >>> If the attacker is already able to >>> modify and forge DNS responses (flags, addresses of know IPv4-only >>> servers, records, etc), ability to influence local address synthesis >>> is likely of low additional value. Also, a DNS-based mechanism is >>> only as secure as the method used to configure the DNS server's IP >>> addresses on the host. Therefore, if the host cannot trust e.g. >>> DHCPv6 it cannot trust the DNS server learned via DHCPv6 either, >>> unless the host has a way to authenticate all DNS responses. >>> >>> Maybe add an explicit DNSSEC reference here? >> >> Will add a reference to RFC4033. >> >> >>> >>> >>> One other possible issue that you should consider: >>> >>> 5.1.2. Analysis and discussion >>> >>> The CONs of the proposal are listed below: >>> >>> I don't know how much of an issue this is in a real world, but one >>> thought: >>> >>> Can use of a well known IPv4-only FQDN be used for tracking >>> applications/hosts which try to employ this algorithm? Such IPv4-only >>> host might be an attractive target for compromise, if such information >>> is valuable to an attacker. >> >> I guess it could be possible in theory.. if we assume the >> DNS server hosting the IPv4-only FQDN would be hostile, >> which is not a realistic assumption imho. >> >> >>> >>> (This might also apply to other DNS methods.) >>> >>> >>> Other comments (not really SecDir related): >>> >>> I found the Abstract to be quite hard to read. Maybe reword to use >>> shorter/simpler sentences? >> >> Ok. We'll look into it. >> >> >>> >>> 5.1.1. Solution description >>> >>> The Well-Known Name may be assigned by IANA or provided some third >>> party, including application or operating system vendor. The IPv4 >>> address corresponding to the Well-Known Name may be resolved via A >>> query to Well-Known Name, assigned by IANA, or hard-coded. >>> >>> Is IANA already providing one of these? If not, why speculate about >>> this, as there is no action for IANA specified in this document. >> >> IANA is going to provide one. I think it is good to have >> this part still in the document. It was a non-trivial issue >> who is going to host the well-known name. >> >> - Jouni >> >>> >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > From bclaise@cisco.com Wed Apr 11 05:28: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 B310211E808F; Wed, 11 Apr 2012 05:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] 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 myhssLoKLTto; Wed, 11 Apr 2012 05:28:22 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id B831021F8650; Wed, 11 Apr 2012 05:28:21 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3BCSIE7004402; Wed, 11 Apr 2012 14:28:18 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3BCSEwG024638; Wed, 11 Apr 2012 14:28:15 +0200 (CEST) Message-ID: <4F8578DE.1020808@cisco.com> Date: Wed, 11 Apr 2012 14:28:14 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: afarrel@juniper.net, "'Al Morton'" References: <20120406144445.4188.3196.idtracker@ietfa.amsl.com> <201204061553.q36FrBRV007699@alpd052.aldc.att.com> <07e001cd14e0$41b408c0$c51c1a40$@olddog.co.uk> <201204080018.q380I1VK007743@alpd052.aldc.att.com> <099701cd15b1$fc18c990$f44a5cb0$@olddog.co.uk> <201204091344.q39Di1rK002725@alpd052.aldc.att.com> <0bea01cd168a$7ed8ae80$7c8a0b80$@juniper.net> In-Reply-To: <0bea01cd168a$7ed8ae80$7c8a0b80$@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 11 Apr 2012 05:30:38 -0700 Cc: secdir@ietf.org, Wesley Eddy , "'Murphy, Sandra'" , 'Samuel Weiler' , ippm-chairs@tools.ietf.org, 'The IESG' , adrian@olddog.co.uk, 'Dan Frost' , draft-ietf-ippm-rt-loss@tools.ietf.org Subject: Re: [secdir] Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT): new (temp) draft? 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, 11 Apr 2012 12:28:22 -0000 Al, Wes I want to review this draft before the IESG telechat tomorrow. However, it's getting difficult to keep track of the all the changes between - the posted version 3 - the diff-03-04 you sent - the extra proposal. What is the best way to proceed? - Al, have you kept a temp version with all the changes? - Are we shooting for "revised-ID" at the telechat? I could start my review from there - Do we want to have a version 4 posted now? What is the best way to proceed? Regards, Benoit. > Al, > > As always, a reasoned response from you. > > A > >> -----Original Message----- >> From: Al Morton [mailto:acmorton@att.com] >> Sent: 09 April 2012 14:45 >> To: adrian@olddog.co.uk; 'Samuel Weiler'; 'The IESG' >> Cc: secdir@ietf.org; 'Murphy, Sandra'; 'Dan Frost'; > ippm-chairs@tools.ietf.org; >> draft-ietf-ippm-rt-loss@tools.ietf.org >> Subject: RE: Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with > DISCUSS >> and COMMENT) >> >> Hi Adrian, >> >> Thanks for clearing your DISCUSS. As always, the memo reads better >> owing to your efforts, and those of Dan and Sandra. >> >> Here's what I added in section 4.4, with supporting modifications >> elsewhere: >> >> We add the following guidance regarding the responder process to >> "send a Type-P packet back to the Src as quickly as possible". >> >> A response that was not generated within Tmax is inadequate for any >> realistic test, and the Src will discard such responses. A responder >> that serves typical round-trip loss testing (which is relevant to >> higher-layer application performance) SHOULD produce a response in 1 >> second or less. A responder that is unable to satisfy this >> requirement SHOULD log the fact so that an operator >> can adjust the load and priorities as necessary. Analysis of >> responder time-stamps [RFC5357] that finds responses are not >> generated in a timely fashion SHOULD result in operator notification, >> and the operator SHOULD suspend tests to the responder since it may >> be overloaded. Additional measurement considerations are described in >> Section 8, below. >> >> Ciao, >> Al >> >> >> At 02:04 PM 4/8/2012, Adrian Farrel wrote: >>> Hello Al, >>> >>>>>> Although IPPM has never formalized a strategy, we have been repeating >>>>>> security material in metrics RFCs. This allows new folks to read >>>>>> and improve the text, rather than be referred to a fixed reference. >>>>>> It seems to work. >>>>> I can see how that would lead to the verbatim reproduction of >>> text. I have no >>>>> problem with that per se, but I worry that the process has >>> become formulaic >>>>> without any new consideration of security for the specific >>> document in hand. >>>>> If you tell me that this is adequate for this document and no >>> refinement is >>>>> needed in this case, I will clear and let the Security ADs and >>>>> Directorate worry >>>>> about the security details. >>>> I think it is. We are essentially conducting a two-way version of RFC 2680 >>>> (one-way loss), so all the same considerations apply. We have exposure in >>>> two (possibly different) paths, but the threats are the same. >>> OK. I cleared my Discuss. >>> >>>>>>>> 1. The phrase "as immediately as possible" that appears a couple > of >>>>>>>> times in the text (and that seems to originate in RFC >>> 5357) is a bit >>>>>>>> unfortunate. "Immediately" or "as quickly as possible" are > better. >>>>>> This odd turn of phrase resulted from many hours of discussion >>>>>> dating back to TWAMP's development. We wear the scar proudly. >>>>> Well, this is only a Comment, and you do not have to address it, but "as >>>>> immediately as possible" is hogwash. It is a butchery of the >>>>> language and means >>>>> nothing! >>>>> >>>>> In fact, and as a general principle of writing standards, even >>> "as quickly as >>>>> possible" would be poor. The English would be fine, but it is a > subjective >>>>> statement against which conformance cannot be measured. >>>> Under typical protocol development circumstances, we could write a >>>> real requirement: >>>> The response MUST be prepared and sent on the wire in>>> >>>> But that's not the case here. Instead we have desire that the response >>>> will be sent immediately, yet we understand that measurement systems will: >>>> >>>> - occasionally execute higher priority processes that delay the response >>>> (processing routing updates comes to mind) >>>> - carry 2 time stamps that allow the tester to determine if the response >>>> was generated fast enough for the intended purpose >>>> - serve purposes with greater or lesser need for immediacy >>>> - either meet the variable needs for measurement immediacy or not, and >>>> this is a judgement that can be made on each and every >>> measurement packet >>>> Is it useful to explain some/all of this in the memo? >>> I don't think so. I would just fix the text to say what you mean! >>> >>> I found key text in your mail to be: >>> >>>> allow the tester to determine if the response >>>> was generated fast enough for the intended purpose >>> Surely it is not enough to have the tester discard all response because they >>> were not fast enough. Surely it is a good idea to give *meaningful* advice to >>> the responder about how to respond so that the response is "fast >>> enough for the >>> intended purpose." >>> >>> Clearly "immediately" is not what is meant since it is allowed for >>> this to be a >>> background process. So perhaps the correct thing to do is warn the >> implementer >>> of the responder about the expectations of the tester. Something like: >>> >>> A tester will normally find that a response that was not generated within 3 >>> weeks is inadequate for the purposes of a realistic test and will discard > such >>> responses. Therefore, a responder needs to ensure that at least 67.2% of >>> responses are generated within 1 hour of receiving the request. A >>> responder that >>> is unable to satisfy this requirement SHOULD log the fact so that an operator >>> can adjust the load and priorities as necessary. A tester that finds that >>> responses regularly are not generated in a timely fashion SHOULD notify the >>> operator that the responder is compromising the tests, and SHOULD suspend >>> sending requests to the responder since it is clearly overloaded. >>> >>> >>> Ciao, >>> Adrian > From alexey.melnikov@isode.com Wed Apr 11 11:28: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 D677E11E80BA; Wed, 11 Apr 2012 11:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=0.257, 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 OaSTOMA0z47P; Wed, 11 Apr 2012 11:28:00 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id DE8FA11E8098; Wed, 11 Apr 2012 11:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334168873; d=isode.com; s=selector; i=@isode.com; bh=bP3AjX2fSnhYKRfX0/cnpviC9QxjgNNNrg/Z9IB3+MI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=vYmHHLNOrYV7EDCoKxGjztR7QepvPpZk/R/KHhwvBpj3BYQhwDIjSvdrlwokX/ajL+Chwp t6l2+y/aygZQs2Zy9h8W0DbkZLX/Z9angKGRg5crq18ntXQATiYG5QbgPewqSyRgY+L5M+ VJdGjduBxUrrEv0b9fn6igHCoeGe4tQ=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 11 Apr 2012 19:27:53 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F85CD46.2020205@isode.com> Date: Wed, 11 Apr 2012 19:28:22 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: jouni korhonen References: <4F842937.9050305@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Teemu Savolainen , IESG , Dan Wing , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.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, 11 Apr 2012 18:28:01 -0000 On 11/04/2012 11:00, jouni korhonen wrote: > Hi, Hi Jouni, > Thank you for the review. See my comments inline. > > On Apr 10, 2012, at 3:36 PM, Alexey Melnikov wrote: [...] >> One other possible issue that you should consider: >> >> 5.1.2. Analysis and discussion >> >> The CONs of the proposal are listed below: >> >> I don't know how much of an issue this is in a real world, but one thought: >> >> Can use of a well known IPv4-only FQDN be used for tracking applications/hosts which try to employ this algorithm? Such IPv4-only host might be an attractive target for compromise, if such information is valuable to an attacker. > I guess it could be possible in theory.. if we assume the > DNS server hosting the IPv4-only FQDN would be hostile, Not necessarily, for example it can be compromised. > which is not a realistic assumption imho. > From alexey.melnikov@isode.com Wed Apr 11 11:29:28 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 A537811E80BA; Wed, 11 Apr 2012 11:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.355 X-Spam-Level: X-Spam-Status: No, score=-102.355 tagged_above=-999 required=5 tests=[AWL=0.244, 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 d42epjUSV2kw; Wed, 11 Apr 2012 11:29:27 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2CC11E8098; Wed, 11 Apr 2012 11:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334168960; d=isode.com; s=selector; i=@isode.com; bh=KlYRpO8rVqbegeT4V7jFTyBLxIRTV/lqL/4GdwSbD48=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=qUWPZtmG92+nc+C/5brs53HFbAx5dTYegTZJivq/HslKiNFEdWbehe9pURleH9Ul6Oizup 7wEeSlNQTlbIUquPlpQOom3tXrmu6ywRCLBy7e6Ac0Sn9jeTHeoB3dAF3ZpYRplZh/KPfB lvt9Xv+2jXQ2mI4KXvGggKI6nNRyivo=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 11 Apr 2012 19:29:20 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F85CD84.1010903@isode.com> Date: Wed, 11 Apr 2012 19:29:24 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: David Harrington , jouni korhonen References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org, IESG , Dan Wing , Teemu Savolainen Subject: Re: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.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, 11 Apr 2012 18:29:28 -0000 On 11/04/2012 12:16, David Harrington wrote: > Hi, > > For IANA to provide an assignment, a document usually needs to request > such an assignment. > Is this document requesting the assignment, or is another document doing > so? > If this document wants to mention such an IANA assignment, it should also > provide a reference to the document that requests IANA to do so. +1. > -- > David Harrington > Ietfdbh@comcast.net > +1-603-828-1401 > > > > > > On 4/11/12 6:00 AM, "jouni korhonen" wrote: >> Hi, >> >> Thank you for the review. See my comments inline. >> >> On Apr 10, 2012, at 3:36 PM, Alexey Melnikov 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. >>> >>> The document reviews possible solutions for the problem of allowing >>> hosts and applications to learn if an IPv6 address is synthesized, which >>> means a NAT64 is used to reach the IPv4 network or Internet. The >>> document analyzes pros and cons of various approaches and also concludes >>> with some recommendations about which approach is recommended. >>> >>> Overall I think the Security Considerations section is reasonable (see >>> some minor comments below). I think it is reasonable for the document to >>> point to RFC 6147 for DSN64 related Security Considerations. The >>> document also talks about Man-in-the-middle and Denial-of-Service >>> attacks caused by forging of information required for IPv6 synthesis >> >from corresponding IPv4 addresses. >> >> Good point. We'll add the reference. >> >> >>> Additionally, the document says: >>> >>> The DHCPv6 and RA >>> based approaches are vulnerable for the forgery as the attacker may >>> send forged RAs or act as a rogue DHCPv6 server (unless DHCPv6 >>> authentication or SEND are used). >>> >>> I think some Informative references to relevant documents should be >>> inserted here in order to help readers find relevant information. >> Will add references to RFC3315 and RFC3971. >> >>> If the attacker is already able to >>> modify and forge DNS responses (flags, addresses of know IPv4-only >>> servers, records, etc), ability to influence local address synthesis >>> is likely of low additional value. Also, a DNS-based mechanism is >>> only as secure as the method used to configure the DNS server's IP >>> addresses on the host. Therefore, if the host cannot trust e.g. >>> DHCPv6 it cannot trust the DNS server learned via DHCPv6 either, >>> unless the host has a way to authenticate all DNS responses. >>> >>> Maybe add an explicit DNSSEC reference here? >> Will add a reference to RFC4033. >> >>> One other possible issue that you should consider: >>> >>> 5.1.2. Analysis and discussion >>> >>> The CONs of the proposal are listed below: >>> >>> I don't know how much of an issue this is in a real world, but one >>> thought: >>> >>> Can use of a well known IPv4-only FQDN be used for tracking >>> applications/hosts which try to employ this algorithm? Such IPv4-only >>> host might be an attractive target for compromise, if such information >>> is valuable to an attacker. >> I guess it could be possible in theory.. if we assume the >> DNS server hosting the IPv4-only FQDN would be hostile, >> which is not a realistic assumption imho. >> >>> (This might also apply to other DNS methods.) >>> >>> >>> Other comments (not really SecDir related): >>> >>> I found the Abstract to be quite hard to read. Maybe reword to use >>> shorter/simpler sentences? >> Ok. We'll look into it. >> >> >>> 5.1.1. Solution description >>> >>> The Well-Known Name may be assigned by IANA or provided some third >>> party, including application or operating system vendor. The IPv4 >>> address corresponding to the Well-Known Name may be resolved via A >>> query to Well-Known Name, assigned by IANA, or hard-coded. >>> >>> Is IANA already providing one of these? If not, why speculate about >>> this, as there is no action for IANA specified in this document. >> IANA is going to provide one. I think it is good to have >> this part still in the document. It was a non-trivial issue >> who is going to host the well-known name. From weiler@watson.org Wed Apr 11 12:33: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 800B211E80B8 for ; Wed, 11 Apr 2012 12:33:19 -0700 (PDT) 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 I+ReT+0Yu7hG for ; Wed, 11 Apr 2012 12:33:19 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id E63E411E80B3 for ; Wed, 11 Apr 2012 12:33:18 -0700 (PDT) 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 q3BJXHJq042498; Wed, 11 Apr 2012 15:33:17 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q3BJXHPh042492; Wed, 11 Apr 2012 15:33:17 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 11 Apr 2012 15:33:17 -0400 (EDT) From: Samuel Weiler To: Alexey Melnikov In-Reply-To: <4F842A4D.1000205@isode.com> Message-ID: References: <4F842937.9050305@isode.com> <4F842A4D.1000205@isode.com> 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, 11 Apr 2012 15:33:18 -0400 (EDT) Cc: secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.txt 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, 11 Apr 2012 19:33:19 -0000 On Tue, 10 Apr 2012, Alexey Melnikov wrote: > I have to admit that my knowledge of DNSSEC is lacking, so can somebody help > me answer this question (which I didn't mention in my SecDir review): > > 5.2. EDNS0 option indicating AAAA Record synthesis and format ... > EDNS0 option [RFC2671], which contained 3 flag bits (called SY-bits). ... > Will DNS64 insertion of this option invalid DNSSEC signature? No. EDNS0 "stuff" is not DNSSEC-signed. I'm not familiar with the cited proposal, but it looks like a poor choice for the task -- EDNS0 "stuff" is hop-by-hop, and this look like data that should persist through the network. -- Sam From weiler@watson.org Wed Apr 11 12:39: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 2A3F011E80B3; Wed, 11 Apr 2012 12:39:19 -0700 (PDT) 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=[AWL=0.000, 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 4tytE9flobFF; Wed, 11 Apr 2012 12:39:18 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD8711E8075; Wed, 11 Apr 2012 12:39:18 -0700 (PDT) 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 q3BJdFtE045863; Wed, 11 Apr 2012 15:39:15 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q3BJdEl1045856; Wed, 11 Apr 2012 15:39:14 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 11 Apr 2012 15:39:14 -0400 (EDT) From: Samuel Weiler To: jouni korhonen In-Reply-To: Message-ID: References: <4F842937.9050305@isode.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Wed, 11 Apr 2012 15:39:15 -0400 (EDT) Cc: secdir@ietf.org, IESG , Dan Wing , Teemu Savolainen Subject: Re: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.txt 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, 11 Apr 2012 19:39:19 -0000 On Wed, 11 Apr 2012, jouni korhonen wrote: >> I think some Informative references to relevant documents should be >> inserted here in order to help readers find relevant information. > > Will add references to RFC3315 and RFC3971. More generally, please add informative citations to all of the docs (e.g the ones mentioned in 5.*) -- don't just give us the ID titles, actually cite them. -- Sam From weiler@watson.org Wed Apr 11 12:45: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 AD9D311E80C9; Wed, 11 Apr 2012 12:45:48 -0700 (PDT) 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=[AWL=0.000, 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 IFjCOmSrZe84; Wed, 11 Apr 2012 12:45:48 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7072E11E80C6; Wed, 11 Apr 2012 12:45:47 -0700 (PDT) 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 q3BJjiW3049459; Wed, 11 Apr 2012 15:45:44 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q3BJjiV5049453; Wed, 11 Apr 2012 15:45:44 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 11 Apr 2012 15:45:44 -0400 (EDT) From: Samuel Weiler To: Alexey Melnikov In-Reply-To: <4F842937.9050305@isode.com> Message-ID: References: <4F842937.9050305@isode.com> 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, 11 Apr 2012 15:45:45 -0400 (EDT) Cc: Jouni Korhonen , Teemu Savolainen , IESG , Dan Wing , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.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, 11 Apr 2012 19:45:48 -0000 Adding my own comments: I think there may be a key "con" missing in the discussion of the two EDNS0 approaches (in 5.2 in 5.3). EDNS0 "stuff", whether flags or options, are typically hop-by-hop only. That severely limits the applicability of these approaches. -- Sam From weiler@watson.org Wed Apr 11 13:07: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 3349A11E80B8 for ; Wed, 11 Apr 2012 13:07:18 -0700 (PDT) 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 tmokh4yfTgeS for ; Wed, 11 Apr 2012 13:07:17 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9D211E8075 for ; Wed, 11 Apr 2012 13:07:17 -0700 (PDT) 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 q3BK7GtY062093 for ; Wed, 11 Apr 2012 16:07:16 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q3BK7GUi062090 for ; Wed, 11 Apr 2012 16:07:16 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 11 Apr 2012 16:07:16 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Wed, 11 Apr 2012 16:07:17 -0400 (EDT) Subject: Re: [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, 11 Apr 2012 20:07:18 -0000 We don't have many new docs coming into the pipeline, but a bunch of the docs on tomorrow's telechat have yet to be reviewed. Please check the list below. I'll send new assignments tomorrow or Friday. -- Sam On Tue, 3 Apr 2012, Samuel Weiler wrote: > There are some new assignments of docs scheduled for the 12 April telechat. > The last assignment message was 16 March, well before the Paris meeting. > > Review instructions and related resources are at: > http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > Scott Kelly is next in the rotation. > > For telechat 2012-04-12 > > Reviewer LC end Draft > Rob Austein T 2012-03-30 draft-ietf-ancp-pon-02 > Dave Cridland T 2012-03-30 draft-ietf-dnsext-rfc2671bis-edns0-08 > Shawn Emery T 2012-04-12 draft-ietf-conex-concepts-uses-04 > Tobias Gondrom T 2012-04-11 > draft-ietf-dhc-dhcpv6-reconfigure-rebind-09 > Charlie Kaufman T 2012-04-11 draft-ietf-tcpm-3517bis-02 > Catherine Meadows T 2012-03-22 draft-ietf-avtcore-ecn-for-rtp-07 > Alexey Melnikov T 2012-03-22 draft-ietf-behave-nat64-learn-analysis-03 > Tim Polk T 2012-02-07 draft-ietf-oauth-v2-bearer-18 > Eric Rescorla T 2012-03-20 draft-ietf-savi-dhcp-12 > Yaron Sheffer T 2012-03-26 > draft-ietf-avtcore-feedback-supression-rtp-16 > Ondrej Sury T 2012-03-26 draft-ietf-bmwg-ipflow-meth-09 > Sam Weiler TR2012-03-06 draft-george-travel-faq-05 > Brian Weis T 2012-04-09 draft-jivsov-openpgp-ecc-11 > > > For telechat 2012-04-26 > > Reviewer LC end Draft > Derek Atkins T 2012-04-16 draft-dbider-sha2-mac-for-ssh-05 > Donald Eastlake T 2012-04-13 draft-ietf-appsawg-greylisting-06 > Steve Hanna T 2012-04-12 draft-ietf-emu-chbind-14 > Russ Mundy T 2012-03-20 draft-ietf-fecframe-raptor-10 > > Last calls and special requests: > > Reviewer LC end Draft > Richard Barnes 2012-03-30 > draft-ietf-dhc-dhcpv6-redundancy-consider-02 > Alan DeKok 2012-04-17 > draft-claise-export-application-info-in-ipfix-05 > Phillip Hallam-Baker 2012-04-18 draft-ietf-ecrit-lost-sync-17 > Dan Harkins 2012-04-11 draft-ietf-ipfix-flow-selection-tech-10 > Sam Hartman 2012-04-11 draft-ietf-ippm-reporting-metrics-08 > Paul Hoffman 2012-04-08 draft-ietf-krb-wg-des-die-die-die-04 > Jeffrey Hutzelman 2012-03-21 draft-betts-itu-oam-ach-code-point-03 > Jeffrey Hutzelman 2012-04-16 draft-ietf-manet-nhdp-mib-12 > Leif Johansson 2012-04-12 draft-ietf-netmod-smi-yang-04 > Tim Polk 2012-03-21 draft-ietf-pwe3-redundancy-bit-06 > Eric Rescorla 2012-02-08 draft-ietf-sieve-notify-sip-message-08 > Vincent Roca 2012-02-06 draft-ietf-simple-chat-14 > Joe Salowey 2012-04-18 draft-templin-aero-10 > Carl Wallace - draft-ietf-roll-minrank-hysteresis-of-07 > Sam Weiler 2012-03-23 draft-sakane-dhc-dhcpv6-kdc-option-14 > Klaas Wierenga - draft-ietf-httpbis-p4-conditional-19 > Nico Williams - draft-ietf-httpbis-p5-range-19 > Tom Yu - draft-ietf-httpbis-p6-cache-19 > Glen Zorn - draft-ietf-httpbis-p7-auth-19 > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > From bew@cisco.com Wed Apr 11 14:04: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 E9DAD11E80DC; Wed, 11 Apr 2012 14:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.523 X-Spam-Level: X-Spam-Status: No, score=-110.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 SrXk2jaII6rP; Wed, 11 Apr 2012 14:04:57 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE1E11E80DB; Wed, 11 Apr 2012 14:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=21844; q=dns/txt; s=iport; t=1334178297; x=1335387897; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=HWp1m9WJLJaq6K5DtKoEqvDJPBXQOLp5MY8r+c2HVy4=; b=F0K6QOmbJ5dedm2HArCLRuwoFlahK4geX91w+lma+L7tfUNmZqS3eI3L 8ht9JiSp43KqPDdbsEOfmu34A8m6w7s9jmzQMcu4vrDuQm1IBSPFKceKx p6EJkC2BgkM1J9utrmvinAj39+sinvyxUAmOwn+cU5ow1cZgYbEeKMlkF g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKHwhU+rRDoJ/2dsb2JhbABBA4JGtxCBB4IJAQEBAwESAQUPUgULCw4KLlcGEyKHZwQBC5pzoB+OTIJGYwSIWo0SgRGNPIFpgweBNgYR X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208,217";a="36992250" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 11 Apr 2012 21:04:56 +0000 Received: from dhcp-128-107-147-33.cisco.com (dhcp-128-107-147-33.cisco.com [128.107.147.33]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3BL4uIM020290; Wed, 11 Apr 2012 21:04:56 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_3FE3CC25-69E3-4B8A-889A-FFD0DE75523F" From: Brian Weis In-Reply-To: <4F85DAF6.5070807@brainhub.org> Date: Wed, 11 Apr 2012 14:04:55 -0700 Message-Id: <14A3E8B6-0688-47D2-9143-9479E20768ED@cisco.com> References: <4F85DAF6.5070807@brainhub.org> To: Andrey Jivsov X-Mailer: Apple Mail (2.1257) Cc: "draft-jivsov-openpgp-ecc.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-jivsov-openpgp-ecc-12 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, 11 Apr 2012 21:04:59 -0000 --Apple-Mail=_3FE3CC25-69E3-4B8A-889A-FFD0DE75523F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Andrey, On Apr 11, 2012, at 12:26 PM, Andrey Jivsov wrote: > Thank you for your comments, Brian. I integrated some of them into = -13, posted = http://datatracker.ietf.org/doc/draft-jivsov-openpgp-ecc/history/ >=20 > On 04/10/2012 08:11 PM, Brian Weis 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 adds support for the use of ECC as an authentication = method to OpenPGP. Two public key algorithms are supported: ECDSA and = ECDH. The document describes the supported ECC curves, how the public = key is represented in OpenPGP, and encodings for public and private = keys. For ECDH, it also specifies the KDF for creating a KEK from from = ECDH shared secret and the method for key wrapping a session key that is = used to protect data traffic. This seems to be standard OpenPGP practice = for DH public key algorithms. A stated goal is to conform to Suite B; as = far as I can tell this is achieved. >>=20 >> I have the following comments/questions. >>=20 >> Section 5: A reference to ECDSA is given for both RFC 6090 and = [SEC1]. The definition in RFC 6090 supersedes [SEC1], and it is = preferable to reference just the RFC. I suggest removing "and in = [SEC1]". >=20 > It seems to me that SEC1 provides the most succinct description of the = algorithm among all the publicly available sources. RFC 6090 refers to = another external document, which is written in a form of a survey of = crypto methods, which the reader will need to process to get the = relevant portion. It's unfortunate that FIPS 186-3 doesn't spell out the = ECDSA exactly. >=20 >>=20 >> Section 6: RFC 6090 uses the notation "(@,@)" for the point at = infinity ("point O"), which would be better to use. This seems to be the = only term in this section specific to [SEC1], so making this change = should enable you to change your reference to RFC 6090 here too. >=20 > The main reason for SEC1 reference is to define the format 04 || x || = y. RFC 6090 is missing any method to serialize an ECC point (no = on-the-wire format). =20 >=20 >>=20 >> Section 6: The reasoning for passing the point at infinity isn't = clearly defined. Can you explain when this would be done? >=20 > Right beneath of the table there was a sentence that addresses this in = -12, which I modified to read: >=20 > "Note that the point O shall not appear in a public keys, including = ephemeral public keys used with ECDH, defined in section 8." >=20 I believe this sentence is saying that it will never be included in a = protocol payload, which makes sense to me. So I'm wondering if there is = actually any value for mentioning the value/description of point O it in = your I-D? It's a bit confusing to include it if it isn't actually used. >> Section 7: The use of "P" for parameters is confusing, since P was = just used in Section 6 to mean "Point". It would be helpful if it were = "Params" or something other name. > Done. P-->Params >>=20 >> Section 7: It would be helpful to the reader to explain that setting = ZB to "x" is using the "compact output" of the shared secret (see RFC = 6090 Section 4.2). >=20 > Done. Added the reference at the bottom. >=20 >>=20 >> Section 8: Are the "5 variable-length and fixed-length fields" meant = to be OtherInfo as defined in SP800-56A? If so, mentioning this would = make it easier on the reader. > This is exactly what the qualifiers intended for, but they are only = needed for persons validating this draft to be compatible with = SP800-56A. I wonder if the reference here adds any value for the rest of = readers? Since your stated goal is to meet Suite B requirements, and complying = with SP800-56A is part of those requirements, I imagine there will be = people wanting to validate this after it becomes an RFC. It would seem = to be in your best interest to make it clear to them. :-) People who = don't care about the reference will just ignore it. =20 >=20 >>=20 >> Section 8: This says "The key wrapping method is based on [RFC3394]". = I hope is it actually "conforming to [RFC3394]", which would be a = clearer statement. Is that so? If not, why? > Done. It is precisely "conforming" >=20 >>=20 >> Section 8: This section gives an example of encoding a 32-octet = ASE-256 session key into 40 octets, which seems to be the input to the = key wrap. My understanding of the AES key wrap defined in RFC 3394 is = that the key input should be just 32 octets, where it is prepended with = an 8 octet IV. This doesn't match your example though. Can this be made = to match the inputs in the RFC? For example, see the example in Section = 4.6 of RFC 3394. (This would also remove the need for padding an AES-256 = key, and reduce the padding for the two smaller sizes.) > There are two reasons for the current method: >=20 > * In OpenPGP the message encryption algorithm (symmetric algorithm of = a session key) is encrypted to a public key of a recipient. In RFC 4880 = it's done so that the session key is 1_byte_symm_alg || key || checksum. = One can argue on the benefit of a checksum, but the ID bumps the payload = size to the next 8 bytes, which gives space to accomodate the checksum = and PKCS#5 padding markers for free Ok, so what you're saying is that you really need the 40 bytes as input = to the key wrap function. You should have some text clarifying exactly = how you're using the AES Key wrap though. For example: "The inputs to = the AES Key wrap are as follows: The Plaintext is taken as the 40 bytes = described above, the KEK is the value derived from the KDF, and the = Default Initial Value is used." > * One cannot we cannot say which key size was used to encrypt the = message by looking at RSA or ElGamal encrypted session key. AESWRAP = leaks this information when it is tightly encapsulated the session key = (this may leak how sensitive a protected document is). There is a = description in the same section 8 on how to avoid this leak by padding = the payload of AESWRAP to make it always look like an AES-256 session = key. >=20 >>=20 >> Section 10: The statement "No changes in the format are needed for = ECDSA" seems true, but isn't it necessary to describe the Algorithm = Specific Fields for ECDSA? Is this actually defined in Section 9? >=20 > I intended to say that the format of the (EC)DSA signed message is = defined in the RFC4880. It's a pair of r,s integers in both cases. = Changes to public keys are needed for both ECDSA and ECDH, defined in = section 9. For internal consistency it might be good to point to section 9. >=20 >>=20 >> Section 13: The table of equivalent algorithm strengths seems to = match claims in SP800-57-Part1-Rev3-May2011. It would be helpful to = reference this document here as a source for the information. >=20 > I wanted to convey a statement that ECC=3D=3DHash=3D=3D2*AES (meaning = sizes and assuming that 521 ~ 512). As with some of the above issues, is = it the right thing to do to add a reference if it can be avoided, given = that a presence of a reference suggests that the reader must then study = it in order to understand a corresponding statements. Isn't the issue of = relative strength well-understood, so that readers that use the current = table can look it up? In my experience, the issue of relative strength has NOT been = well-understood over the years, and I believe the NIST document is the = first to actually pull it all together. Thanks, Brian >=20 >>=20 >> Thanks, >> Brian >=20 > Thank you. --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com --Apple-Mail=_3FE3CC25-69E3-4B8A-889A-FFD0DE75523F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Andrey,

On Apr 11, 2012, at 12:26 PM, Andrey Jivsov = wrote:

=20 =20
Thank you for your comments, Brian. I integrated some of them into -13, posted http://datatracker.ietf.org/doc/draft-jivsov-openpgp-ecc/history/
=
On 04/10/2012 08:11 PM, Brian Weis 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 adds support for the use of ECC as an authentication =
method to OpenPGP. Two public key algorithms are supported: ECDSA and =
ECDH. The document describes the supported ECC curves, how the public =
key is represented in OpenPGP, and encodings for public and private =
keys. For ECDH, it also specifies the KDF for creating a KEK from from =
ECDH shared secret and the method for key wrapping a session key that is =
used to protect data traffic. This seems to be standard OpenPGP practice =
for DH public key algorithms. A stated goal is to conform to Suite B; as =
far as I can tell this is achieved.

I have the following comments/questions.

Section 5: A reference to ECDSA is given for both RFC 6090 and [SEC1]. =
The definition in RFC 6090 supersedes [SEC1], and it is preferable to =
reference just the RFC. I suggest removing "and in [SEC1]".

It seems to me that SEC1 provides the most succinct description of the algorithm among all the publicly available sources. RFC 6090 refers to another external document, which is written in a form of a survey of crypto methods, which the reader will need to process to get the relevant portion. It's unfortunate that FIPS 186-3 doesn't spell out the ECDSA exactly.

= 
Section 6: RFC 6090 uses the notation "(@,@)" for the point at infinity =
("point O"), which would be better to use. This seems to be the only =
term in this section specific to [SEC1], so making this change should =
enable you to change your reference to RFC 6090 here too.

The main reason for SEC1 reference is to define the format 04 || x || y. RFC 6090 is missing any method to serialize an ECC point (no on-the-wire format). 

= 
Section 6: The reasoning for passing the point at infinity isn't clearly =
defined. Can you explain when this would be done?

Right beneath of the table there was a sentence that addresses this in -12, which I modified to read:

"Note that = the point O shall not appear in a public keys, including ephemeral public keys used with ECDH, defined in section = 8."



I believe = this sentence is saying that it will never be included in a protocol = payload, which makes sense to me. So I'm wondering if there is actually = any value for mentioning the value/description of point O it in your = I-D? It's a bit confusing to include it if it isn't actually = used.

Section 7: The use of "P" for parameters is =
confusing, since P was just used in Section 6 to mean "Point". It would =
be helpful if it were "Params" or something other name.
Done. P-->Params
= 
Section 7: It would be helpful to the reader to explain that setting ZB =
to "x" is using the "compact output" of the shared secret (see RFC 6090 =
Section 4.2).

Done. Added the reference at the bottom.

= 
Section 8: Are the "5 variable-length and fixed-length fields" meant to =
be OtherInfo as defined in SP800-56A? If so, mentioning this would make =
it easier on the reader.
This is exactly what the qualifiers intended for, but they are only needed for persons validating this draft to be compatible with SP800-56A. I wonder if the reference here adds any value for the rest of readers?

Since = your stated goal is to meet Suite B requirements, and complying with = SP800-56A is part of those requirements, I imagine there will be people = wanting to validate this after it becomes an RFC. It would seem to be in = your best interest to make it clear to them. :-) People who don't care = about the reference will just ignore it.
 

= 
Section 8: This says "The key wrapping method is based on [RFC3394]". I =
hope is it actually "conforming to [RFC3394]", which would be a clearer =
statement. Is that so? If not, why?
Done. It is precisely "conforming"

= 
Section 8: This section gives an example of encoding a 32-octet ASE-256 =
session key into 40 octets, which seems to be the input to the key wrap. =
My understanding of the AES key wrap defined in RFC 3394 is that the key =
input should be just 32 octets, where it is prepended with an 8 octet =
IV. This doesn't match your example though. Can this be made to match =
the inputs in the RFC? For example, see the example in Section 4.6 of =
RFC 3394. (This would also remove the need for padding an AES-256 key, =
and reduce the padding for the two smaller sizes.)
There are two reasons for the current method:

* In OpenPGP the message encryption algorithm (symmetric algorithm of a session key) is encrypted to a public key of a recipient. In RFC 4880 it's done so that the session key is 1_byte_symm_alg || key || checksum. One can argue on the benefit of a checksum, but the ID bumps the payload size to the next 8 bytes, which gives space to accomodate the checksum and PKCS#5 padding markers for = free

Ok, so what you're saying = is that you really need the 40 bytes as input to the key wrap function. = You should have some text clarifying exactly how you're using the AES = Key wrap though. For example: "The inputs to the AES Key wrap are as = follows: The Plaintext is taken as the 40 bytes described above, the KEK = is the value derived from the KDF, and the Default Initial Value is = used."

* One cannot we cannot say which key size was used to encrypt the message by looking at RSA or ElGamal encrypted session key. AESWRAP leaks this information when it is tightly encapsulated the session key (this may leak how sensitive a protected document is). There is a description in the same section 8 on how to avoid this leak by padding the payload of AESWRAP to make it always look like an AES-256 session key.

= 
Section 10: The statement "No changes in the format are needed for =
ECDSA" seems true, but isn't it necessary to describe the Algorithm =
Specific Fields for ECDSA? Is this actually defined in Section 9?

I intended to say that the format of the (EC)DSA signed message is defined in the RFC4880. It's a pair of r,s integers in both cases. Changes to public keys are needed for both ECDSA and ECDH, defined in section 9.

For internal = consistency it might be good to point to section = 9.


= 
Section 13: The table of equivalent algorithm strengths seems to match =
claims in SP800-57-Part1-Rev3-May2011. It would be helpful to reference =
this document here as a source for the information.

I wanted to convey a statement that ECC=3D=3DHash=3D=3D2*AES = (meaning sizes and assuming that 521 ~ 512). As with some of the above issues, is it the right thing to do to add a reference if it can be avoided, given that a presence of a reference suggests that the reader must then study it in order to understand a corresponding statements. Isn't the issue of relative strength well-understood, so that readers that use the current table can look it = up?

In my experience, the issue of = relative strength has NOT been well-understood over the years, and I = believe the NIST document is the first to actually pull it all = together.

Thanks,
Brian

<= blockquote type=3D"cite">

= 
Thanks,
Brian

Thank you.

bew@cisco.com





= --Apple-Mail=_3FE3CC25-69E3-4B8A-889A-FFD0DE75523F-- From wes@mti-systems.com Wed Apr 11 11:12:21 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 67FCF11E80BA for ; Wed, 11 Apr 2012 11:12:21 -0700 (PDT) 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 813uRfqIw6wl for ; Wed, 11 Apr 2012 11:12:19 -0700 (PDT) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id F1AC511E808D for ; Wed, 11 Apr 2012 11:12:16 -0700 (PDT) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3BICCMv009641 for ; Wed, 11 Apr 2012 14:12:15 -0400 Authentication-Results: cm-omr6 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [107.50.114.182] ([107.50.114.182:46660] helo=[192.168.43.65]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 99/7B-22382-A79C58F4; Wed, 11 Apr 2012 14:12:14 -0400 Message-ID: <4F85C96C.4050705@mti-systems.com> Date: Wed, 11 Apr 2012 14:11:56 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Benoit Claise References: <20120406144445.4188.3196.idtracker@ietfa.amsl.com> <201204061553.q36FrBRV007699@alpd052.aldc.att.com> <07e001cd14e0$41b408c0$c51c1a40$@olddog.co.uk> <201204080018.q380I1VK007743@alpd052.aldc.att.com> <099701cd15b1$fc18c990$f44a5cb0$@olddog.co.uk> <201204091344.q39Di1rK002725@alpd052.aldc.att.com> <0bea01cd168a$7ed8ae80$7c8a0b80$@juniper.net> <4F8578DE.1020808@cisco.com> In-Reply-To: <4F8578DE.1020808@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 11 Apr 2012 17:21:17 -0700 Cc: 'Al Morton' , secdir@ietf.org, "'Murphy, Sandra'" , afarrel@juniper.net, 'Samuel Weiler' , ippm-chairs@tools.ietf.org, 'The IESG' , adrian@olddog.co.uk, 'Dan Frost' , draft-ietf-ippm-rt-loss@tools.ietf.org Subject: Re: [secdir] Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT): new (temp) draft? 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, 11 Apr 2012 18:12:21 -0000 On 4/11/2012 8:28 AM, Benoit Claise wrote: > Al, Wes > > I want to review this draft before the IESG telechat tomorrow. > However, it's getting difficult to keep track of the all the changes > between > - the posted version 3 > - the diff-03-04 you sent > - the extra proposal. > > What is the best way to proceed? > - Al, have you kept a temp version with all the changes? > - Are we shooting for "revised-ID" at the telechat? I could start my > review from there > - Do we want to have a version 4 posted now? > > What is the best way to proceed? I noticed Al sent a copy with updates that have been suggested so far. Please feel free to hit the "Defer" button if you don't feel there's adequate time to review this one; it looks like a busy telechat agenda this week! -- Wes Eddy MTI Systems From openpgp@brainhub.org Wed Apr 11 12:25:51 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 290D911E80BF for ; Wed, 11 Apr 2012 12:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 ouyVZq6TlPbf for ; Wed, 11 Apr 2012 12:25:50 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0217C11E8098 for ; Wed, 11 Apr 2012 12:25:49 -0700 (PDT) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta01.emeryville.ca.mail.comcast.net with comcast id wiUh1i0081afHeLA1jRpKJ; Wed, 11 Apr 2012 19:25:49 +0000 Received: from [127.0.0.1] ([98.234.252.65]) by omta17.emeryville.ca.mail.comcast.net with comcast id wjRn1i0081RRS8a8djRnut; Wed, 11 Apr 2012 19:25:49 +0000 Message-ID: <4F85DAF6.5070807@brainhub.org> Date: Wed, 11 Apr 2012 12:26:46 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Brian Weis References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080106010205000604090305" X-Mailman-Approved-At: Wed, 11 Apr 2012 17:21:18 -0700 Cc: "draft-jivsov-openpgp-ecc.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-jivsov-openpgp-ecc-12 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, 11 Apr 2012 19:25:51 -0000 This is a multi-part message in MIME format. --------------080106010205000604090305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thank you for your comments, Brian. I integrated some of them into -13, posted http://datatracker.ietf.org/doc/draft-jivsov-openpgp-ecc/history/ On 04/10/2012 08:11 PM, Brian Weis 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 adds support for the use of ECC as an authentication method to OpenPGP. Two public key algorithms are supported: ECDSA and ECDH. The document describes the supported ECC curves, how the public key is represented in OpenPGP, and encodings for public and private keys. For ECDH, it also specifies the KDF for creating a KEK from from ECDH shared secret and the method for key wrapping a session key that is used to protect data traffic. This seems to be standard OpenPGP practice for DH public key algorithms. A stated goal is to conform to Suite B; as far as I can tell this is achieved. > > I have the following comments/questions. > > Section 5: A reference to ECDSA is given for both RFC 6090 and [SEC1]. The definition in RFC 6090 supersedes [SEC1], and it is preferable to reference just the RFC. I suggest removing "and in [SEC1]". It seems to me that SEC1 provides the most succinct description of the algorithm among all the publicly available sources. RFC 6090 refers to another external document, which is written in a form of a survey of crypto methods, which the reader will need to process to get the relevant portion. It's unfortunate that FIPS 186-3 doesn't spell out the ECDSA exactly. > > Section 6: RFC 6090 uses the notation "(@,@)" for the point at infinity ("point O"), which would be better to use. This seems to be the only term in this section specific to [SEC1], so making this change should enable you to change your reference to RFC 6090 here too. The main reason for SEC1 reference is to define the format 04 || x || y. RFC 6090 is missing any method to serialize an ECC point (no on-the-wire format). > > Section 6: The reasoning for passing the point at infinity isn't clearly defined. Can you explain when this would be done? Right beneath of the table there was a sentence that addresses this in -12, which I modified to read: "Note that the point O shall not appear in a public keys, including ephemeral public keys used with ECDH, defined in section 8." > > Section 7: The use of "P" for parameters is confusing, since P was just used in Section 6 to mean "Point". It would be helpful if it were "Params" or something other name. Done. P-->Params > > Section 7: It would be helpful to the reader to explain that setting ZB to "x" is using the "compact output" of the shared secret (see RFC 6090 Section 4.2). Done. Added the reference at the bottom. > > Section 8: Are the "5 variable-length and fixed-length fields" meant to be OtherInfo as defined in SP800-56A? If so, mentioning this would make it easier on the reader. This is exactly what the qualifiers intended for, but they are only needed for persons validating this draft to be compatible with SP800-56A. I wonder if the reference here adds any value for the rest of readers? > > Section 8: This says "The key wrapping method is based on [RFC3394]". I hope is it actually "conforming to [RFC3394]", which would be a clearer statement. Is that so? If not, why? Done. It is precisely "conforming" > > Section 8: This section gives an example of encoding a 32-octet ASE-256 session key into 40 octets, which seems to be the input to the key wrap. My understanding of the AES key wrap defined in RFC 3394 is that the key input should be just 32 octets, where it is prepended with an 8 octet IV. This doesn't match your example though. Can this be made to match the inputs in the RFC? For example, see the example in Section 4.6 of RFC 3394. (This would also remove the need for padding an AES-256 key, and reduce the padding for the two smaller sizes.) There are two reasons for the current method: * In OpenPGP the message encryption algorithm (symmetric algorithm of a session key) is encrypted to a public key of a recipient. In RFC 4880 it's done so that the session key is 1_byte_symm_alg || key || checksum. One can argue on the benefit of a checksum, but the ID bumps the payload size to the next 8 bytes, which gives space to accomodate the checksum and PKCS#5 padding markers for free * One cannot we cannot say which key size was used to encrypt the message by looking at RSA or ElGamal encrypted session key. AESWRAP leaks this information when it is tightly encapsulated the session key (this may leak how sensitive a protected document is). There is a description in the same section 8 on how to avoid this leak by padding the payload of AESWRAP to make it always look like an AES-256 session key. > > Section 10: The statement "No changes in the format are needed for ECDSA" seems true, but isn't it necessary to describe the Algorithm Specific Fields for ECDSA? Is this actually defined in Section 9? I intended to say that the format of the (EC)DSA signed message is defined in the RFC4880. It's a pair of r,s integers in both cases. Changes to public keys are needed for both ECDSA and ECDH, defined in section 9. > > Section 13: The table of equivalent algorithm strengths seems to match claims in SP800-57-Part1-Rev3-May2011. It would be helpful to reference this document here as a source for the information. I wanted to convey a statement that ECC==Hash==2*AES (meaning sizes and assuming that 521 ~ 512). As with some of the above issues, is it the right thing to do to add a reference if it can be avoided, given that a presence of a reference suggests that the reader must then study it in order to understand a corresponding statements. Isn't the issue of relative strength well-understood, so that readers that use the current table can look it up? > > Thanks, > Brian Thank you. --------------080106010205000604090305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thank you for your comments, Brian. I integrated some of them into -13, posted http://datatracker.ietf.org/doc/draft-jivsov-openpgp-ecc/history/

On 04/10/2012 08:11 PM, Brian Weis 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 adds support for the use of ECC as an authentication method to OpenPGP. Two public key algorithms are supported: ECDSA and ECDH. The document describes the supported ECC curves, how the public key is represented in OpenPGP, and encodings for public and private keys. For ECDH, it also specifies the KDF for creating a KEK from from ECDH shared secret and the method for key wrapping a session key that is used to protect data traffic. This seems to be standard OpenPGP practice for DH public key algorithms. A stated goal is to conform to Suite B; as far as I can tell this is achieved.

I have the following comments/questions.

Section 5: A reference to ECDSA is given for both RFC 6090 and [SEC1]. The definition in RFC 6090 supersedes [SEC1], and it is preferable to reference just the RFC. I suggest removing "and in [SEC1]".

It seems to me that SEC1 provides the most succinct description of the algorithm among all the publicly available sources. RFC 6090 refers to another external document, which is written in a form of a survey of crypto methods, which the reader will need to process to get the relevant portion. It's unfortunate that FIPS 186-3 doesn't spell out the ECDSA exactly.


Section 6: RFC 6090 uses the notation "(@,@)" for the point at infinity ("point O"), which would be better to use. This seems to be the only term in this section specific to [SEC1], so making this change should enable you to change your reference to RFC 6090 here too.

The main reason for SEC1 reference is to define the format 04 || x || y. RFC 6090 is missing any method to serialize an ECC point (no on-the-wire format).  


Section 6: The reasoning for passing the point at infinity isn't clearly defined. Can you explain when this would be done?

Right beneath of the table there was a sentence that addresses this in -12, which I modified to read:

"Note that the point O shall not appear in a public keys, including ephemeral public keys used with ECDH, defined in section 8."




Section 7: The use of "P" for parameters is confusing, since P was just used in Section 6 to mean "Point". It would be helpful if it were "Params" or something other name.
Done. P-->Params

Section 7: It would be helpful to the reader to explain that setting ZB to "x" is using the "compact output" of the shared secret (see RFC 6090 Section 4.2).

Done. Added the reference at the bottom.


Section 8: Are the "5 variable-length and fixed-length fields" meant to be OtherInfo as defined in SP800-56A? If so, mentioning this would make it easier on the reader.
This is exactly what the qualifiers intended for, but they are only needed for persons validating this draft to be compatible with SP800-56A. I wonder if the reference here adds any value for the rest of readers?


Section 8: This says "The key wrapping method is based on [RFC3394]". I hope is it actually "conforming to [RFC3394]", which would be a clearer statement. Is that so? If not, why?
Done. It is precisely "conforming"


Section 8: This section gives an example of encoding a 32-octet ASE-256 session key into 40 octets, which seems to be the input to the key wrap. My understanding of the AES key wrap defined in RFC 3394 is that the key input should be just 32 octets, where it is prepended with an 8 octet IV. This doesn't match your example though. Can this be made to match the inputs in the RFC? For example, see the example in Section 4.6 of RFC 3394. (This would also remove the need for padding an AES-256 key, and reduce the padding for the two smaller sizes.)
There are two reasons for the current method:

* In OpenPGP the message encryption algorithm (symmetric algorithm of a session key) is encrypted to a public key of a recipient. In RFC 4880 it's done so that the session key is 1_byte_symm_alg || key || checksum. One can argue on the benefit of a checksum, but the ID bumps the payload size to the next 8 bytes, which gives space to accomodate the checksum and PKCS#5 padding markers for free
* One cannot we cannot say which key size was used to encrypt the message by looking at RSA or ElGamal encrypted session key. AESWRAP leaks this information when it is tightly encapsulated the session key (this may leak how sensitive a protected document is). There is a description in the same section 8 on how to avoid this leak by padding the payload of AESWRAP to make it always look like an AES-256 session key.


Section 10: The statement "No changes in the format are needed for ECDSA" seems true, but isn't it necessary to describe the Algorithm Specific Fields for ECDSA? Is this actually defined in Section 9?

I intended to say that the format of the (EC)DSA signed message is defined in the RFC4880. It's a pair of r,s integers in both cases. Changes to public keys are needed for both ECDSA and ECDH, defined in section 9.


Section 13: The table of equivalent algorithm strengths seems to match claims in SP800-57-Part1-Rev3-May2011. It would be helpful to reference this document here as a source for the information.

I wanted to convey a statement that ECC==Hash==2*AES (meaning sizes and assuming that 521 ~ 512). As with some of the above issues, is it the right thing to do to add a reference if it can be avoided, given that a presence of a reference suggests that the reader must then study it in order to understand a corresponding statements. Isn't the issue of relative strength well-understood, so that readers that use the current table can look it up?


Thanks,
Brian

Thank you.
--------------080106010205000604090305-- From openpgp@brainhub.org Wed Apr 11 17:16: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 3640711E810F for ; Wed, 11 Apr 2012 17:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=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 1SkcG01UOLwl for ; Wed, 11 Apr 2012 17:16:46 -0700 (PDT) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by ietfa.amsl.com (Postfix) with ESMTP id EAAE821F84CF for ; Wed, 11 Apr 2012 17:16:45 -0700 (PDT) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta05.emeryville.ca.mail.comcast.net with comcast id wo5N1i0010b6N64A5oGlzb; Thu, 12 Apr 2012 00:16:45 +0000 Received: from [127.0.0.1] ([98.234.252.65]) by omta03.emeryville.ca.mail.comcast.net with comcast id woGh1i02D1RRS8a8PoGiew; Thu, 12 Apr 2012 00:16:45 +0000 Message-ID: <4F861F25.8070005@brainhub.org> Date: Wed, 11 Apr 2012 17:17:41 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Brian Weis References: <4F85DAF6.5070807@brainhub.org> <14A3E8B6-0688-47D2-9143-9479E20768ED@cisco.com> In-Reply-To: <14A3E8B6-0688-47D2-9143-9479E20768ED@cisco.com> Content-Type: multipart/alternative; boundary="------------070103060502000105020109" X-Mailman-Approved-At: Wed, 11 Apr 2012 17:21:18 -0700 Cc: "draft-jivsov-openpgp-ecc.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-jivsov-openpgp-ecc-12 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, 12 Apr 2012 00:16:47 -0000 This is a multi-part message in MIME format. --------------070103060502000105020109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello again Brian. Thank you for your comments. I integrated them into -14 revision. On 04/11/2012 02:04 PM, Brian Weis wrote: > ... >>> Section 6: The reasoning for passing the point at infinity isn't clearly defined. Can you explain when this would be done? >> >> Right beneath of the table there was a sentence that addresses this >> in -12, which I modified to read: >> >> "Note that the point O shall not appear in a public keys, including >> ephemeral public keys used with ECDH, defined in section 8." >> >> > > I believe this sentence is saying that it will never be included in a > protocol payload, which makes sense to me. So I'm wondering if there > is actually any value for mentioning the value/description of point O > it in your I-D? It's a bit confusing to include it if it isn't > actually used. > > I eliminated the B0=0. >> ... >>> Section 8: Are the "5 variable-length and fixed-length fields" meant to be OtherInfo as defined in SP800-56A? If so, mentioning this would make it easier on the reader. >> This is exactly what the qualifiers intended for, but they are only >> needed for persons validating this draft to be compatible with >> SP800-56A. I wonder if the reference here adds any value for the rest >> of readers? > > Since your stated goal is to meet Suite B requirements, and complying > with SP800-56A is part of those requirements, I imagine there will be > people wanting to validate this after it becomes an RFC. It would seem > to be in your best interest to make it clear to them. :-) People who > don't care about the reference will just ignore it. I added this reference to (already referenced) SP800-56A. > ... >>> Section 8: This section gives an example of encoding a 32-octet ASE-256 session key into 40 octets, which seems to be the input to the key wrap. My understanding of the AES key wrap defined in RFC 3394 is that the key input should be just 32 octets, where it is prepended with an 8 octet IV. This doesn't match your example though. Can this be made to match the inputs in the RFC? For example, see the example in Section 4.6 of RFC 3394. (This would also remove the need for padding an AES-256 key, and reduce the padding for the two smaller sizes.) >> There are two reasons for the current method: >> >> * In OpenPGP the message encryption algorithm (symmetric algorithm of >> a session key) is encrypted to a public key of a recipient. In RFC >> 4880 it's done so that the session key is 1_byte_symm_alg || key || >> checksum. One can argue on the benefit of a checksum, but the ID >> bumps the payload size to the next 8 bytes, which gives space to >> accomodate the checksum and PKCS#5 padding markers for free > > > Ok, so what you're saying is that you really need the 40 bytes as > input to the key wrap function. You should have some text clarifying > exactly how you're using the AES Key wrap though. For example: "The > inputs to the AES Key wrap are as follows: The Plaintext is taken as > the 40 bytes described above, the KEK is the value derived from the > KDF, and the Default Initial Value is used." I added a sentence on Default Initial Value. Here is what the current document says in section 8. > > The input to the key wrapping method is the value "m" derived from the > session key, as described in section 5.1. Public-Key Encrypted Session > Key Packets (Tag 1) of [RFC4880], except, the PKCS#1.5 padding step is > omitted.~~The result is padded using the method described in [PKCS5] > to the 8-byte granularity.~~For example, a following AES-256 session > key, which 32 octets are denoted from k0 to k31, is composed to form > the following 40 octet sequence: > > 09 k0 k1 ... k31 c0 c1 05 05 05 05 05 > > The octets c0 and c1 above denote the checksum.~~This encoding allows > the sender to obfuscate the size of the symmetric encryption key used > to encrypt the data.~~For example, assuming that an AES algorithm is > used for the session key, the sender MAY use 21, 13, and 5 bytes of > padding for AES-128, AES-192, and AES-256, respectively, to provide > the same number of octets, 40 total, as an input to the key wrapping > method. > By the way, I should have mentioned that the search with Google for "AESWRAP" will bring up the following page with code to implement the key wrapping for this draft: http://code.google.com/p/gnupg-ecc/wiki/AESWrap The following page provides test keys and other practical information to implementers: http://sites.google.com/site/brainhub/pgpecckeys > >> * One cannot we cannot say which key size was used to encrypt the >> message by looking at RSA or ElGamal encrypted session key. AESWRAP >> leaks this information when it is tightly encapsulated the session >> key (this may leak how sensitive a protected document is). There is a >> description in the same section 8 on how to avoid this leak by >> padding the payload of AESWRAP to make it always look like an AES-256 >> session key. >> >>> Section 10: The statement "No changes in the format are needed for ECDSA" seems true, but isn't it necessary to describe the Algorithm Specific Fields for ECDSA? Is this actually defined in Section 9? >> >> I intended to say that the format of the (EC)DSA signed message is >> defined in the RFC4880. It's a pair of r,s integers in both cases. >> Changes to public keys are needed for both ECDSA and ECDH, defined in >> section 9. > > For internal consistency it might be good to point to section 9. > The design criteria was to keep the message-specific fields as small as possible. This is achieved by placing everything possible into the key structure. Consider that the KDF parameters field (that affects the ECDH) is fixed at key generation. ECDSA stays the same as DSA, while ECDH needs one additional field with AESWrapped key. This said, I cannot find of a good way to say "compare this [section 10] to section 9, just above" ( these comments are a design insight, not a spec ). >> >>> Section 13: The table of equivalent algorithm strengths seems to match claims in SP800-57-Part1-Rev3-May2011. It would be helpful to reference this document here as a source for the information. >> >> I wanted to convey a statement that ECC==Hash==2*AES (meaning sizes >> and assuming that 521 ~ 512). As with some of the above issues, is it >> the right thing to do to add a reference if it can be avoided, given >> that a presence of a reference suggests that the reader must then >> study it in order to understand a corresponding statements. Isn't the >> issue of relative strength well-understood, so that readers that use >> the current table can look it up? > > In my experience, the issue of relative strength has NOT been > well-understood over the years, and I believe the NIST document is the > first to actually pull it all together. What stopped me is that this reference points to a draft. > > Thanks, > Brian > ... --------------070103060502000105020109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello again Brian. Thank you for your comments. I integrated them into -14 revision.

On 04/11/2012 02:04 PM, Brian Weis wrote:
... 
Section 6: The reasoning for passing the point at infinity isn't clearly defined. Can you explain when this would be done?

Right beneath of the table there was a sentence that addresses this in -12, which I modified to read:

"Note that the point O shall not appear in a public keys, including ephemeral public keys used with ECDH, defined in section 8."



I believe this sentence is saying that it will never be included in a protocol payload, which makes sense to me. So I'm wondering if there is actually any value for mentioning the value/description of point O it in your I-D? It's a bit confusing to include it if it isn't actually used.



I eliminated the B0=0.

...
Section 8: Are the "5 variable-length and fixed-length fields" meant to be OtherInfo as defined in SP800-56A? If so, mentioning this would make it easier on the reader.
This is exactly what the qualifiers intended for, but they are only needed for persons validating this draft to be compatible with SP800-56A. I wonder if the reference here adds any value for the rest of readers?

Since your stated goal is to meet Suite B requirements, and complying with SP800-56A is part of those requirements, I imagine there will be people wanting to validate this after it becomes an RFC. It would seem to be in your best interest to make it clear to them. :-) People who don't care about the reference will just ignore it.

I added this reference to (already referenced) SP800-56A.

... 
Section 8: This section gives an example of encoding a 32-octet ASE-256 session key into 40 octets, which seems to be the input to the key wrap. My understanding of the AES key wrap defined in RFC 3394 is that the key input should be just 32 octets, where it is prepended with an 8 octet IV. This doesn't match your example though. Can this be made to match the inputs in the RFC? For example, see the example in Section 4.6 of RFC 3394. (This would also remove the need for padding an AES-256 key, and reduce the padding for the two smaller sizes.)
There are two reasons for the current method:

* In OpenPGP the message encryption algorithm (symmetric algorithm of a session key) is encrypted to a public key of a recipient. In RFC 4880 it's done so that the session key is 1_byte_symm_alg || key || checksum. One can argue on the benefit of a checksum, but the ID bumps the payload size to the next 8 bytes, which gives space to accomodate the checksum and PKCS#5 padding markers for free


Ok, so what you're saying is that you really need the 40 bytes as input to the key wrap function. You should have some text clarifying exactly how you're using the AES Key wrap though. For example: "The inputs to the AES Key wrap are as follows: The Plaintext is taken as the 40 bytes described above, the KEK is the value derived from the KDF, and the Default Initial Value is used."

I added a sentence on Default Initial Value.

Here is what the current document says in section 8.

The input to the key wrapping method is the value "m" derived from the session key, as described in section 5.1. Public-Key Encrypted Session Key Packets (Tag 1) of [RFC4880], except, the PKCS#1.5 padding step is omitted.~~The result is padded using the method described in [PKCS5] to the 8-byte granularity.~~For example, a following AES-256 session key, which 32 octets are denoted from k0 to k31, is composed to form the following 40 octet sequence:

09 k0 k1 ... k31 c0 c1 05 05 05 05 05

The octets c0 and c1 above denote the checksum.~~This encoding allows the sender to obfuscate the size of the symmetric encryption key used to encrypt the data.~~For example, assuming that an AES algorithm is used for the session key, the sender MAY use 21, 13, and 5 bytes of padding for AES-128, AES-192, and AES-256, respectively, to provide the same number of octets, 40 total, as an input to the key wrapping method.


By the way, I should have mentioned that the search with Google for "AESWRAP" will bring up the following page with code to implement the key wrapping for this draft:
   http://code.google.com/p/gnupg-ecc/wiki/AESWrap

The following page provides test keys and other practical information to implementers:
   http://sites.google.com/site/brainhub/pgpecckeys


* One cannot we cannot say which key size was used to encrypt the message by looking at RSA or ElGamal encrypted session key. AESWRAP leaks this information when it is tightly encapsulated the session key (this may leak how sensitive a protected document is). There is a description in the same section 8 on how to avoid this leak by padding the payload of AESWRAP to make it always look like an AES-256 session key.

Section 10: The statement "No changes in the format are needed for ECDSA" seems true, but isn't it necessary to describe the Algorithm Specific Fields for ECDSA? Is this actually defined in Section 9?

I intended to say that the format of the (EC)DSA signed message is defined in the RFC4880. It's a pair of r,s integers in both cases. Changes to public keys are needed for both ECDSA and ECDH, defined in section 9.

For internal consistency it might be good to point to section 9.


The design criteria was to keep the message-specific fields as small as possible. This is achieved by placing everything possible into the key structure. Consider that the KDF parameters field (that affects the ECDH) is fixed at key generation.

ECDSA stays the same as DSA, while ECDH needs one additional field with AESWrapped key.

This said, I cannot find of a good way to say "compare this [section 10] to section 9, just above" ( these comments are a design insight, not a spec ).


Section 13: The table of equivalent algorithm strengths seems to match claims in SP800-57-Part1-Rev3-May2011. It would be helpful to reference this document here as a source for the information.

I wanted to convey a statement that ECC==Hash==2*AES (meaning sizes and assuming that 521 ~ 512). As with some of the above issues, is it the right thing to do to add a reference if it can be avoided, given that a presence of a reference suggests that the reader must then study it in order to understand a corresponding statements. Isn't the issue of relative strength well-understood, so that readers that use the current table can look it up?

In my experience, the issue of relative strength has NOT been well-understood over the years, and I believe the NIST document is the first to actually pull it all together.

What stopped me is that this reference points to a draft.


Thanks,
Brian

... --------------070103060502000105020109-- From shawn.emery@oracle.com Thu Apr 12 00:45:20 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 ACADD21F85C5; Thu, 12 Apr 2012 00:45:20 -0700 (PDT) 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 1TdE2rchL9R3; Thu, 12 Apr 2012 00:45:19 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 86C8721F85C4; Thu, 12 Apr 2012 00:45:19 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3C7jHW7017006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Apr 2012 07:45:17 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q3C7jFjw002372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2012 07:45:16 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q3C7jFaO007184; Thu, 12 Apr 2012 02:45:15 -0500 Received: from [10.159.3.153] (/10.159.3.153) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Apr 2012 00:45:15 -0700 Message-ID: <4F8687DA.6020402@oracle.com> Date: Thu, 12 Apr 2012 01:44:26 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.2) Gecko/20120223 Thunderbird/10.0.2 MIME-Version: 1.0 To: secdir@ietf.org References: <4F5321A2.1070504@oracle.com> In-Reply-To: <4F5321A2.1070504@oracle.com> X-Forwarded-Message-Id: <4F5321A2.1070504@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-CT-RefId: str=0001.0A090201.4F86880E.0002,ss=1,re=0.000,fgs=0 Cc: draft-ietf-conex-concepts-uses.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-conex-concepts-uses-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, 12 Apr 2012 07:45:20 -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 informational draft describes use cases for the Congestion Exposure (ConEx) protocol to facilitate efficient traffic management. It also describes the reasoning of using ConEx markings at the IP layer. The security consideration section does exist and defers to the ietf-conex-abstract-mech draft. The security consideration section of ietf-conex-abstract-mech draft defers to section 4.4, which is on auditing. This really should be in its own security consideration section and should extract specific security threats and how they are mitigated. General comments: Not being a ConEx expert, I didn't know what "ConEx markings" really meant when initially reading the abstract. Editorial comments: None. Shawn. -- From jouni.nospam@gmail.com Thu Apr 12 01:06: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 D0CB721F860E; Thu, 12 Apr 2012 01:06:14 -0700 (PDT) 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 bV-yfENyilLE; Thu, 12 Apr 2012 01:06:14 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id E2EB721F8606; Thu, 12 Apr 2012 01:06:13 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so1415734wib.13 for ; Thu, 12 Apr 2012 01:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=IahvXpW+Do4rtjfYKpOoormJbAGw07ReNuUoSKu96V4=; b=gg4xaezvmN1eHz4lpfL56L0Dp+uEFchOEH49ryNoiVeaatlzlM41/3iyqACU4uZtbo gTl0sMFB537euJXzSvtf8xaJAiO+rxW/dd/Fy7XJjbsnMmZGLhnkzopILvNs/hp5YZwI tM2lXtMXI7MYfYBRXeNqA7ZmxiXbbg+ew4AGpWoQHQiLVN1jAbTD3apzjIOSNKV98h11 0nGbadDJYvbC3Y3081utqVlCeKTYHeHAF/TvVrrpHjyeyz90dDofezn5L8QceygWicah mxnCQkoR0RtXEGti7iK1mUpnweFYJEKUUJZlSagkXaIYntB5dnOQGDoY9eyXwsmAq801 geaA== Received: by 10.180.100.2 with SMTP id eu2mr3582986wib.1.1334217973072; Thu, 12 Apr 2012 01:06:13 -0700 (PDT) Received: from [10.17.0.20] ([83.150.126.201]) by mx.google.com with ESMTPS id b3sm50608016wib.4.2012.04.12.01.06.10 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Apr 2012 01:06:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 12 Apr 2012 11:06:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F842937.9050305@isode.com> To: secdir-secretary@mit.edu X-Mailer: Apple Mail (2.1084) Cc: secdir@ietf.org, IESG , Dan Wing , Teemu Savolainen Subject: Re: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.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, 12 Apr 2012 08:06:15 -0000 Hi, On Apr 11, 2012, at 10:39 PM, Samuel Weiler wrote: > On Wed, 11 Apr 2012, jouni korhonen wrote: >=20 >>> I think some Informative references to relevant documents should be = inserted here in order to help readers find relevant information. >>=20 >> Will add references to RFC3315 and RFC3971. >=20 > More generally, please add informative citations to all of the docs = (e.g the ones mentioned in 5.*) -- don't just give us the ID titles, = actually cite them. Ack. - Jouni >=20 > -- Sam >=20 >=20 From jouni.nospam@gmail.com Thu Apr 12 01:11:37 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 3424621F8581; Thu, 12 Apr 2012 01:11:37 -0700 (PDT) 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 JC8hbqdu+QFX; Thu, 12 Apr 2012 01:11:36 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CFF8F21F8576; Thu, 12 Apr 2012 01:11:35 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1147991wgb.13 for ; Thu, 12 Apr 2012 01:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=rOaEkMpMVQV/wt/6KJ/n52Q0T3zAMebITu9U0YYbN7E=; b=RmLsz7lmRZQUl1NdBEwZYVJuxePg0GN/BEs0xVm6fMKbUJEjf03xKQO0owmHs4Lb27 39NMBFoGCUdfyspglImQmFqw7/g2R2BggxlQVWQVpbmfaVFSmzwisrBWvE6YHVh4wOmt 4tLiYBDt3Qq1Iq0Vwh4iWcKeybgrrEcaqppJhTTOtELRCjjZDlmFapZNSOZ9JRH/wr3S cwt9dGBGftbZ7DTtemtZg6jME7ASkuSM7orVU/LZ/v+COZisKWbRrlcuayodiJTuJLIG A8X5VYEINzjRt+G+yrXuXQmxZ+1lV3Pom+GMFHtWXmWCOnygSuzsvoPuoe3KVJPNdBrI CnYQ== Received: by 10.216.132.202 with SMTP id o52mr870455wei.106.1334218294852; Thu, 12 Apr 2012 01:11:34 -0700 (PDT) Received: from [10.17.0.20] ([83.150.126.201]) by mx.google.com with ESMTPS id 17sm52486981wis.0.2012.04.12.01.11.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Apr 2012 01:11:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 12 Apr 2012 11:11:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <05C223A0-61EC-405E-AC27-0CA007902210@gmail.com> References: <4F842937.9050305@isode.com> To: Samuel Weiler X-Mailer: Apple Mail (2.1084) Cc: Teemu Savolainen , IESG , Dan Wing , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.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, 12 Apr 2012 08:11:37 -0000 Hi, On Apr 11, 2012, at 10:45 PM, Samuel Weiler wrote: > Adding my own comments: >=20 > I think there may be a key "con" missing in the discussion of the two = EDNS0 approaches (in 5.2 in 5.3). EDNS0 "stuff", whether flags or = options, are typically hop-by-hop only. That severely limits the = applicability of these approaches. You mean, unless the "EDNS0 capable" DNS64 is the first DNS server the end host talks to, one cannot guarantee the EDNS0 option survives = through all DNS proxies and (caching) servers in between? That would be something to point out.. me thinks. - Jouni >=20 > -- Sam From weiler@watson.org Thu Apr 12 08:25: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 59C4021F8659; Thu, 12 Apr 2012 08:25:31 -0700 (PDT) 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 YjtUO7yrLpaf; Thu, 12 Apr 2012 08:25:31 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id BFFF421F864D; Thu, 12 Apr 2012 08:25:30 -0700 (PDT) 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 q3CFPRLE022625; Thu, 12 Apr 2012 11:25:27 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q3CFPQTJ022611; Thu, 12 Apr 2012 11:25:26 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 12 Apr 2012 11:25:26 -0400 (EDT) From: Samuel Weiler To: jouni korhonen In-Reply-To: <05C223A0-61EC-405E-AC27-0CA007902210@gmail.com> Message-ID: References: <4F842937.9050305@isode.com> <05C223A0-61EC-405E-AC27-0CA007902210@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 12 Apr 2012 11:25:27 -0400 (EDT) Cc: Teemu Savolainen , IESG , Dan Wing , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.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, 12 Apr 2012 15:25:31 -0000 On Thu, 12 Apr 2012, jouni korhonen wrote: > You mean, unless the "EDNS0 capable" DNS64 is the first DNS server the > end host talks to, one cannot guarantee the EDNS0 option survives through > all DNS proxies and (caching) servers in between? Yes, but it's even worse than that: if ANY other nameserver is in between, you likely won't see the option. EDNS0 options are not transitive. -- Sam From Sandra.Murphy@sparta.com Thu Apr 12 09:20: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 684E421F86CB; Thu, 12 Apr 2012 09:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 ulWUFhHyy9QW; Thu, 12 Apr 2012 09:20:05 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0F021F8693; Thu, 12 Apr 2012 09:20:05 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q3CGJw6p011836; Thu, 12 Apr 2012 11:19:58 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q3CGJviK023404; Thu, 12 Apr 2012 11:19:58 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Thu, 12 Apr 2012 12:19:57 -0400 From: "Murphy, Sandra" To: Wesley Eddy , Benoit Claise Thread-Topic: Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT): new (temp) draft? Thread-Index: AQHNF96ejwUj+YcaD0u34eQkYbvUTZaWMHkAgAEoeGg= Date: Thu, 12 Apr 2012 16:19:56 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6F2DD0@Hermes.columbia.ads.sparta.com> References: <20120406144445.4188.3196.idtracker@ietfa.amsl.com> <201204061553.q36FrBRV007699@alpd052.aldc.att.com> <07e001cd14e0$41b408c0$c51c1a40$@olddog.co.uk> <201204080018.q380I1VK007743@alpd052.aldc.att.com> <099701cd15b1$fc18c990$f44a5cb0$@olddog.co.uk> <201204091344.q39Di1rK002725@alpd052.aldc.att.com> <0bea01cd168a$7ed8ae80$7c8a0b80$@juniper.net> <4F8578DE.1020808@cisco.com>,<4F85C96C.4050705@mti-systems.com> In-Reply-To: <4F85C96C.4050705@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Al Morton' , "secdir@ietf.org" , "afarrel@juniper.net" , 'Samuel Weiler' , "ippm-chairs@tools.ietf.org" , 'The IESG' , "adrian@olddog.co.uk" , 'Dan Frost' , "draft-ietf-ippm-rt-loss@tools.ietf.org" Subject: Re: [secdir] Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT): new (temp) draft? 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, 12 Apr 2012 16:20:06 -0000 Dan Frost and I brought up some of the same comments, wrt the active or pas= sive use of the metric and the suggestion of cryptographic hashes to solve = security considerations.=0A= =0A= The latest revision satisfies me.=0A= =0A= There's one question I'm not adequate to address, and I leave it to the aut= hors and ADs to address:=0A= =0A= Although this metric MAY be applicable in=0A= passive measurement as well, discussion of additional considerations=0A= for the passive scenario are beyond the normative scope of this memo.=0A= =0A= Does that "MAY" mean "optional" in the 2119 sense, or "might"/"could" in no= rmal English usage sense? =0A= =0A= It sounds like this is saying "there are considerations if this metric is u= sed in a passive scenario, which we aren't going to discuss, but even so yo= u have the option to use this".=0A= =0A= I don't know what the "additional considerations" would be. If they are co= nsiderations that a measurement implementer should heed, that's not much of= a worry. If they are considerations that impact others, that's more of a = worry. (Section 9.2's discussion of keeping info confidential (for passive= measurements) is an example of considerations that impact others.) =0A= =0A= So I'll leave it to those who know whether that "MAY" is OK or not.=0A= =0A= --Sandy =0A= =0A= ________________________________________=0A= From: Wesley Eddy [wes@mti-systems.com]=0A= Sent: Wednesday, April 11, 2012 2:11 PM=0A= To: Benoit Claise=0A= Cc: afarrel@juniper.net; 'Al Morton'; adrian@olddog.co.uk; 'Samuel Weiler';= 'The IESG'; ippm-chairs@tools.ietf.org; draft-ietf-ippm-rt-loss@tools.ietf= .org; 'Dan Frost'; Murphy, Sandra; secdir@ietf.org=0A= Subject: Re: Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (wi= th DISCUSS and COMMENT): new (temp) draft?=0A= =0A= On 4/11/2012 8:28 AM, Benoit Claise wrote:=0A= > Al, Wes=0A= >=0A= > I want to review this draft before the IESG telechat tomorrow.=0A= > However, it's getting difficult to keep track of the all the changes=0A= > between=0A= > - the posted version 3=0A= > - the diff-03-04 you sent=0A= > - the extra proposal.=0A= >=0A= > What is the best way to proceed?=0A= > - Al, have you kept a temp version with all the changes?=0A= > - Are we shooting for "revised-ID" at the telechat? I could start my= =0A= > review from there=0A= > - Do we want to have a version 4 posted now?=0A= >=0A= > What is the best way to proceed?=0A= =0A= =0A= I noticed Al sent a copy with updates that have been suggested=0A= so far.=0A= =0A= Please feel free to hit the "Defer" button if you don't feel=0A= there's adequate time to review this one; it looks like a busy=0A= telechat agenda this week!=0A= =0A= --=0A= Wes Eddy=0A= MTI Systems=0A= From stephen.farrell@cs.tcd.ie Thu Apr 12 09:21:21 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 EDFE221F86CB; Thu, 12 Apr 2012 09:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 x3u7+d4v2FKE; Thu, 12 Apr 2012 09:21:20 -0700 (PDT) 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 B46D721F8693; Thu, 12 Apr 2012 09:21:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 167CD17147C; Thu, 12 Apr 2012 17:21:19 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334247678; bh=FBQq/f0hLMoR+w z0P70QEPx86p9L6yTeL6avCTH0G4A=; b=6G4yulfDuvHq1P7hIbWLJHv1ePyLvR H5ItJe0wiGyNwWdqJvngIQ80fQs5PwKZUk8eu53aj9EmJP0vLCycSWFcj1/Rami6 +uXph88JYtajtEqeDBjyo2FK7hjUI/kkZ394ZVRL7t28mk1aSnpYU78+pO2cEZnc 7kgerUiVHtN7ASouQSGh2h/Kxm8vKh+1sjSzxFqN7a88skYjbbUxo3jKYKgFibPi qOmPIwnqJOU/5s6rS5KZxXoeJ81sRTGK6C0FlMzqj/DYaWhTefjek4sR01Lv7Hv9 sRyVmMOUwZATfY1FvFyYUW6khUtnSJAM6ie7UVEm42scoawZvVNV7oAw== 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 C-cAxKiPI1WX; Thu, 12 Apr 2012 17:21:18 +0100 (IST) Received: from [10.87.48.3] (unknown [86.45.63.74]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 53FA7171474; Thu, 12 Apr 2012 17:21:12 +0100 (IST) Message-ID: <4F8700F8.4060709@cs.tcd.ie> Date: Thu, 12 Apr 2012 17:21:12 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Murphy, Sandra" References: <20120406144445.4188.3196.idtracker@ietfa.amsl.com> <201204061553.q36FrBRV007699@alpd052.aldc.att.com> <07e001cd14e0$41b408c0$c51c1a40$@olddog.co.uk> <201204080018.q380I1VK007743@alpd052.aldc.att.com> <099701cd15b1$fc18c990$f44a5cb0$@olddog.co.uk> <201204091344.q39Di1rK002725@alpd052.aldc.att.com> <0bea01cd168a$7ed8ae80$7c8a0b80$@juniper.net> <4F8578DE.1020808@cisco.com>, <4F85C96C.4050705@mti-systems.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F2DD0@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6F2DD0@Hermes.columbia.ads.sparta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Al Morton' , "secdir@ietf.org" , Wesley Eddy , "afarrel@juniper.net" , 'Samuel Weiler' , "ippm-chairs@tools.ietf.org" , 'The IESG' , Benoit Claise , "adrian@olddog.co.uk" , 'Dan Frost' , "draft-ietf-ippm-rt-loss@tools.ietf.org" Subject: Re: [secdir] Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT): new (temp) draft? 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, 12 Apr 2012 16:21:21 -0000 Thanks Sandy, I've cleared. S On 04/12/2012 05:19 PM, Murphy, Sandra wrote: > Dan Frost and I brought up some of the same comments, wrt the active or passive use of the metric and the suggestion of cryptographic hashes to solve security considerations. > > The latest revision satisfies me. > > There's one question I'm not adequate to address, and I leave it to the authors and ADs to address: > > Although this metric MAY be applicable in > passive measurement as well, discussion of additional considerations > for the passive scenario are beyond the normative scope of this memo. > > Does that "MAY" mean "optional" in the 2119 sense, or "might"/"could" in normal English usage sense? > > It sounds like this is saying "there are considerations if this metric is used in a passive scenario, which we aren't going to discuss, but even so you have the option to use this". > > I don't know what the "additional considerations" would be. If they are considerations that a measurement implementer should heed, that's not much of a worry. If they are considerations that impact others, that's more of a worry. (Section 9.2's discussion of keeping info confidential (for passive measurements) is an example of considerations that impact others.) > > So I'll leave it to those who know whether that "MAY" is OK or not. > > --Sandy > > ________________________________________ > From: Wesley Eddy [wes@mti-systems.com] > Sent: Wednesday, April 11, 2012 2:11 PM > To: Benoit Claise > Cc: afarrel@juniper.net; 'Al Morton'; adrian@olddog.co.uk; 'Samuel Weiler'; 'The IESG'; ippm-chairs@tools.ietf.org; draft-ietf-ippm-rt-loss@tools.ietf.org; 'Dan Frost'; Murphy, Sandra; secdir@ietf.org > Subject: Re: Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT): new (temp) draft? > > On 4/11/2012 8:28 AM, Benoit Claise wrote: >> Al, Wes >> >> I want to review this draft before the IESG telechat tomorrow. >> However, it's getting difficult to keep track of the all the changes >> between >> - the posted version 3 >> - the diff-03-04 you sent >> - the extra proposal. >> >> What is the best way to proceed? >> - Al, have you kept a temp version with all the changes? >> - Are we shooting for "revised-ID" at the telechat? I could start my >> review from there >> - Do we want to have a version 4 posted now? >> >> What is the best way to proceed? > > > I noticed Al sent a copy with updates that have been suggested > so far. > > Please feel free to hit the "Defer" button if you don't feel > there's adequate time to review this one; it looks like a busy > telechat agenda this week! > > -- > Wes Eddy > MTI Systems > From weiler+secdir@watson.org Thu Apr 12 12:48:54 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 EA58321F86F2 for ; Thu, 12 Apr 2012 12:48:54 -0700 (PDT) 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 QnwbDVwci-2d for ; Thu, 12 Apr 2012 12:48:54 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5FED321F86F4 for ; Thu, 12 Apr 2012 12:48:53 -0700 (PDT) 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 q3CJmrCg066077 for ; Thu, 12 Apr 2012 15:48:53 -0400 (EDT) (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 q3CJmq8c066071 for ; Thu, 12 Apr 2012 15:48:53 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 12 Apr 2012 15:48:52 -0400 (EDT) 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, 12 Apr 2012 15:48:53 -0400 (EDT) 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, 12 Apr 2012 19:48:55 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Julien Laganier is next in the rotation. For telechat 2012-04-26 Reviewer LC end Draft Derek Atkins T 2012-04-16 draft-dbider-sha2-mac-for-ssh-05 Richard Barnes T 2012-03-30 draft-ietf-dhc-dhcpv6-redundancy-consider-02 Donald Eastlake T 2012-04-13 draft-ietf-appsawg-greylisting-06 Phillip Hallam-Baker T 2012-04-18 draft-ietf-ecrit-lost-sync-17 Steve Hanna T 2012-04-12 draft-ietf-emu-chbind-14 Scott Kelly T 2012-04-24 draft-ietf-marf-as-13 Stephen Kent T 2012-04-20 draft-ietf-pkix-pubkey-caps-04 Tero Kivinen T - draft-ietf-sipcore-rfc3265bis-08 Russ Mundy T 2012-03-20 draft-ietf-fecframe-raptor-10 Last calls and special requests: Reviewer LC end Draft Alan DeKok 2012-04-17 draft-claise-export-application-info-in-ipfix-05 Jeffrey Hutzelman 2012-03-21 draft-betts-itu-oam-ach-code-point-04 Jeffrey Hutzelman 2012-04-16 draft-ietf-manet-nhdp-mib-12 Leif Johansson 2012-04-12 draft-ietf-netmod-smi-yang-04 Warren Kumari 2012-04-25 draft-ietf-dane-protocol-19 Tim Polk 2012-03-21 draft-ietf-pwe3-redundancy-bit-06 Joe Salowey 2012-04-18 draft-templin-aero-10 Carl Wallace - draft-ietf-roll-minrank-hysteresis-of-07 Sam Weiler 2012-03-23 draft-sakane-dhc-dhcpv6-kdc-option-14 Klaas Wierenga - draft-ietf-httpbis-p4-conditional-19 Nico Williams - draft-ietf-httpbis-p5-range-19 Tom Yu - draft-ietf-httpbis-p6-cache-19 Glen Zorn - draft-ietf-httpbis-p7-auth-19 From shanna@juniper.net Fri Apr 13 11:26: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 DB2FE11E8093; Fri, 13 Apr 2012 11:26:58 -0700 (PDT) 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=[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 ZXvaor4netaX; Fri, 13 Apr 2012 11:26:57 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3C64421F86F2; Fri, 13 Apr 2012 11:26:47 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKT4hv5l13sTmkwp/fQZFE6Wloboep9Clq@postini.com; Fri, 13 Apr 2012 11:26:57 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 13 Apr 2012 11:26:46 -0700 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; Fri, 13 Apr 2012 14:26:45 -0400 From: Stephen Hanna To: "draft-ietf-emu-chbind@tools.ietf.org" , "secdir@ietf.org" , "ietf@ietf.org" Date: Fri, 13 Apr 2012 14:26:43 -0400 Thread-Topic: secdir review of draft-ietf-emu-chbind-14 Thread-Index: AczSLeo7PTPAq42hRwirXy24basViBG7+UWQ 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 Subject: [secdir] secdir review of draft-ietf-emu-chbind-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: Fri, 13 Apr 2012 18:26:59 -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. I apologize for submitting these comments a day after the IETF LC closed. Other commitments delayed my work. I hope these are still useful. Thanks, Steve ------ secdir review of draft-ietf-emu-chbind-14 This document defines channel bindings for EAP methods, providing a way to address the lying NAS and lying provider problems. Overall, I have no objections to this document. However, I do have some comments. I have divided these comments into substantive and non-substantive ones. Substantive Comments -------------------- In the Introduction, the second paragraph says that the problem "results when the same credentials are used to access multiple services that differ in some interesting property". Do you mean client or server credentials? I think you mean EAP server credentials. Please be more=20 explicit to make this clearer, since many people will assume that you mean client (EAP peer) credentials. If I'm correct and you do mean EAP server credentials, I suggest that you say so in the first sentence of this paragraph and also in the last sentence. In the next paragraph, you give an example where a low security network is used to read email and a high security network is use to access valuable confidential information. A better example would be to use the low security network for web surfing. Reading email can require a lot of security. In the first paragraph of the Problem Statement, the second sentence says "However, when operating in pass-through mode, the EAP server can be far removed from the authenticator." While this is true, I think the more relevant statement here is that the EAP server can be far removed from the EAP peer. This paragraph is all about problems that can arise when parties between the EAP peer and the EAP server (including the authenticator) are malicious or compromised. So the important thing to point out at the start of the paragraph is the large number of parties that may come between the EAP server and the EAP peer. In the second bullet of section 3 (on page 7), the EAP GSS-API mechanism is a good example. However, I wonder if this attack might take a slightly different form. Could the IM server pretend to be the mail server? I think so. That's just one specific example of a relatively untrusted service pretending to be a relatively trusted service. I suggest that you add an example like that since the current language is quite abstract. Overall, I found the document too abstract for my taste. When I read an RFC that's defining a protocol to be implemented, I prefer to read a description of the problem to be solved and then a clear definition of the protocol. This document reads like a combination of an academic paper and a protocol definition. For example, section 4.1 describes two categories of approach to EAP channel bindings: exchanging the actual network information or encoding the network information into a blob that is used to derive EAP session keys. The rest of section 4.1 goes on to discuss the pros and cons of these approaches. Then section 4.2 defines a bunch of requirements for transporting channel bindings in a lower layer's secure association protocol. While that's interesting, the actual protocol defined in this document sends the actual network information in EAP. Why bother spending several pages talking about things that this protocol doesn't actually do? I see several downsides to including that text in this document. First, you're making it harder for the reader to understand what they actually need to do to implement this protocol. You've probably decreased by half the number of people who will actually read all of this document. Second, some people will use that digression to support arguments like ("My incompatible implementation is compliant with RFC XXXX because I encoded the network information into a blob and used that to generate EAP session keys"). IETF is an engineering organization. We should make our specs as clear and simple as possible and no simpler. This document includes lots of interesting theory that's not needed for its purpose. If you're interested in seeing this document widely implemented, I suggest that you remove as much of that as possible and focus the document on explaining the problem and defining a protocol that solves it. Or you can leave it as is. I'm sure some people will implement it. Just not as many. Friendly suggestion. Take it or leave it. In the first paragraph of section 5.1, you say that "the EAP server needs to be able to access information from the AAA server that is utilized during the EAP session and a local database". Which information? A parenthetical example (an e.g.) would help with understanding what you mean. In section 7.1, you explain that this document isn't useful without an accompanying document defining what information should be included in i1 for each lower layer. Are those documents being prepared for all or at least some of the lower layers? I couldn't find any in a quick search. I know we can't wait for everything to be ready but it would be nice to see at least one or two of those documents so that we can have confidence that this protocol can support all the things that those documents will need. In section 7.2, you define a new RADIUS attribute that identifies the EAP lower layer in use. But you say in the first sentence of that section that this attribute is defined to "carry the EAP lower layer". That sounds like all the lower layer traffic will be encapsulated in this attribute and carried in it. I think you should change the word "carry" in that text to "identify". Unless I misunderstood you. As I read section 8, I wonder whether include the User-Name attribute in i2 could open the system up to attacks where an authenticator or intermediate proxy could remove the anonymity of a user who's using a pseudonym for the username by changing the value of the User-Name attribute to the username of the user suspected of being responsible for this authentication. If the channel bindings checks fail, the authenticator will know they were wrong but if the channel bindings checks succeed, the authenticator will have confirmation of the user's identity. I didn't understand that sending i2 from the server to the peer is optional until I got to section 9.1. In section 5.3, you said that "For success, the server returns the attributes that were considered by the server in making the determination that channel bindings are successfully validated". Which of these is right? At the top of page 23, you say that "In many EAP deployments today attacks where one NAS can impersonate another are out of scope." Do you mean that these attacks are generally not considered but they are a potential problem? Or that they are not a problem? I think they are always a possible problem. Even when all the NASes are owned and managed by the same organization that runs the AAA server and no proxies are used, there's still the potential for a NAS to become compromised. So I think you should say these attacks are "not considered although a real concern" not that they are "out of scope". And then the following sentence says that "Channel bindings brings these attacks into scope". Again, I think those attacks are always a potential issue. Channel bindings provide a good way to address them, whereas there were few ways to do so before. Maybe it would be better to say that. In the next paragraph, you say that when cryptographic binding is used in a tunnel method, the MSK is disclosed to the NAS. I don't think that's right. The MSK that's disclosed to the NAS is the one generated by the outer method. The MSK that's used in cryptographic binding is the one that's generated by the inner method. I don't think there's a problem there. Later in that paragraph, you say that an attack where the NAS terminates an EAP tunnel method is not in scope for existing models for cryptographic binding. I think that's wrong also. EAP tunnel methods protect against just this sort of attack. The first step in these methods is for the EAP peer and the EAP server to build a TLS tunnel. This requires the EAP peer to authenticate the EAP server and decide whether it's trusted. If the NAS has credentials that will cause the EAP peer to trust it as an EAP server, a MITM attack is possible. Of course, that's true for any secure communications and it's a very bad situation. That's why the EAP peer must be very careful about who it trusts and how it authenticates them and the EAP server (and any CAs or other TTPs) must also be similarly careful. I don't see that any of this has much to do with channel bindings. Am I missing something here? If so, please explain it. And maybe you can clarify the text so that other folks get it also. In section 9.2, this paragraph appears: Dishonest peers can only manipulate the first message i1 of the channel binding protocol. In this scenario, a peer sends i1' to the server. If i1' is invalid, the channel binding validation will fail. On the other hand if i1' passes the validation, either the original i1 was wrong and i1' corrected the problem or both i1 and i1' constitute valid information. A peer could potentially gain an advantage in auditing or charging if both are valid and information from i1 is used for auditing or charging. Such peers can be detected by including the information in i2 and checking i1 against i2. In the penultimate sentence, I think you mean "information from i1' is used for auditing or charging." There's no problem if information from i1 is used for auditing. If that happens, the bad peer's information is being ignored. That paragraph does make me wonder about another attack that could be enabled by channel bindings. What if a malicious peer gets perfectly good i1 from a NAS but then sends bad i1' to the EAP server with a goal of damaging the reputation of the NAS? The EAP peer could be working for a competitor of the organization that runs the NAS or just be malicious. Is that a valid concern? If so, maybe you should cite it and suggest a countermeasure. In section 9.4, you refer to "the optional result message". I didn't know before this that the result message was optional. Could you make that clear earlier? In the IANA Considerations, you talk about creating a new "EAP Channel Binding Parameters" top level registry. That's fine. But then you talk about a "Channel Binding Codes" registry. Didn't you mean a "sub registry"? If you want the Channel Binding Codes registry to be in the EAP Channel Binding Paramters registry, I think the first one is really a sub registry. Also, you say that "Early allocation is allowed" for that registry. What does that mean? I don't see any description of "early allocation" in RFC 5226. I expect that IANA will want to know what they need to do to provide "early allocation". How early? Etc. In the definition of the "Channel Binding Namespaces" registry, did you want to include a reference column as you did in the "Channel Binding Codes" registry? If so, maybe you should say so. At the end of section 11.1, a sentence says that "Values skipped in the above table are available for assignment." I don't think any values were skipped so I don't think you need that sentence. Appendix A is pretty similar to section 1. Might you be able to merge them somehow? In section A.3, you describe downgrading attacks and how channel bindings can prevent them. However, I think this will only work if the EAP peer rejects all methods that don't include channel bindings. Otherwise, the NAS can just offer an unauthorized EAP method that permits it to obtain the user's credentials and off to the bank. Non-Substantive Comments ------------------------ In the top right header of the first page, the organization for T. Clancy should probably be Virginia Tech not Electrical and Computer Engineering. In the fourth paragraph of the Introduction, I think you should add the word "the" before "lying provider" problem. In the last sentence of that paragraph, I'd suggest adding "also" before "gain access". That should make things clearer. In the first bullet in section 3 (at the bottom of page 6), "virtual Lads" should probably be "virtual LANs". Unless you are talking about some other phenomenon! ;-) In the second paragraph of section 4.3, the phrase "More often it is useful" can be confusing. The word "it" seems to refer to the subject of the previous sentence ("verification of the MAC or IP address of the NAS"). Actually, the word "it" refers to the idea of making policy decisions about services but that idea doesn't appear until later in the sentence. I suggest that you reword the sentence to say "More often the best approach is to make policy decisions [...]". In the first sentence of section 8, the phrase "a AAA Accept- Request messages" can't be right. Is it singular or plural? I think it's plural so the word "a" should be removed. In section 12 (Acknowledgements), I think Sam Hartman's last name should be capitalized. From d3e3e3@gmail.com Sat Apr 14 18:44: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 AF5F721F8693; Sat, 14 Apr 2012 18:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.181 X-Spam-Level: X-Spam-Status: No, score=-104.181 tagged_above=-999 required=5 tests=[AWL=-0.582, 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 shKVNV4tHvtB; Sat, 14 Apr 2012 18:44:13 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A0CBA21F8692; Sat, 14 Apr 2012 18:44:12 -0700 (PDT) Received: by lagj5 with SMTP id j5so3419719lag.31 for ; Sat, 14 Apr 2012 18:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=KwbE8SBvaWGp6MJdMA0aom+4ZD1rLeCEPCKr59s8hCY=; b=XX5HKjsvEp/rRX+XtFyYG6P916xtdWB23+WjezxI/g9vd/5opZ4qypHK2Lr3rz7h2Z P7l4v5YEnx800PCfTqHCRog8Kk4q3fPTrcKHMGBz7Zbngn9QDJ4n+wcu4mYnyE4pcKho OiN6P31nEBx2tJUo5/VHy2rtjB6BQNbbRItewZJRipEqaTpnOm8iF6UFnV78/TQTIDa9 6TJrH++IxWQHhw8WYyI7iiPtWDBm9ZxxQZHq8Mfog5GqYvVR/GS1ZmEbl2T1R4QXukJb bV3HlLgE8m4Gxysddz5deXqlwYUS2hA+ShqMV0Rfi8x2p8pSDXsexcLR2Z24RhttIaa5 GKEA== Received: by 10.152.113.229 with SMTP id jb5mr5933930lab.45.1334454251431; Sat, 14 Apr 2012 18:44:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.162 with HTTP; Sat, 14 Apr 2012 18:43:51 -0700 (PDT) From: Donald Eastlake Date: Sat, 14 Apr 2012 21:43:51 -0400 Message-ID: To: iesg@ietf.org, secdir@ietf.org, draft-ietf-appsawg-greylisting.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [secdir] draft-ietf-appsawg-greylisting-06.txt 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: Sun, 15 Apr 2012 01:44:13 -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. Document editors and WG chairs should treat these comments just like any other last call comments. This document discusses grey listing, the returning of temporary failure codes in some SMTP exchanges with mail sources not known to be good guys, to ameliorate spam. The technique is very much heuristic so security consideration are, reasonably, fairly soft rather than the precise, hard edged formulations of cryptographic security. The discussion of variations in grey listing, typical spammer behavior, and potential spammer countermeasures all seem quite reasonable and complete. I do not think any additional security considerations are required. EDITORIAL In one place the draft says "when delivery of mail is timely." when I think it means "when delivery of mail is time critical." or "when delivery of mail must be timely.". 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 msk@cloudmark.com Sat Apr 14 20:10:55 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 2CF2121F86A4 for ; Sat, 14 Apr 2012 20:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 Lbha+LT7j4ct for ; Sat, 14 Apr 2012 20:10:54 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 805A521F867B for ; Sat, 14 Apr 2012 20:10:54 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id y3Ai1i0010as01C013AiDN; Sat, 14 Apr 2012 20:10:48 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=NYRkJh/4 c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=bYEoYnXPsMsA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=Sp55DQD6M8tC4k8PYxEA:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Sat, 14 Apr 2012 20:10:26 -0700 From: "Murray S. Kucherawy" To: Donald Eastlake , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-appsawg-greylisting.all@tools.ietf.org" Thread-Topic: draft-ietf-appsawg-greylisting-06.txt SECDIR review Thread-Index: AQHNGqlLCHBRX3p6ZkeKUkT2karfFJabNAGw Date: Sun, 15 Apr 2012 03:10:24 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F1E80@exch-mbx901.corp.cloudmark.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334459448; bh=MHuF/g72OGlxzts+G1gqueJqu0f7qTl3a/t3670vvAE=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Mj/MFf0MeRE3+fBQPifX9fQlwtvgKLHpqkYoBomoZ2+RQQiWboEB2xtiyU1IyrFt4 qlvF0KpPyAu2NFghTR5DC8yv/zdbItrn2bnW7zMk6InzPcAqvy5C9ys9FFWAByHJVf QJlwcO21cUbdxJWPsjj+nOZ9SmhOzRiLqfEAT0b4= Subject: Re: [secdir] draft-ietf-appsawg-greylisting-06.txt 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: Sun, 15 Apr 2012 03:10:55 -0000 Hi Donald. Thanks for your review. > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@gmail.com] > Sent: Saturday, April 14, 2012 6:44 PM > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-appsawg-greylisting.all@to= ols.ietf.org > Subject: draft-ietf-appsawg-greylisting-06.txt SECDIR review >=20 > The technique is very much heuristic so security consideration are, > reasonably, fairly soft rather than the precise, hard edged > formulations of cryptographic security. The discussion of variations in > grey listing, typical spammer behavior, and potential spammer > countermeasures all seem quite reasonable and complete. I do not think > any additional security considerations are required. >=20 > EDITORIAL >=20 > In one place the draft says "when delivery of mail is timely." when I > think it means "when delivery of mail is time critical." or "when > delivery of mail must be timely.". Indeed you're right on that point. I'll adjust it after LC closes. Thanks, -MSK From miguel.a.garcia@ericsson.com Mon Apr 16 03:27: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 28AA621F8608; Mon, 16 Apr 2012 03:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 g0ds+kq+hyrB; Mon, 16 Apr 2012 03:27:23 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4EB21F85E6; Mon, 16 Apr 2012 03:27:22 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-6d-4f8bf408e3a9 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0184"; auth=fail (cipher=AES128-SHA) Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0184", Issuer "esessmw0184" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 25.D7.25560.904FB8F4; Mon, 16 Apr 2012 12:27:21 +0200 (CEST) Received: from [159.107.24.207] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012 12:27:20 +0200 Message-ID: <4F8BF405.5030708@ericsson.com> Date: Mon, 16 Apr 2012 12:27:17 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Vincent Roca References: <51DE5E2E-1D51-4025-B55C-4B09EFA62468@inria.fr> In-Reply-To: <51DE5E2E-1D51-4025-B55C-4B09EFA62468@inria.fr> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-chat.all@tools.ietf.org" , IESG IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-simple-chat-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: Mon, 16 Apr 2012 10:27:24 -0000 Hi Vincent. Thanks for your comments. Allow me to reply you inline. On 04/04/2012 15:50, Vincent Roca wrote: > Hello, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > General: > > The authors, in section 11, discuss several simple security issues. > However I have the feeling that there aren't enough details on how to > avoid/mitigate them. Additionally, I'm not sure the section provides a > comprehensive analysis of security aspects. What about intelligent, > more elaborate attacks? > > > Details for section 11 "Security considerations" > --------------------------------------------------------------- > > ** The second paragraph explains several situations where a message can > be sent to several recipients without the sender knowing. It's a good > point to identify this problem, but I'd like to know how it can be > avoided (if possible). Effort was made to lower the barrier of endpoints, so that conference-unaware participants were able to join and still have some basic chat functionality. If possible, we would like to keep this feature. I see a couple of immediate possible solutions: 1) We forbid conference-unaware participants to join the chat room, for example, by accepting the session to a virtual chat room where the only participants is the MSRP switch itself, which sends a message indicating that the client does not support the required features, and disconnects it. This forbids conference-unaware participants joining the chat room, and it is not desirable. 2) We force the MSRP switch to send one or more messages to conference-unaware participants, indicating that this is a chat room, their client does not support all the features, we send the roster as text, and indicate that all messages will be further distributed to the whole chat room. Basically, we tell the user (and not its software) that this is a chat room. If 2 is acceptable, I will go for it. > > ** It is said: > "It's up to the policy of the MSRP > switch if the messages are forwarded to the other participant's in > the chat room using TLS [RFC5246] transport." > > I'm surprised to see that a participant has no way to enforce a secure > end-to-end connection. At a minimum, can the participant know the > situation in order to take a decision? A participant can control if TLS is used between his endpoint and the MSRP switch. But this participant cannot control if the MSRP switch uses TLS to deliver messages to the rest of the participant. This is because each pair of endpoint-MSRPswitch session is independent of each other, so, it is possible for the chat room to have a mixture of secure and non-secure MSRP session. It is possible for an MSRP switch to have a local policy enforcing that TLS will be required for sending/receiving MSRP messages. Since this does not affect interoperability, we haven't mentioned anything, but if you guys feel more comfortable indicating this fact, we can always add a paragraph. > > ** It is said: > "To avoid takeovers the MSRP switch MUST make sure that a nickname is > unique inside a chat room." > > Do you mean the protocol does not guaranty by design that a nickname is > unique at some point of time in a chat room? If this is the case it's > clearly a flaw that should be addressed within the protocol description, > not in the security considerations section. Yes, the selection of a nickname guaranties that a nickname is unique in the chat room. This is described in Section 7.1: The reservation of a nickname can also fail if the value of the Use-Nickname header field of the NICKNAME request is a reserved word (not to be used as a nickname by any user) or that particular value is already in use by another user. In this case the MSRP switch MUST answer the NICKNAME request with a 425 response code. That paragraph you quoted is just implicitly referring to the paragraph that I just quoted. > > Another remark: it's not sufficient to guaranty the uniqueness of the > nickname. Phishing attacks show us that two close URLs can mislead a > user, even if the URLs differ by at least one character. It would be > wiser to recommend that nicknames be significantly different (the MSRP > can probably check the distance between a proposed nickname and those > already registered in the chat session). We can add such paragraph. However, there has been some e-mail discussion on the topic, in conjunction with the internationalization of characters in nicknames. I will point you to a couple of interesting e-mails. Peter Saint-Andre mention here that avoiding confusable nicknames should be optional: http://www.ietf.org/mail-archive/web/simple/current/msg09894.html And in this other e-mail, Peter indicates the confusion that different (but still similar) characters can create http://www.ietf.org/mail-archive/web/simple/current/msg09887.html I believe it is hard, if not impossible, to fight the latter. > > ** last sentence: > The following sentence is a bit strange and unclear: > "If a nickname can be reserved if it previously has been used by another > participant in the chat room, is up to the policy of the chat room." > I suggest: > > NEW: > It is up to the policy of the chat room to determine if a nickname that > has been previously used by another participant of the chat room can > be reserved or not. Absolutely right. Fixed > > ** General: > Several threats are missing in this document. In particular, > what about attacks where some traffic is intercepted and modified > on-the-fly by the attacker? If TLS is used for delivering MSRP messages, then this attack should not be possible. > What about faked messages sent by an > attacker to the MSRP? TLS will also prevent this attack. If TLS is used to transport MSRP messages, then an attacker could not impersonate a participant and inject false messages. > Can a participant use some integrity service? > This is not discussed. Here the solution should either be TLS or S/MIME. For all the threats, remember that this draft builds on MSRP. Therefore, the security considerations of RFC 4975 apply. TLS and S/MIME is discussed in there, and they apply to this draft. > > I'd like to see guidelines on how a participant or MSRP administrator > can define a secure mode of operation. If not possible, I'd like to > see a detailed discussion of existing risks. Can you please elaborate what else on top of RFC 4975 we need to discuss? Are you referring to indicating that it is RECOMMENDED that the MSRP switch only accepts TLS-protected MSRP sessions or is it something else? Thanks for your review. Looking forward to your comments, Miguel > > > Cheers, > > Vincent -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From matthew.bocci@alcatel-lucent.com Mon Apr 16 09:27:36 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 B760311E809D; Mon, 16 Apr 2012 09:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.223 X-Spam-Level: X-Spam-Status: No, score=-108.223 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_BASE64_TEXT=1.753, 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 hRIyfkpggyNR; Mon, 16 Apr 2012 09:27:36 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id C899621F85EF; Mon, 16 Apr 2012 09:27:35 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3GGRXGb022084 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 16 Apr 2012 18:27:33 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 16 Apr 2012 18:27:33 +0200 From: "Bocci, Matthew (Matthew)" To: Radia Perlman , The IESG , "secdir@ietf.org" , "draft-ietf-pwe3-redundancy.all@tools.ietf.org" Date: Mon, 16 Apr 2012 18:27:31 +0200 Thread-Topic: secdir review of draft-ietf-pwe3-redundancy-06 Thread-Index: Ac0b7dMsg1U1ugp0RQC+KHqxcpU9kA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 X-Mailman-Approved-At: Mon, 16 Apr 2012 10:00:46 -0700 Subject: Re: [secdir] secdir review of draft-ietf-pwe3-redundancy-06 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, 16 Apr 2012 16:27:36 -0000 UmFkaWEsDQoNCk1hbnkgdGhhbmtzIGZvciB5b3VyIHJldmlldy4gUGxlYXNlIHNlZSBiZWxvdyBm b3Igc29tZSBjb21tZW50cyBhbmQNCnByb3Bvc2VkIGFtZW5kbWVudHMgdG8gdGhlIGRyYWZ0Lg0K DQpCZXN0IHJlZ2FyZHMsDQoNCk1hdHRoZXcNCg0KT24gMTkvMDMvMjAxMiAyMjoyMiwgIlJhZGlh IFBlcmxtYW4iIDxyYWRpYXBlcmxtYW5AZ21haWwuY29tPiB3cm90ZToNCg0KPkkgaGF2ZSByZXZp ZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MN Cj5vbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nl c3NlZCBieSB0aGUNCj5JRVNHLiAgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmls eSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlDQo+c2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuICBEb2N1 bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0DQo+dGhlc2UgY29tbWVudHMg anVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQo+DQo+VGhpcyBpcyBhIHJl cXVpcmVtZW50cyBkb2N1bWVudCAoaW50ZW5kZWQgYXMgaW5mb3JtYXRpb25hbCkgZm9yIGENCj5y b3V0aW5nIHByb3RvY29sLg0KPg0KPg0KPg0KPkF0IHRoaXMgbGV2ZWwgb2YgYWJzdHJhY3Rpb24s IEkgZG9uqfZ0IHRoaW5rIHRoZXJlIGFyZSBhbnkgaW50ZXJlc3RpbmcNCj5zZWN1cml0eSBpc3N1 ZXMuIFRoZXJlIGFyZSBzb21lIG1lc3NhZ2VzIGluIHRoZSBwcm90b2NvbCB0aGF0IG5lZWQgdG8N Cj5iZSBjb21tdW5pY2F0ZWQgc2VjdXJlbHksIGFuZCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgc2VjdGlvbg0KPnJlZmVyZW5jZXMgc29tZSBvdGhlciBSRkNzIGFuZCBzYXlzIHRoZSBuZXcg bWVzc2FnZXMgd2lsbCCp+GluaGVyaXQgYXQNCj5sZWFzdCB0aGUgc2FtZSBzZWN1cml0eSBwcm9w ZXJ0aWVzqfcgYXMgdGhlIG1lc3NhZ2VzIGluIHRob3NlIG90aGVyDQo+UkZDcy4gSSBkaWRuqfZ0 IGxvb2sgdXAgd2hhdCBraW5kIG9mIHByb3RlY3Rpb24gZXhpc3RlZCB0aGVyZS4NCj4NCj4NCj4N Cj5UaGUgaW50ZXJlc3Rpbmcgcm91dGluZyBwcm90b2NvbCBpc3N1ZSBoYXMgdG8gZG8gd2l0aCBu ZXN0aW5nIG9mDQo+cm91dGluZyBhbGdvcml0aG1zIGFuZCB0aGUgbmVlZGVkIG11bHRpcGxpZXJz IGluIHRpbWVvdXRzLiBJdCB3b3VsZA0KPmFwcGVhciB0aGF0IHBzZXVkby13aXJlcyBydW4gb3Zl ciBhIGNvbnZlbnRpb25hbCByb3V0ZWQgaW5mcmFzdHJ1Y3R1cmUNCj5hbmQgYWxzbyBjb25uZWN0 IHBhcnRzIG9mIGEgY29udmVudGlvbmFsIHJvdXRlZCBpbmZyYXN0cnVjdHVyZS4gVGhlDQo+c3Bl YyBhc3N1bWVzIHRoYXQgZmFpbHVyZXMgd2l0aGluIHRoZSBpbm5lciByb3V0ZWQgaW5mcmFzdHJ1 Y3R1cmUgd2lsbA0KPmhlYWwgdGhlbXNlbHZlcyBxdWlja2x5IGVub3VnaCB0byBub3QgYmUgbm90 aWNlZCBieSB0aGUgcHdlMyByZWR1bmRhbmN5DQo+cHJvdG9jb2wgKGlmIHRoZXkgYXJlIGNhcGFi bGUgb2YgaGVhbGluZyBhdCBhbGwpLCBhbmQgdGhhdCBwc2V1ZG8td2lyZQ0KPmZhaWxvdmVyICh0 cmlnZ2VyZWQgYnkgdGhpcyBpbm5lciBmYWlsdXJlKSB3aWxsIGhhcHBlbiBxdWlja2x5IGVub3Vn aA0KPnRvIG5vdCBkaXNydXB0IHRoZSByb3V0aW5nIHByb3RvY29sIHRoYXQgaXMgcnVubmluZyBv dmVyIHRoZQ0KPnBzZXVkby13aXJlcy4NCj4NCj4NCj4NCj5CdXQgdGhhdCByZXF1aXJlbWVudCBp cyBub3QgZXhwbGljaXRseSBhY2tub3dsZWRnZWQgaW4gdGhlIGRvY3VtZW50LA0KPmFuZCBpdCBp bnR1aXRpdmVseSBzZWVtcyBsaWtlIGEgc2lnbmlmaWNhbnQgY2hhbGxlbmdlLg0KDQpNQj4gTXVs dGktbGF5ZXIgcmVzaWxpZW5jeSBtZWNoYW5pc21zLCB3aGVyZSBwcm90ZWN0aW9uIGlzIHByb3Zp ZGVkIGF0DQptdWx0aXBsZSBuZXN0ZWQgbGV2ZWxzIGFyZSBmYWlybHkgY29tbW9uIGluIHByb3Zp ZGVyIG5ldHdvcmtzLCBidXQgdGhlcmUNCmlzIGluZGVlZCBhbiBhc3N1bXB0aW9uIHRoYXQgbG93 ZXIgbGF5ZXIgcHJvdGVjdGlvbiBtZWNoYW5pc21zIHJlYWN0IGFuZA0KcmVzdG9yZSBtb3JlIHJh cGlkbHkgdGhhbiB0aG9zZSBpbiB0aGUgbmV4dCBoaWdoZXIgbGF5ZXIuIEkgYWdyZWUgdGhhdA0K dGhpcyBpbXBsaWNpdCBhc3N1bXB0aW9uIGlzIHdvcnRoIGFja25vd2xlZGdpbmcgaW4gdGhlIGRy YWZ0LCBhbmQgcHJvcG9zZQ0KbW9kaWZ5aW5nIHRoZSAybmQgcGFyYWdyYXBoIGluIHRoZSBpbnRy b2R1Y3Rpb24gYXMgZm9sbG93czoNCg0KIkluIHNpbmdsZS1zZWdtZW50IFBXIChTUy1QVykgYXBw bGljYXRpb25zLCBwcm90ZWN0aW9uIGZvciB0aGUgUFcgaXMNCiAgIHByb3ZpZGVkIGJ5IHRoZSBQ U04gbGF5ZXIuICBUaGlzIG1heSBiZSBhIFJlc291cmNlIFJlc2VydmF0aW9uDQogICBQcm90b2Nv bCB3aXRoIFRyYWZmaWMgRW5naW5lZXJpbmcgKFJTVlAtVEUpIGxhYmVsZWQgc3dpdGNoZWQgcGF0 aA0KICAgKExTUCkgd2l0aCBhIGZhc3QtUmVyb3V0ZSAoRlJSKSBiYWNrdXAgb3IgYW4gZW5kLXRv LWVuZCBiYWNrdXAgTFNQLiBJdA0KaXMgYXNzdW1lZCB0aGF0IHRoZXNlIG1lY2hhbmlzbXMgY2Fu IHJlc3RvcmUgUFNOIGNvbm5lY3Rpdml0eSByYXBpZGx5DQplbm91Z2ggdG8gYXZvaWQgdHJpZ2dl cmluZyBwcm90ZWN0aW9uIGJ5IFBXIHJlZHVuZGFuY3kuIg0KDQpSZWdhcmRpbmcgeW91ciBzZWNv bmQgcG9pbnQgYWJvdXQgYW4gYXNzdW1wdGlvbiB0aGF0IFBXIHJlZHVuZGFuY3kgd2lsbA0Kc3dp dGNoIG92ZXIgcXVpY2tseSBlbm91Z2ggdGhhdCBhbnkgcm91dGluZyBwcm90b2NvbHMgcnVubmlu ZyBvdmVyIHRoZQ0KZW11bGF0ZWQgc2VydmljZSBwcm92aWRlZCBieSB0aGUgUFcgZG9uJ3Qgbm90 aWNlLCBJIGFtIG5vdCBzdXJlIHRoYXQgdGhhdA0KYXNzdW1wdGlvbiBpcyBhbHdheXMgY29ycmVj dC4gSXQgaXMgY2VydGFpbmx5IHBvc3NpYmxlIHRvIGVuZ2luZWVyIFBXDQpyZWR1bmRhbmN5IHRv IGFjaGlldmUgdGhpcywgYnV0IHRoZXJlIGFyZSBtZWNoYW5pc21zIHRoYXQgaXQgcmVsaWVzIG9u DQooZS5nLiBOYXRpdmUgc2VydmljZSBkdWFsLWhvbWluZyBwcm90b2NvbHMgcnVubmluZyBvbiB0 aGUgQUNzKSB0aGF0IGFyZQ0Kb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIHdvcmsgaW4gUFdFMyB0 aGF0IHdlIGNhbid0IHJlYWxseSBzZXQgYQ0KcGVyZm9ybWFuY2Ugb2JqZWN0aXZlIGZvciBpbiB0 aGlzIGRvY3VtZW50LiBGdXJ0aGVyLCBQV3MgcHJvdmlkZSBhICdnb29kDQplbm91Z2gnIGVtdWxh dGlvbiByYXRoZXIgdGhhbiBhIHBlcmZlY3QgZW11bGF0aW9uIG9mIGEgbmF0aXZlIHNlcnZpY2Ug KGFzDQpkZXRhaWxlZCBpbiB0aGUgUFdFMyBjaGFydGVyKS4gVGhpcyBtZWFucyB0aGF0IHRoZSBl bXVsYXRpb24gbWF5IGJlIGdvb2QNCmVub3VnaCBmb3IgYSBwYXJ0aWN1bGFyIGFwcGxpY2F0aW9u LCBidXQgaXNuJ3QgZ3VhcmFudGVlZCB0byBiZQ0KaW5kaXN0aW5ndWlzaGFibGUgZnJvbSBhIG5l dHdvcmsgYnVpbHQgZW50aXJlbHkgb2YgdGhlIG5hdGl2ZSBzZXJ2aWNlDQp0ZWNobm9sb2d5Lg0K DQoNCj4NCj4NCj4NCj5NaWNyby1sZXZlbCBpc3N1ZXM6DQo+DQo+DQo+DQo+SW4gdGVybWlub2xv Z3kgKHNlY3Rpb24gMiksIHRoZSBQcmltYXJ5IFBXIGlzIGRlZmluZWQgYXMgdGhlIG9uZSB0aGF0 DQo+d2lsbCBiZSB1c2VkIHdoZW4gYW55IG9uZSB3aWxsIGRvLCBhbmQgdGhhdCBpZiBpdCBnb2Vz IGRvd24gYW5kIGNvbWVzDQo+YmFjayB0aGUgUFcgd2lsbCByZXZlcnQgdG8gaXQuIEJ1dCBpdCBh bHNvIGRlZmluZXMgbm9uLXJldmVydGl2ZQ0KPnByb3RlY3Rpb24gc3dpdGNoaW5nIGFzIGFuIG9w dGlvbiB3aGVyZSB0aGUgdHJhZmZpYyB3aWxsIG5vdCBzd2l0Y2gNCj5iYWNrIHRvIHRoZSBwcmlt YXJ5IHVubGVzcyB0aGUgc2Vjb25kYXJ5IGZhaWxzLCBhbmQgaW4gc2VjdGlvbiA0LjEgaXQNCj5z YXlzIHRoYXQgbm9uLXJldmVydGl2ZSBwcm90ZWN0aW9uIE1VU1QgYmUgc3VwcG9ydGVkIGFuZCBy ZXZlcnRpdmUgaXMNCj5vcHRpb25hbC4NCg0KTUI+DQpJIHByb3Bvc2UgbW9kaWZ5aW5nIHRoZSBk ZWZpbml0aW9uIG9mIFByaW1hcnkgYXMgZm9sbG93czoNCm8gIFByaW1hcnkgUFc6IHRoZSBQVyB3 aGljaCBhIFBXIGVuZHBvaW50IGFjdGl2YXRlcyAoaS5lLiB1c2VzIGZvcg0KICAgICAgZm9yd2Fy ZGluZykgaW4gcHJlZmVyZW5jZSB0byBhbnkgb3RoZXIgUFcgd2hlbiBtb3JlIHRoYW4gb25lIFBX DQogICAgICBxdWFsaWZpZXMgZm9yIGFjdGl2ZSBzdGF0ZS4gIFdoZW4gdGhlIHByaW1hcnkgUFcg Y29tZXMgYmFjayB1cA0KICAgICAgYWZ0ZXIgYSBmYWlsdXJlIGFuZCBxdWFsaWZpZXMgZm9yIHRo ZSBhY3RpdmUgc3RhdGUsIHRoZSBQVw0KICAgICAgZW5kcG9pbnQgYWx3YXlzIHJldmVydHMgdG8g aXQuICBUaGUgZGVzaWduYXRpb24gb2YgUHJpbWFyeSBpcw0KICAgICAgcGVyZm9ybWVkIGJ5IGxv Y2FsIGNvbmZpZ3VyYXRpb24gZm9yIHRoZSBQVyBhdCB0aGUgUEUgYW5kIGlzIG9ubHkNCnJlcXVp cmVkIHdoZW4gcmV2ZXJ0aXZlIGJlaGF2aW91ciBpcyB1c2VkLg0KDQoNCj4NCj4NCj4NCj5UeXBv czoNCj4NCj4NCj4NCj5TZWN0aW9uIDQuMToNCj4NCj5iZXN1cHBvcnRlZCAtPiBiZSBzdXBwb3J0 ZWQNCj4NCj5zdXBvcnRlZCAtPiBzdXBwb3J0ZWQNCg0KTUI+IFRoYW5rcw0KDQo+DQo+DQo+DQo+ U2VjdGlvbiA0LjI6DQo+DQo+T3JwaGFuZWQgYnVsbGV0DQoNCk1CPiBUaGFua3MNCg0KDQoNCg== From derek@ihtfp.com Mon Apr 16 14:01:01 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 D667711E808A; Mon, 16 Apr 2012 14:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.957 X-Spam-Level: X-Spam-Status: No, score=-101.957 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, 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 umGi5Zp92ncj; Mon, 16 Apr 2012 14:01:01 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 476E611E8089; Mon, 16 Apr 2012 14:01:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 963262602A6; Mon, 16 Apr 2012 17:01:00 -0400 (EDT) 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 17124-06; Mon, 16 Apr 2012 17:00:59 -0400 (EDT) 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 434342602A5; Mon, 16 Apr 2012 17:00:59 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q3GL0vrq014605; Mon, 16 Apr 2012 17:00:57 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Mon, 16 Apr 2012 17:00:55 -0400 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: ietf-ssh2@denisbider.com, mdb@juniper.net Subject: [secdir] sec-dir review of draft-dbider-sha2-mac-for-ssh-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: Mon, 16 Apr 2012 21:01:02 -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 memo defines algorithm names and parameters for use of some of the SHA-2 family of secure hash algorithms for data integrity verification in the Secure Shell (SSH) protocol. It also updates RFC4253 by specifying a new RECOMMENDED data integrity algorithm. I see no issues with this draft -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nurit.sprecher@nsn.com Tue Apr 17 00:18: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 E338E21F84F8 for ; Tue, 17 Apr 2012 00:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 RRj4d6fd9Tiu for ; Tue, 17 Apr 2012 00:18:28 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id BC93021F84FF for ; Tue, 17 Apr 2012 00:18:27 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q3H7Haw7009532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Apr 2012 09:17:36 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q3H7HTce010560; Tue, 17 Apr 2012 09:17:33 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Apr 2012 09:16:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1C6A.12B6A32A" Date: Tue, 17 Apr 2012 09:16:56 +0200 Message-ID: In-Reply-To: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-mpls-tp-oam-analysis-08 Thread-Index: AQHNCYTfIZ8uMvCtg0mge42m/0NwfZadxfiA References: A From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Tina TSOU" X-OriginalArrivalTime: 17 Apr 2012 07:16:57.0590 (UTC) FILETIME=[13158160:01CD1C6A] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 42319 X-purgate-ID: 151667::1334647056-00003570-09BCA762/0-0/0-0 X-Mailman-Approved-At: Tue, 17 Apr 2012 10:24:15 -0700 Cc: draft-ietf-mpls-tp-oam-analysis@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-mpls-tp-oam-analysis-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, 17 Apr 2012 07:18:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1C6A.12B6A32A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tina hi, Thank you for your review. Please see inline. Best regards, Nurit =20 -----Original Message----- From: ext Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]=20 Sent: Saturday, March 24, 2012 8:11 AM To: secdir@ietf.org; draft-ietf-mpls-tp-oam-analysis@tools.ietf.org Subject: secdir review of draft-ietf-mpls-tp-oam-analysis-08 =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 Some comments which may not be from security aspects only are below. =20 1) One missing OAM function =20 I compared the OAM functions listed in this draft and those required in RFC5860 and find out one OAM function named Client Failure Indication (Section 2.2.10 of [RFC 5860]) is missing. I cannot see a reason for this. Since this is an informational analysis document, it is recommended to give a whole view. Specific clarifications are appreciated in the document.=20 =20 this document provides an overview of the MPLS-TP OAM tools that are specified in separate RFCs. It was agreed by the working group that the final version of this document refers to RFCs only. draft-ietf-mpls-tp-csf on "Indication of Client Failure in MPLS-TP" was expired on September 2011, hence we cannot refer to this document.=20 Please note also that although the name of the FILE may confuse, this document does not make any analysis but rather presents an overview of the OAM tools. The purpose of the document is carried in the document TITLE and Abstract/Introduction. \ =20 =20 2) Lack of analysis about the compatibility with existing tools =20 It is said in this document that compatibility with the existing tools has been maintained. But there is no detailed analysis which IMHO might be of great interest to the industry and should form an important part of this analysis document. =20 =20 As mentioned above, the purpose of the document is to provide an overview of the MPLS-TP OA tools. It is not a detailed analysis of the tools.=20 Still, I think your idea is excellent, and may be a subject for another I-D. \ =20 3) 1.1 Scope =20 In the middle of this section, under the "three objectives", the first bullet reads =20 =20 o The OAM toolset should be developed based on existing MPLS architecture, technology, and toolsets. =20 However, in the following paragraph it is written as =20 o ITU-T OAM for Ethernet toolset as defined in [Y.1731]. This has been used for functionality guidelines for the performance measurement tools that were not previously supported in MPLS. =20 There seem to be conflicts between the objective (should...existing MPLS....)=20 I am afraid I cannot see the conflict between the sentences....I consulted with some colleagues and they could not see the conflict as well. \ and the toolset development (...tools...not...supported in MPLS). [RFC 5860] says that "...the MPLS-TP design, SHOULD as far as reasonably possible, reuse existing MPLS standards." which looks more appropriate to me as the objective. Please clarify this point. =20 =20 4) 1.1 Scope =20 The third one of the "three objectives" in this draft reads=20 =20 o The OAM toolset developed for MPLS based transport networks needs to be fully inter-operable with existing MPLS OAM tools as documented in [RFC 5860]. =20 I may be wrong but I find [RFC 5860] only requires OAM interoperability between distinct domains (w/wo IP capabilities). The original description is as follows: =20 It is REQUIRED that OAM interoperability is achieved between distinct domains materializing the environments described in Section 2.1.4. My understanding of the "OAM interoperability" mentioned here refers to MPLS-TP OAM interoperable in different domains, but not MPLS-TP OAM and MPLS OAM interoperability.=20 =20 Section 2.1.4 to which you refer in your quote, discusses the environments.=20 "There are environments where IP capabilities are present in the data plane. IP/MPLS environments are examples of such environments....". RFC 5860 continues to require that "When MPLS-TP is run with IP routing and forwarding capabilities, it MUST be possible to operate any of the existing IP/MPLS and PW OAM protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [5], and VCCV-BFD [14])." \ =20 =20 5) MPLS-TP v.s. MPLS based transport networks The draft uses both "MPLS-TP" and "MPLS based transport networks". E.g. is it "MPLS-TP OAM" or OAM toolset developed for MPLS based transport networks?=20 Are they the same? Or what is the relationship between them? =20 thank you for catching this. We will clarify that they are the same. \=20 =20 Tina =20 =20 =20 =20 ------_=_NextPart_001_01CD1C6A.12B6A32A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tina = hi,

Thank you for your = review.

Please see inline.

Best = regards,

Nurit

 

-----Original = Message-----
From: ext Tina TSOU = [mailto:Tina.Tsou.Zouting@huawei.com]
Sent: Saturday, March 24, 2012 = 8:11 AM
To: secdir@ietf.org; = draft-ietf-mpls-tp-oam-analysis@tools.ietf.org
Subject: secdir review = of draft-ietf-mpls-tp-oam-analysis-08

 

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.

 

Some comments = which may not be from security aspects only are = below.

 

1) One missing OAM = function

 

I compared the OAM = functions listed in this draft and those required in RFC5860 and find = out one OAM function named Client Failure Indication (Section 2.2.10 of = [RFC 5860]) is missing. I cannot see a reason for this. Since this is an = informational analysis document, it is recommended to give a whole view. = Specific clarifications are appreciated in the document. =

 

<Nurit> this = document provides an overview of the MPLS-TP OAM tools that are = specified in separate RFCs. It was agreed by the working group that the = final version of this document refers to RFCs only. draft-ietf-mpls-tp-csf on = “Indication of Client Failure in MPLS-TP” was expired on = September 2011, hence we cannot refer to this document. =

Please note also that although the name of = the FILE may confuse, this document does not make any analysis but = rather presents an overview of the OAM tools. The purpose of the = document is carried in the document TITLE and Abstract/Introduction. = \<Nurit>

 

 

2) Lack of = analysis about the compatibility with existing = tools

 

It is said in this = document that compatibility with the existing tools has been maintained. = But there is no detailed analysis which IMHO might be of great interest = to the industry and should form an important part of this analysis = document.

 

<Nurit> =

As mentioned above, the purpose of the = document is to provide an overview of the MPLS-TP OA tools. It is not a = detailed analysis of the tools.

Still, I think = your idea is excellent, and may be a subject for another I-D. = \<Nurit>

 

3) 1.1 = Scope

 

In the middle of = this section, under the "three objectives", the first bullet = reads  =

 

   o  The OAM toolset should be = developed based on existing MPLS

      = architecture, technology, and toolsets.

 

However, in the = following paragraph it is written as

 

   o  ITU-T OAM for Ethernet toolset = as defined in [Y.1731].  = This has

      been = used for functionality guidelines for the = performance

      = measurement tools that were not previously supported in = MPLS.

 

There seem to be = conflicts between the objective (should...existing MPLS....) =

<Nurit> I am afraid I cannot see the = conflict between the sentences….I consulted with some colleagues = and they could not see the conflict as well. = \<Nurit>

and the toolset development = (...tools...not...supported in MPLS). [RFC 5860] says that "...the = MPLS-TP design, SHOULD as far as reasonably possible, reuse existing = MPLS standards." which looks more appropriate to me as the = objective. Please clarify this point.

 

 

4) 1.1 = Scope

 

The third one of = the "three objectives" in this draft reads =

 

   o  The OAM toolset developed for = MPLS based transport networks needs

      to be = fully inter-operable with existing MPLS OAM tools = as

      = documented in [RFC 5860].

 

I may be wrong but = I find [RFC 5860] only requires OAM interoperability between distinct = domains (w/wo IP capabilities). The original description is as = follows:

 

   It is REQUIRED that OAM = interoperability is achieved between distinct

   domains materializing the = environments described in Section 2.1.4.

=

My understanding of the "OAM = interoperability" mentioned here refers to MPLS-TP OAM = interoperable in different domains, but not MPLS-TP OAM and MPLS OAM = interoperability.

 

<Nurit> =
Section 2.1.4 to which you refer in your quote, discusses the =
environments. 
“There =
are environments where IP capabilities are present in the data =
plane.  IP/MPLS =
environments are examples of such =
environments….”.
RFC 5860 =
continues to require that “When MPLS-TP is run with IP routing and =
forwarding capabilities, it MUST be possible to operate any of the =
existing IP/MPLS and PW OAM protocols (e.g., LSP-Ping [4], MPLS-BFD =
[13], VCCV [5], and VCCV-BFD [14]).”
\<Nurit><=
/span>

 

 

5) MPLS-TP v.s. = MPLS based transport networks

The draft uses = both "MPLS-TP" and "MPLS based transport networks". = E.g. is it "MPLS-TP OAM" or OAM toolset developed for MPLS = based transport networks?

Are they the same? = Or what is the relationship between them?

 

<Nurit> = thank you for catching this. We will clarify that they are the same. = \<Nurit>

 

Tina

 

 

 

 

------_=_NextPart_001_01CD1C6A.12B6A32A-- From new-work-bounces@ietf.org Tue Apr 17 09:41:47 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 8B38711E80A3; Tue, 17 Apr 2012 09:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334680907; bh=J/V904YAgbMHfi0Jc58hG0ZoOXYIxTt8/QbNKsPBf4E=; h=MIME-Version:From:To:Message-ID:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=w+wA1qrLlgW2MWYLPP7zgdQePVUpmTi0GyyKbZljKBeZXng/ZswDSEKV5Ysw9lzA3 N3Kfsv4X45/BJ8UWyqXo4CtoFm9Ve9hPFZCVOKZGP/JidhzB4plYwCLkBw7VxRfds0 /bLaSZjJRW7gV3fr3zyxnz6ryK/YkC+fkFeIKV48= 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 4694B11E80A3; Tue, 17 Apr 2012 09:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 iE4qRH6LJ0kf; Tue, 17 Apr 2012 09:41:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F5111E8080; Tue, 17 Apr 2012 09:41:45 -0700 (PDT) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120417164145.20359.45106.idtracker@ietfa.amsl.com> Date: Tue, 17 Apr 2012 09:41:45 -0700 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, 17 Apr 2012 10:24:15 -0700 Subject: [secdir] [new-work] WG Review: sunset4 (sunset4) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 16:41:47 -0000 A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, April 24, 2012. sunset4 (sunset4) ----------------------------------------- Status: Proposed Working Group Last Updated: 2012-04-13 Chairs: TBD Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Area Advisors: OPS: TSV: RTG: Mailing Lists: Description of Working Group: The IETF is committed to the deployment of IPv6 to ensure the evolution of the Internet. However, the IPv4-only components of the Internet must continue to operate as much as possible during the transition from IPv4 to IPv6. The Working Group will standardize technologies that facilitate the graceful sunsetting of the IPv4 Internet in the context of the exhaustion of IPv4 address space while IPv6 is deployed. These technologies will likely be less optimal than equivalent technologies for IPv6-only and dual-stack networks. The Working Group works only on IPv4 protocols to facilitate IPv4 sunsetting. The Working Group may work on fixing security bugs in existing IPv4-specific protocols but is not chartered to add new security functionality to those protocols. The working group will provide a single venue for the consideration of IPv4 sunsetting, while ensuring that any such technologies do not impede the deployment of IPv6 and do not duplicate functions and capabilities already available in existing technologies. Therefore, along the lines of draft-george-ipv6-support, before the working group adopts any technology, it must: 1) describe the problem to be solved and show that there is widespread demand for a solution 2) demonstrate that the problem can not be solved with existing technologies 3) provide a description of the proposed solution along with the impact on current IPv4-only use and its ability to promote the deployment of IPv6 These steps will likely be described in the form of a use case and requirements document. Only after the above mentioned steps have been completed and the results accepted by the community will the IETF consider adding new work items to the Working Group charter. This new work may include protocol specifications. The work spans over multiple IETF areas including as Internet, Operations, Transport and Routing. Therefore, cross-area coordination and support is essential and required. Any work on IPv4 to IPv6 transition methods is out of scope. The initial work items are: * Review current CGN documents, including requirements for standardization, and determine is CGN is a suitable sunsetting technology to become a work item * Gap analysis of IPv4 features to facilitate IPv4 sunsetting Milestones 2012-09 Complete review of CGN and, if necessary, propose CGN work items 2013-06 Send gap analysis on IPv4 sunsetting to IESG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Apr 17 09:47:59 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 5085D11E80CE; Tue, 17 Apr 2012 09:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334681279; bh=GWK3Re4c8u5welztv2ChSGLwtJssAKOcHjpIHB5fQFk=; h=MIME-Version:From:To:Message-ID:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=V7SiWMu/+SXbOTNgPrUv07VfO8LuyhdTbROnnRInYYd4UQxLgmrIr0pG0OVLAoUOX 82UfvXCHu/3Uw2KMaRyWPPxMYq5Uk0TlyXFePL1XvJwoOiQO1OopRWC646YObyd7Oj aG40hWu2x3lN6bcAIvtiHSlk7ACIC6bTpqx4TIwo= 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 9E40911E80CE; Tue, 17 Apr 2012 09:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 yqHsrjbrPGsC; Tue, 17 Apr 2012 09:47:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754BC11E80CC; Tue, 17 Apr 2012 09:47:58 -0700 (PDT) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120417164758.21917.5204.idtracker@ietfa.amsl.com> Date: Tue, 17 Apr 2012 09:47:58 -0700 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, 17 Apr 2012 10:24:15 -0700 Subject: [secdir] [new-work] WG Review: Network Virtualization Overlays (nvo3) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 16:47:59 -0000 A new IETF working group has been proposed in the Routing Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, April 24, 2012. Network Virtualization Overlays (nvo3) ----------------------------------------- Status: Proposed Working Group Last Updated: 2012-04-13 Chair(s): TBD Routing Area Director(s): Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Internet Area Advisor: TBD Operations Area Advisor: TBD Mailing Lists: Address: nvo3@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/nvo3 Archive: http://www.ietf.org/mail-archive/web/nvo3/ Description of Working Group: Support for multi-tenancy has become a core requirement of data centers (DCs), especially in the context of data centers supporting virtualized hosts known as virtual machines (VMs). Two key requirements needed to support multi-tenancy are traffic isolation, so that a tenant's traffic is not visible to any other tenant, and address independence, so that one tenant's addressing does not collide with other tenants addressing schemes or with addresses used within the data center itself. Another key requirement is to support the placement and migration of VMs anywhere within the data center, without being limited by DC network constraints such as the IP subnet boundaries of the underlying DC network. An NVO3 solution (known here as a Data Center Virtual Private Network (DCVPN)) is a VPN that is viable across a scaling range of a few thousand VMs to several million VMs running on greater than 100K physical servers. It thus has good scaling properties from relativly small networks to networks with several million DCVPN endpoints and hundreds of thousands DCVPNs within a single administrative domain. Note that although this charter uses the term VM throughout, NVO3 must also support connectivity to traditional hosts e.g. hosts that do not have hypervisors. NVO3 will develop an approach to multi-tenancy that uses a Layer 3 encapsulation rather than relying on traditional L2 isolation mechanisms (e.g., VLANs) to support multi-tenancy. The approach will provide an emulated Ethernet service capable of satisfying typical data center deployments. NVO3 will document the problem statement, the applicability, and an architectural framework for DCVPNs within a data center environment. Within this framework, functional blocks will be defined to allow the dynamic attachment / detachment of VMs to their DCVPN, and the interconnection of elements of the DCVPNs over the underlying physical network. This will support delivery of packets to the destination VM, and provide the network functions required for the migration of VMs within the network in a sub-second timeframe. Based on this framework, the WG will develop requirements for both control plane protocol(s) and data plane encapsulation format(s), and perform a gap analysis of existing candidate mechanisms. In addition to functional and architectural requirements, NVO3 will develop management, operational, OAM, maintenance, troubleshooting, and security requirements. The WG will investigate the interconnection of the DCVPNs and their tenants with non-NVO3 IP network(s) to determine if any specific work is needed. The NVO3 will write the following informational RFCs, which must be substantially complete before rechartering can be considered: Problem Statement Framework document Control plane requirements document Data plane requirements document Operational Requirements Gap Analysis Driven by the requirements and consistent with the gap analysis, the WG may request being rechartered to document solutions consisting of one or more data plane encapsulations and control plane protocols as applicable. Any documented solutions will use existing mechanisms if suitable, or will develop new mechanisms if necessary. If the WG anticipates the adoption of the technologies of another SDO, such as the IEEE, as part of the solution, it will liaise with that SDO to ensure the compatibility of the approach. Milestones: Dec 2012 Problem Statement submitted for IESG review Dec 2012 Framework document submitted for IESG review Dec 2012 Control plane requirements submitted for IESG review Dec 2012 Data plane requirements submitted for IESG review Dec 2012 Operational Requirements submitted for IESG review Dec 2012 Gap Analysis submitted for IESG review Dec 2012 Recharter or close Working Group _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From weiler+secdir@watson.org Sun Apr 22 04:15: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 5503421F8637 for ; Sun, 22 Apr 2012 04:15:34 -0700 (PDT) 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 q2iI9fMIufkX for ; Sun, 22 Apr 2012 04:15:33 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0C85221F85FB for ; Sun, 22 Apr 2012 04:15:32 -0700 (PDT) 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 q3MBFTq8025380 for ; Sun, 22 Apr 2012 07:15:30 -0400 (EDT) (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 q3MBFTQp025377 for ; Sun, 22 Apr 2012 07:15:29 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sun, 22 Apr 2012 07:15:29 -0400 (EDT) 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]); Sun, 22 Apr 2012 07:15:30 -0400 (EDT) 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: Sun, 22 Apr 2012 11:15:34 -0000 Catherine Meadows is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2012-04-26 Reviewer LC end Draft Richard Barnes T 2012-03-30 draft-ietf-dhc-dhcpv6-redundancy-consider-02 Phillip Hallam-Baker T 2012-04-18 draft-ietf-ecrit-lost-sync-17 Leif Johansson T 2012-04-12 draft-ietf-netmod-smi-yang-05 Scott Kelly T 2012-04-24 draft-ietf-marf-as-14 Tero Kivinen T - draft-ietf-sipcore-rfc3265bis-08 Julien Laganier T 2012-04-20 draft-ietf-pkix-pubkey-caps-04 Russ Mundy T 2012-03-20 draft-ietf-fecframe-raptor-10 Joe Salowey T 2012-04-18 draft-templin-aero-10 For telechat 2012-05-10 Reviewer LC end Draft Stephen Kent T - draft-ietf-appsawg-mime-default-charset-02 Warren Kumari T 2012-05-02 draft-ietf-appsawg-about-uri-scheme-04 Chris Lonvick T 2012-05-02 draft-ietf-mboned-mcaddrdoc-03 Last calls and special requests: Reviewer LC end Draft Alan DeKok 2012-04-17 draft-claise-export-application-info-in-ipfix-05 Jeffrey Hutzelman 2012-03-21 draft-betts-itu-oam-ach-code-point-04 Jeffrey Hutzelman 2012-04-16 draft-ietf-manet-nhdp-mib-12 Barry Leiba 2012-04-25 draft-ietf-dane-protocol-19 Matt Lepinski 2012-05-02 draft-ietf-mboned-64-multicast-address-format-01 Tim Polk 2012-03-21 draft-ietf-pwe3-redundancy-bit-06 Carl Wallace - draft-ietf-roll-minrank-hysteresis-of-08 Sam Weiler 2012-03-23 draft-sakane-dhc-dhcpv6-kdc-option-14 Klaas Wierenga - draft-ietf-httpbis-p4-conditional-19 Nico Williams - draft-ietf-httpbis-p5-range-19 Tom Yu - draft-ietf-httpbis-p6-cache-19 Glen Zorn - draft-ietf-httpbis-p7-auth-19 From Tina.Tsou.Zouting@huawei.com Sun Apr 22 07:45:26 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 B5B5721F859B for ; Sun, 22 Apr 2012 07:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=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 VcMPIszNJlb9 for ; Sun, 22 Apr 2012 07:45:25 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2C71B21F859F for ; Sun, 22 Apr 2012 07:45:25 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFK87828; Sun, 22 Apr 2012 10:45:24 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 22 Apr 2012 07:43:48 -0700 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 22 Apr 2012 07:43:46 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.22]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Sun, 22 Apr 2012 22:43:40 +0800 From: Tina TSOU To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" Thread-Topic: secdir review of draft-ietf-mpls-tp-oam-analysis-08 Thread-Index: AQHNCYTfIZ8uMvCtg0mge42m/0NwfZadxfiAgAlTmwg= Date: Sun, 22 Apr 2012 14:43:40 +0000 Message-ID: <03265FE8-42A2-4C50-AEDA-BFED8FCCF076@huawei.com> References: A, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_03265FE842A24C50AEDABFED8FCCF076huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-mpls-tp-oam-analysis@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-mpls-tp-oam-analysis-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: Sun, 22 Apr 2012 14:45:26 -0000 --_000_03265FE842A24C50AEDABFED8FCCF076huaweicom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Nurit, Thank u for ur reply, comments are in line. Have a good weekend. Sent from my iPad On Apr 17, 2012, at 12:18 AM, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" > wrote: Tina hi, Thank you for your review. Please see inline. Best regards, Nurit -----Original Message----- From: ext Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com] Sent: Saturday, March 24, 2012 8:11 AM To: secdir@ietf.org; draft-ietf-mpls-tp-oam-analysi= s@tools.ietf.org Subject: secdir review of draft-ietf-mpls-tp-oam-analysis-08 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 com= ments 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. Some comments which may not be from security aspects only are below. 1) One missing OAM function I compared the OAM functions listed in this draft and those required in RFC= 5860 and find out one OAM function named Client Failure Indication (Section= 2.2.10 of [RFC 5860]) is missing. I cannot see a reason for this. Since th= is is an informational analysis document, it is recommended to give a whole= view. Specific clarifications are appreciated in the document. this document provides an overview of the MPLS-TP OAM tools that ar= e specified in separate RFCs. It was agreed by the working group that the f= inal version of this document refers to RFCs only. draft-ietf-mpls-tp-csf o= n =93Indication of Client Failure in MPLS-TP=94 was expired on September 20= 11, hence we cannot refer to this document. Please note also that although the name of the FILE may confuse, this docum= ent does not make any analysis but rather presents an overview of the OAM t= ools. The purpose of the document is carried in the document TITLE and Abst= ract/Introduction. \ If there is no RFC to refer at the moment (perhaps FFS?), you may just refl= ect the simple fact in the document. This is also the purpose of an overvie= w to let people know what is done and what is missing. I still prefer to match the analysis or overview with the requirement RFC r= eferenced in this document. 2) Lack of analysis about the compatibility with existing tools It is said in this document that compatibility with the existing tools has = been maintained. But there is no detailed analysis which IMHO might be of g= reat interest to the industry and should form an important part of this ana= lysis document. As mentioned above, the purpose of the document is to provide an overview o= f the MPLS-TP OA tools. It is not a detailed analysis of the tools. Still, I think your idea is excellent, and may be a subject for another I-D= . \ OK. 3) 1.1 Scope In the middle of this section, under the "three objectives", the first bull= et reads o The OAM toolset should be developed based on existing MPLS architecture, technology, and toolsets. However, in the following paragraph it is written as o ITU-T OAM for Ethernet toolset as defined in [Y.1731]. This has been used for functionality guidelines for the performance measurement tools that were not previously supported in MPLS. There seem to be conflicts between the objective (should...existing MPLS...= .) I am afraid I cannot see the conflict between the sentences=85.I co= nsulted with some colleagues and they could not see the conflict as well. \= and the toolset development (...tools...not...supported in MPLS). [RFC 5860= ] says that "...the MPLS-TP design, SHOULD as far as reasonably possible, r= euse existing MPLS standards." which looks more appropriate to me as the ob= jective. Please clarify this point. My concern is that the objective in this document is not exactly the same a= s in RFC5860. It is proposed to keep aligned. 4) 1.1 Scope The third one of the "three objectives" in this draft reads o The OAM toolset developed for MPLS based transport networks needs to be fully inter-operable with existing MPLS OAM tools as documented in [RFC 5860]. I may be wrong but I find [RFC 5860] only requires OAM interoperability bet= ween distinct domains (w/wo IP capabilities). The original description is a= s follows: It is REQUIRED that OAM interoperability is achieved between distinct domains materializing the environments described in Section 2.1.4. My understanding of the "OAM interoperability" mentioned here refers to MPL= S-TP OAM interoperable in different domains, but not MPLS-TP OAM and MPLS O= AM interoperability. Section 2.1.4 to which you refer in your quote, discusses the envir= onments. =93There are environments where IP capabilities are present in the data pla= ne. IP/MPLS environments are examples of such environments=85.=94. RFC 5860 continues to require that =93When MPLS-TP is run with IP routing a= nd forwarding capabilities, it MUST be possible to operate any of the exist= ing IP/MPLS and PW OAM protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [= 5], and VCCV-BFD [14]).=94 \ 5) MPLS-TP v.s. MPLS based transport networks The draft uses both "MPLS-TP" and "MPLS based transport networks". E.g. is = it "MPLS-TP OAM" or OAM toolset developed for MPLS based transport networks= ? Are they the same? Or what is the relationship between them? thank you for catching this. We will clarify that they are the same= . \ Tina --_000_03265FE842A24C50AEDABFED8FCCF076huaweicom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Nurit,
Thank u for ur reply, comments are in line.
Have a good weekend.

Sent from my iPad

On Apr 17, 2012, at 12:18 AM, "Sprecher, Nurit (NSN - IL/Hod HaSharon)= " <nurit.sprecher@nsn.com= > wrote:

Tina hi,

Thank you for yo= ur review.

Please see inlin= e.

Best regards,

Nurit=

 

-----Original Message-----
From: ext Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]
Sent: Saturday, March 24, 2012 8:11 AM
To: secdir@ietf.org; draft-ietf-mpls-tp-oam-analysis@tools.ietf.org
Subject: secdir review of draft-ietf-mpls-tp-oam-analysis-08

 

I have reviewed = this document as part of the security directorate's ongoing effort to revie= w all IETF documents being processed by the IESG. These comments were writt= en primarily for the benefit of the security area directors.  Doc= ument editors and WG chairs should treat these comments just like any other= last call comments.

 

Some comments wh= ich may not be from security aspects only are below.

 

1) One missing O= AM function

 

I compared the O= AM functions listed in this draft and those required in RFC5860 and find ou= t one OAM function named Client Failure Indication (Section 2.2.10 of [RFC = 5860]) is missing. I cannot see a reason for this. Since this is an informational analysis document, it is recommen= ded to give a whole view. Specific clarifications are appreciated in the do= cument.

 

<Nurit> th= is document provides an overview of the MPLS-TP OAM tools that are specifie= d in separate RFCs. It was agreed by the working group that the final versi= on of this document refers to RFCs only. draft-ietf<= /span>-mpls-tp-= csf on =93Indication of Client Failure in MPLS-TP=94 was expired on September = 2011, hence we cannot refer to this document.

Please note also= that although the name of the FILE may confuse, this document does not mak= e any analysis but rather presents an overview of the OAM tools. The purpos= e of the document is carried in the document TITLE and Abstract/Introduction. \<Nurit>

If there is no RFC to refer at the moment (perhaps= FFS?), you may just reflect the simple fact in the document. This is also = the purpose of an overview to let people know what is done and what is missing.

 

I still prefer to match the analysis or overview w= ith the requirement RFC referenced in this document. 

 

 

2) Lack of analy= sis about the compatibility with existing tools

 

It is said in th= is document that compatibility with the existing tools has been maintained.= But there is no detailed analysis which IMHO might be of great interest to= the industry and should form an important part of this analysis document.

 

<Nurit>

As mentioned abo= ve, the purpose of the document is to provide an overview of the MPLS-TP OA= tools. It is not a detailed analysis of the tools.

Still, I think y= our idea is excellent, and may be a subject for another I-D. \<Nurit>=

OK.

 

3) 1.1 Scope

 

In the middle of= this section, under the "three objectives", the first bullet rea= ds 

 

   o  The OAM toolset shou= ld be developed based on existing MPLS

      architecture, technology, and toolsets.

 

However, in the = following paragraph it is written as

 

   o  ITU-T OAM for Ethern= et toolset as defined in [Y.1731].  This has

      been used for functionality guidelines for the performance

      measurement tools that were not previously supported in MPLS.

 

There seem to be= conflicts between the objective (should...existing MPLS....)

<Nurit> I = am afraid I cannot see the conflict between the sentences=85.I consulted wi= th some colleagues and they could not see the conflict as well. \<Nurit&= gt;

and the toolset = development (...tools...not...supported in MPLS). [RFC 5860] says that &quo= t;...the MPLS-TP design, SHOULD as far as reasonably possible, reuse existi= ng MPLS standards." which looks more appropriate to me as the objective. Please clarify this point.

My concern is that the objective in this document is not exactly the same a= s in RFC5860. It is proposed to keep aligned.

 

 

4) 1.1 Scope

 

The third one of= the "three objectives" in this draft reads

 

   o  The OAM toolset deve= loped for MPLS based transport networks needs

      to be fully inter-operable with existing MPLS OAM tools as

      documented in [RFC 5860].

 

I may be wrong b= ut I find [RFC 5860] only requires OAM interoperability between distinct do= mains (w/wo IP capabilities). The original description is as follows:<= /o:p>

 

   It is REQUIRED that OAM interoperability is achieved between distinc= t

   domains materializing the environments described in Section 2.1.4.

My understanding= of the "OAM interoperability" mentioned here refers to MPLS-TP O= AM interoperable in different domains, but not MPLS-TP OAM and MPLS OAM int= eroperability.

 

<Nuri=
t> Section 2.1.4 to which you refer in your quote, discusses the environ=
ments. 
=93There are environments where IP capabilities are pres=
ent in the data plane.  IP/MPL=
S environments are examples of such environments=85.=94.<=
/pre>

RFC 5860 continues to require that =93When MPLS-TP is ru=
n with IP routing and forwarding capabilities, it MUST be possible to opera=
te any of the existing IP/MPLS and PW OAM protocols (e.g., LSP-Ping [4], MP=
LS-BFD [13], VCCV [5], and VCCV-BFD [14]).=94


\<Nurit>


 


 


5) MPLS-TP v.s. =
MPLS based transport networks


The draft uses b=
oth "MPLS-TP" and "MPLS based transport networks". E.g.=
 is it "MPLS-TP OAM" or OAM toolset developed for MPLS based tran=
sport networks?



Are they the sam=
e? Or what is the relationship between them?


 


<Nurit> th=
ank you for catching this. We will clarify that they are the same. \<Nur=
it>



 


Tina<=
/span>


 


 


 


 
--_000_03265FE842A24C50AEDABFED8FCCF076huaweicom_-- From scott@hyperthought.com Sun Apr 22 11:23:03 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 7DF1021F865C for ; Sun, 22 Apr 2012 11:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 f0G9s9WKBeEK for ; Sun, 22 Apr 2012 11:23:02 -0700 (PDT) Received: from smtp130.dfw.emailsrvr.com (smtp130.dfw.emailsrvr.com [67.192.241.130]) by ietfa.amsl.com (Postfix) with ESMTP id A617821F8648 for ; Sun, 22 Apr 2012 11:23:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp29.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 3D6D93982F2; Sun, 22 Apr 2012 14:23:02 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp29.relay.dfw1a.emailsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id B25993982F5; Sun, 22 Apr 2012 14:23:01 -0400 (EDT) From: Scott Kelly Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Apr 2012 11:23:00 -0700 Message-Id: To: draft-ietf-marf-as.all@tools.ietf.org, secdir@ietf.org, iesg@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] secdir review of draft-ietf-marf-as-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: Sun, 22 Apr 2012 18:23:03 -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 Abuse Reporting Format (ARF) is used to report email abuse feedback = between email operators, or from email operators to end user network = access operators. This document is an applicability statement for using = the ARF in these two contexts. The security considerations section refers the reader to the security = considerations discussions in RFCs 5965 and 6449, but also contains a = detailed discussion of various concerns. I see no security issues with = this document. From jsalowey@cisco.com Sun Apr 22 15:00: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 8584421F85A0; Sun, 22 Apr 2012 15:00:09 -0700 (PDT) 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 yutKGId5HPHq; Sun, 22 Apr 2012 15:00:08 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id A494E21F8595; Sun, 22 Apr 2012 15:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=2627; q=dns/txt; s=iport; t=1335132008; x=1336341608; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=yLcOKFKX6+VQPdXYObCnbmp5VQsrNwT+1JCqF4t41XA=; b=fj36VJI/tWpFpU+6GDLzFwmJf0tYA9z7WyQ/2qgLBdv4uP7hESFXXjqH gqgXWP/eZwJ+3LnJByV0tb0mfv/qZLsH+kgKhJb4DtA61KLCDoVKMW5nO Yk39eejmcRupe0czdgQ7/zl9+YyIjKQndDElQxFn7TY1YUCPs8b2EWHGN c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoAGALx+lE+rRDoH/2dsb2JhbABEgx2uJIEHgiIBJ4F9ATSHbJofnw2QUGMEiGONF4V0iGGBaYMJ X-IronPort-AV: E=Sophos;i="4.75,463,1330905600"; d="scan'208";a="39104191" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 22 Apr 2012 22:00:08 +0000 Received: from [10.33.248.250] ([10.33.248.250]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3MM07cf010894; Sun, 22 Apr 2012 22:00:07 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Apr 2012 15:00:07 -0700 Message-Id: <36214B77-821E-47B9-8349-A89D2800E24C@cisco.com> To: secdir@ietf.org, The IESG , draft-templin-aero.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] secdir review of draft-templin-aero-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: Sun, 22 Apr 2012 22:00:09 -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. I apologize for the delay in getting this review out. Hopefully it is = still useful. =20 This first set of comments is primarily for the authors. 1. In section 4.4.4 on Data origin authentication the last paragraph = states that only the 3rd of the above conditions is acceptable, do you = really mean the 4th? 2. In section 4.4.4 there is reference to the packet including a digital = signature to authenticate the origin. What is the signature mechanism? = Is this SEND or something different? I did not see a reference to it. 3. The security considerations do not say much about the consequences of = trusting an inappropriate intermediate router, ingress node or egress = node. Clearly DOS to the ingress node is a possibility. Data = modification and disclosure can be a goal of an attacker who tries to = control the routing. Are there other issues the reader should be aware = of (perhaps other DOS attacks such as amplification attacks). Anything = outside the considerations of RFC4861)? 4. The security consideration section indicates that spoofing protection = can be provided by links that provide link layer security mechanisms. = Link Layer security mechanisms may or may not help. I believe more = information is needed here. L2 mechanisms may not provide adequate = protection of upper layer address bindings. In some cases L2 mechanisms = do not provide source origin authentication such as multicast traffic = protected with the group key in WiFi and group security associations in = 802.1AE (MACSEC).=20 This set of comments is mostly for the area directors: 1. I am mostly concerned about the lack of definition for the digital = signature mechanism. Perhaps this is easily rectified by a reference to = an existing specification. Its not clear to me what the specification = would be (perhaps SEND??)? Is something needed in addition?=20 2. The risks of not securing the proposal are not defined in the = security considerations section. I think this would be helpful, but may = not be strictly necessary. There is some mention of Link-Layer security = helping in some aspects of this, but its not clear on what = characteristics the lower layer security needs to provide.=20 Cheers, Joe= From klaas@cisco.com Mon Apr 23 06:51:08 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 5C1C621F84E2; Mon, 23 Apr 2012 06:51:08 -0700 (PDT) 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 t+qW6bIBrGVr; Mon, 23 Apr 2012 06:51:07 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D849521F8464; Mon, 23 Apr 2012 06:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5607; q=dns/txt; s=iport; t=1335189066; x=1336398666; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=lnqzOyugBdqhfz0ov0ng3ZwSIhvDAmPbonSAnWjl1rY=; b=gq9TnshNIVKSENfhDhdeVBitvH4bj8gT9I/4bn9FrMFm1enJ8d5VQ2Vt PsBLsd8ImNCtNyD9DMNi/AII58w5HUsN2CNMGmjGChDi7S6erfjRMTbyb bI1K4zIJKNq+j+X4laf2MoBh6E7S70LxdJipX765wMYZOGCm0F89TOj8z E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPVdlU+tJV2Z/2dsb2JhbABEsUWBB4IiARREDT0WGAMCAQIBSwEJAwgBAR6HbZo+n3+RMwSVeoERjUSBaYJrgVQX X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="73987564" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 23 Apr 2012 13:51:06 +0000 Received: from macmini.wierenga.net (rtp-kwiereng-8713.cisco.com [10.116.7.36]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3NDp4MT001725; Mon, 23 Apr 2012 13:51:05 GMT Message-ID: <4F955E48.7060908@cisco.com> Date: Mon, 23 Apr 2012 15:51:04 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: secdir@ietf.org, The IESG , draft-ietf-httpbis-p4-conditional.all@tools.ietf.org X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-ietf-httpbis-p4-conditional-19 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, 23 Apr 2012 13:51:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. First of, I think the draft is well written and a good read, compliments to the authors, especially the examples were helpful! To start with the Security Considerations (section 6), there aren't any..... or rather, section 6 refers to the security considerations of part 1 and states that the security considerations are the same as for HTTP in general. IMO that is a bit too easy, for example throughout the text there is discussion about clock synchronization, evaluation of weak conditionals, hashes etc. All of those can lead to the client having a "wrong" view of the resource. I would expect some discussion as to what that could mean and what measures could be taken to avoid that. Also, in part 1, security considerations 8.5 there is some discussion about MitM attacks and evil proxies, and the general statement is made that proxies should not be trusted anymore than the person who operates it. Whereas it is true that everyone in the path can change the transmitted information at will, I could imagine that with ETags one could actually implement some rsort of integrity protection by using ETags that are signed hashes of the content that is transfered.... thinking out loud... anyway, my bottom line is that I am not sure that the security properties of the system as a whole don't change by introducing conditionals. Then other things that came to mind while reading the draft (many just edutorial): - - section 1, p3, Introduction, first sentence I can not parse that sentence, should it perhaps be "....on that metadata be checked...." -> "....on that metadata; to be checked...."? - - 1.1, p3, conformance and error handling, 3d paragraph I don't get the statement about "SHOULD-level" requirements. Isn't that always the case with SHOULD? I.e. what is different from RFC2119? - - 1.2, p4, Syntax I think it would be helpful to state what OWS, obs-text and HTTP-date (informal) stand for, the production rule given here does not provide much clarity - - 2.1, p5, weak vs strong, 4th paragraph "A cryptographic hash function", which one? I think you need to state at least that you should choose one that is collusion resistant (and this should probably go into the security considerations) - - 2.2, p6 last-modiefied This paragraph came a bit out of the blue it is not mentioned that Last-Modified is one of the validators that you just talked about in the previous paragraph - - 2.2.1, p7, generation, one but last paragraph Seems that a bad system clock can nevertheless screw things up, if the system clock is set to earlier than the previous "fresh page" the content will never be updated. - - 2.2.2 p7, comparision Is it really neccessary to have the elaborate determination whether the vlaidator is weak or strong, with arbitrary time intervals etc.? It seems very error prone and confusing for implementers. Why not just say that Last-Modified is weak, and if you want strong use ETags. - - 2.3 ETag, p9, Note "ought to" is not very normative. Why not make it MUST or SHOULD? - - 2.3 ETag, p9, 2nd paragraph The "more reliable" and "convenient" don't seem to be related, even though that is suggested in the paragraph. I would argue that an entity-tag can be implemented to be more reliable period (because of the clock problems discussed before) - - 2.3.1 p 9, generation same discussion as in 2.1 about collission resistant hashes - - 2.4, p12, Rules.... HTTP/1.1 clients So if I understand the "MUST use the entity-tag" correctly the heuristic that is being used for servers can not be used here. Like in the server example I could imagine that also the client could decide not to fetch new weather data based on some internal rule (because it is mobile and wants to avoid rapid updates for example) The MAY use the Last-Modified in the case of an HTTP/1.0 origin server deserves some explanation, not being an HTTP expert it is unclear to me what makes it deifferent for 1.1 3.1, p 13, If-Match Most HTTP return codes are expanded, highly appreciated! Could you please do that for all, i.e. "304" -> "304 (not modified)" etc., that makjes for a much easier read. 3.3, p16 If-Modified-Since, First Note: What is the consequence of the Range header field modifying the meaning? 3.4 p17, If-Unmodified-Since Why not defining the the result of a request having both an If-Unmodified-Since and a If-None-Match or If-Modified-Since? 4.1 p17, Not modified, second paragraph A 304 response..... isn't this a fine case of a SHOULD rather than a MUST? Or perhaps "A 304 response MUST include a Date header field, unless the origin server.... , in that case a Date header field MUST NOT be provided", and what actually does "reasonable approximation" mean? Once again, compliments on a well written spec! Klaas Wierenga -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+VXkgACgkQH2Wy/p4XeFJoDgCgn2tUOZjydxeccRNBm7ml+XcB g+cAoMhPk0yV7KCZRVw+ysYJaQYh9IsQ =Woo2 -----END PGP SIGNATURE----- From fltemplin@yahoo.com Mon Apr 23 09:31: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 5DA6B21F85BE for ; Mon, 23 Apr 2012 09:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=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 mxKViHwhCPPs for ; Mon, 23 Apr 2012 09:31:08 -0700 (PDT) Received: from nm10-vm0.bullet.mail.bf1.yahoo.com (nm10-vm0.bullet.mail.bf1.yahoo.com [98.139.213.147]) by ietfa.amsl.com (Postfix) with SMTP id 2F2FD21F859F for ; Mon, 23 Apr 2012 09:31:08 -0700 (PDT) Received: from [98.139.212.149] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 23 Apr 2012 16:31:07 -0000 Received: from [98.139.215.248] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 23 Apr 2012 16:31:07 -0000 Received: from [127.0.0.1] by omp1061.mail.bf1.yahoo.com with NNFMP; 23 Apr 2012 16:31:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 646961.32276.bm@omp1061.mail.bf1.yahoo.com Received: (qmail 44981 invoked by uid 60001); 23 Apr 2012 16:31:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1335198667; bh=gLrxemWWxge/oCwF4ZSptwmknZK1dvscWBH3kMxfYDk=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=0Ei0CYh5mOnqsx7JHbQcQMQbdec4F1CuqESG9lk33UjqigzYNz30NI82QdDj0UPNVZ1XvZ5QhtyMGCDC6y67sDmfkm7oqkKyDE/nvDNZDyWMhX0X9X3YTfoZXmYsIte/WZ6qdLfTWfKlqJDol7zHtDweUvMJZ9FT3fl/G6yldog= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=tLfZmMQ6z0tMPhaeV6YdUtI/FMVwAg0tz/wLDOhWLRGQFRgMjHATlHIlecZfTIjmM32HbsDNkI7hcN9h7xcadTyF01l33zBCi+a/9T1G71i4sjFCQVEooS27991tj7DgrU4cm9x+C4M2Y5hY0mHWiJ6o7BGFcYDHpxq/M1ei/Kw=; X-YMail-OSG: ZlCLLyYVM1lkj6ykm4fhV8A.6EKiptt70W5sR4pLRJ.cYup sk7YFyxBv5PbSNa_A7ffDu18detk8EhWhp.QJ0FMTc6SbGGXTNPJ9UBGj8ud pVLvn1Vsoq03g5PckQasBNshyX_0xsGcMGfOHb7wmeRwTfBCj.vLhi_mcvRI wk0RR2CpzCKM9pcFYkZdqCUibS0TeB85UsqUNaWPx.rnDheWp1gAN32WpG6u XKycwZpIpn_WqsfYlMO5WYwTVr6h6lz3ijtFlDyqNjpv6iHoS.a96_hMr3dg nojSqs.Dew_9Oj1pe5zfEgnAZRCHoGXZLKfhTn18O.H7j7L4i9mEjC7EbgtW y2Jf6GCGf3J0eQS0PyMgq_h7pMlN4Ec10Eq23RiyIcwasjUEJkGgP_CWX0JJ pxQaAs8B3uYR0f.3dgVJLdr7h5YLyFrajFfBi3CsOzitQGXnmCgMjgmDHVz0 6Yz8ed0l16ZsrwIJo8J3641fstXkZeLHEDCJPQzJ5XfF4nHx. Received: from [130.76.32.197] by web161601.mail.bf1.yahoo.com via HTTP; Mon, 23 Apr 2012 09:31:07 PDT X-Mailer: YahooMailWebService/0.8.117.340979 References: <36214B77-821E-47B9-8349-A89D2800E24C@cisco.com> Message-ID: <1335198667.40720.YahooMailNeo@web161601.mail.bf1.yahoo.com> Date: Mon, 23 Apr 2012 09:31:07 -0700 (PDT) From: Fred Templin To: Joe Salowey , "secdir@ietf.org" , The IESG , "draft-templin-aero.all@tools.ietf.org" In-Reply-To: <36214B77-821E-47B9-8349-A89D2800E24C@cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-83809723-123150112-1335198667=:40720" X-Mailman-Approved-At: Mon, 23 Apr 2012 09:56:22 -0700 Subject: Re: [secdir] secdir review of draft-templin-aero-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Fred Templin List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 16:31:09 -0000 ---83809723-123150112-1335198667=:40720 Content-Type: multipart/alternative; boundary="-83809723-875793722-1335198667=:40720" ---83809723-875793722-1335198667=:40720 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello Joe,=0A=0AThank you for these comments. Please see attached for my pr= oposed=0Aresolutions:=0A=0AFred=0Afltemplin@acm.org=0A=0A=0A=0A=0A>________= ________________________=0A> From: Joe Salowey =0A>To: = secdir@ietf.org; The IESG ; draft-templin-aero.all@tools.iet= f.org =0A>Sent: Sunday, April 22, 2012 3:00 PM=0A>Subject: secdir review of= draft-templin-aero-10=0A> =0A>I have reviewed this document as part of the= security directorate's =0A>ongoing effort to review all IETF documents bei= ng processed by the =0A>IESG.=A0 These comments were written primarily for = the benefit of the =0A>security area directors.=A0 Document editors and WG = chairs should treat =0A>these comments just like any other last call commen= ts.=0A>=0A>I apologize for the delay in getting this review out.=A0 Hopeful= ly it is still useful.=A0 =0A>=0A>This first set of comments is primarily f= or the authors.=0A>=0A>1. In section 4.4.4 on Data origin authentication th= e last paragraph states that only the 3rd of the above conditions is accept= able, do you really mean the 4th?=0A>2. In section 4.4.4 there is reference= to the packet including a digital signature to authenticate the origin.=A0= What is the signature mechanism?=A0 Is this SEND or something different? I= did not see a reference to it.=0A>3. The security considerations do not sa= y much about the consequences of trusting an inappropriate intermediate rou= ter, ingress node or egress node. Clearly DOS to the ingress node is a poss= ibility.=A0 Data modification and disclosure can be a goal of an attacker = who tries to control the routing.=A0 Are there other issues the reader sho= uld be aware of (perhaps other DOS attacks such as amplification attacks).= =A0 Anything outside the considerations of RFC4861)?=0A>4. The security con= sideration section indicates that spoofing protection can be provided by li= nks that provide link layer security mechanisms.=A0 =A0 Link Layer security= mechanisms may or may not help.=A0 I believe more information is needed h= ere.=A0 L2 mechanisms may not provide adequate protection of upper layer ad= dress bindings.=A0 In some cases L2 mechanisms do not provide source origin= authentication such as multicast=A0 traffic protected with the group=A0 ke= y in WiFi and group security associations in 802.1AE (MACSEC). =0A>=0A>This= set of comments is mostly for the area directors:=0A>=0A>1. I am mostly co= ncerned about the lack of definition for the digital signature mechanism.= =A0 Perhaps this is easily rectified by a reference to an existing specific= ation. Its not clear to me what the specification would be (perhaps SEND??)= ?=A0 Is something needed in addition? =0A>2.=A0 The risks of not securing t= he proposal are not defined in the security considerations section. I think= this would be helpful, but may not be strictly necessary.=A0 There is some= mention of Link-Layer security helping in some aspects of this, but its no= t clear on what characteristics the lower layer security needs to provide. = =0A>=0A>Cheers,=0A>=0A>Joe=0A>=0A> ---83809723-875793722-1335198667=:40720 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Joe,=

Thank you for these com= ments. Please see attached for my proposed
resolutio= ns:

Fred
fltemplin@acm.org


From: J= oe Salowey <jsalowey@cisco.com>
To: secdir@ietf.org; The IESG <iesg@ietf.org>; draft-templin-ae= ro.all@tools.ietf.org
Sent: Sunday, April 22, 2012 3:00 PM
Subject: secdir review of draft-templin-aero-10
=

=0AI have reviewed this document as part of the security direct= orate's
ongoing effort to review all IETF documents being processed by = the
IESG.  These comments were written primarily for the benefit o= f the
security area directors.  Document editors and WG chairs sho= uld treat
these comments just like any other last call comments.
I apologize for the delay in getting this review out.  Hopefully it i= s still useful. 

This first set of comments is primarily for t= he authors.

1. In section 4.4.4 on Data origin authentication the la= st paragraph states that only the 3rd of the above conditions is acceptable= , do you really mean the 4th?
2. In section 4.4.4 there is reference to = the packet including a digital signature to authenticate the origin.  = What is the signature mechanism?  Is this SEND or something different?= I did not see a reference to it.
3. The security considerations do not = say much about the consequences of trusting an inappropriate intermediate router, i= ngress node or egress node. Clearly DOS to the ingress node is a possibilit= y.  Data modification and disclosure can be a goal of an attacker who= tries to control the routing.  Are there other issues the reader sho= uld be aware of (perhaps other DOS attacks such as amplification attacks).&= nbsp; Anything outside the considerations of RFC4861)?
4. The security c= onsideration section indicates that spoofing protection can be provided by = links that provide link layer security mechanisms.    Link Layer = security mechanisms may or may not help.  I believe more information = is needed here.  L2 mechanisms may not provide adequate protection of = upper layer address bindings.  In some cases L2 mechanisms do not prov= ide source origin authentication such as multicast  traffic protected = with the group  key in WiFi and group security associations in 802.1AE (MACSEC).

This set of comments is mostly for the area dire= ctors:

1. I am mostly concerned about the lack of definition for the= digital signature mechanism.  Perhaps this is easily rectified by a r= eference to an existing specification. Its not clear to me what the specifi= cation would be (perhaps SEND??)?  Is something needed in addition? 2.  The risks of not securing the proposal are not defined in the se= curity considerations section. I think this would be helpful, but may not b= e strictly necessary.  There is some mention of Link-Layer security he= lping in some aspects of this, but its not clear on what characteristics th= e lower layer security needs to provide.

Cheers,

Joe

=
---83809723-875793722-1335198667=:40720-- ---83809723-123150112-1335198667=:40720 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="Joe Salowey 042212.docx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Joe Salowey 042212.docx" UEsDBBQABgAIAAAAIQDr01KodAEAAKMFAAATAAgCW0NvbnRlbnRfVHlwZXNd LnhtbCCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0lMtOwzAQRfdI/IPlLUrc skAIJemCxxIqUT7AtSethV+y3dffM0nbCAFNRatuIkXxnHvveCbFaG00WUKI ytmSDvMBJWCFk8rOSvoxecnuKYmJW8m1s1DSDUQ6qq6visnGQyRYbWNJ5yn5 B8aimIPhMXceLH6pXTA84WuYMc/FJ58Bux0M7phwNoFNWWoYtCre0EBQEsiY h/TKDeqwlQsSDxqDB2OONEoet2WNckm591oJntA3W1r5QzNzda0ESCcWDSBv aD44ATFiMqPzPfmmIbOqeIKaL3Qiz2t0tm1GAB3/J7oLmWNlayzOlY89Cv2p ds4ONqcL1485oTkd2XBl9/4P+ohpo+ECV7Tl9smjz3FwPjIchrNHBJqblyAz nBMPISnoru5wdEgJ5+kS4XfkvvjtiiRcOWDtc3h2D1rMUcka93DCpxrO1vu1 lh36qIkVTN8v1v1v8D4j3fwJF05oxv530VT/MXWs/cVWXwAAAP//AwBQSwME FAAGAAgAAAAhAB6RGrfzAAAATgIAAAsACAJfcmVscy8ucmVscyCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACMkttKA0EMhu8F32HIfTfbCiLS2d5IoXci6wOE mewBdw7MpNq+vaMgulDbXub058tP1puDm9Q7pzwGr2FZ1aDYm2BH32t4bbeL B1BZyFuagmcNR86waW5v1i88kZShPIwxq6Lis4ZBJD4iZjOwo1yFyL5UupAc SQlTj5HMG/WMq7q+x/RXA5qZptpZDWln70C1x1g2X9YOXTcafgpm79jLiRXI B2Fv2S5iKmxJxnKNain1LBpsMM8lnZFirAo24Gmi1fVE/1+LjoUsCaEJic/z fHWcA1peD3TZonnHrzsfIVksFn17+0ODsy9oPgEAAP//AwBQSwMEFAAGAAgA AAAhAJs7tcMJAQAAtAMAABwACAF3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5y ZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArJNN TsMwEIX3SNzBmj1xUqBCVZ1uUKVuIRzAdSY/IrEjzxTI7TGRUlJRhU02luZZ fu+zZ7zdfbWN+EBPtbMKkigGgda4vLalgrdsf/cEgljbXDfOooIeCXbp7c32 BRvN4RBVdUciuFhSUDF3GynJVNhqilyHNuwUzreaQ+lL2WnzrkuUqzheSz/1 gPTCUxxyBf6Q34PI+i4k/+/tiqI2+OzMqUXLVyLkJx5fkTlcjoKt9iWygokY BVqQ10FWS4LQH4pRmUNIFkXgvgnNPD8DDfVc/HrJeA4jgr/pQymHNZljeFyS oXCWM31sJhxnaQ7iYUkI49qfcZ10YlRGBHnx19JvAAAA//8DAFBLAwQUAAYA CAAAACEAQl6+NuwHAACqFgAAEQAAAHdvcmQvZG9jdW1lbnQueG1sxFjrbts4 Fv6/wL4D4T8zBVo7dtImMBoHbZJ2vejMFE0G/U1LtMQNRWpIyhrP0+yz7JPN dyhRli/JOMUUiwBJKF7O7fvOOeTbq98LxVbCOmn05WA8PBkwoROTSp1dDn69 //DqYsCc5zrlymhxOVgLN7ia/fMfb+tpapKqENozHKHddIXZ3PtyOhq5JBcF d0NTCo3JpbEF9xjabFRw+1CVrxJTlNzLhVTSr0eTk5M3g/YYczmorJ62R7wq ZGKNM0tPW6ZmuZSJaP/EHfYYuc3Om1blIHFkhYIORrtcli6eVnzraTAxj4es njJiVai4ri6PkZZaXiMehWrUro1NS2sS4Ry+3jST3Ynjk6dktw6kI7odx6iw LTNqUnCpu2MIHTvx74I3RPBGjewRHbUxBL6YAUsLk67pb8nqKbCYfrkcnJyM 35/ejM8H8dONWPJKeZp5/f78+vU47LS0LWBw6kqeQInSCifsSgxmc5bzlWBW rKSoRcp8Lh3rYMsdK7n1zCwxIZgTSWWBRpZKKxJvLPfiB8fejnD8jH4HSeHX wo6ekGp0ZhAYJpYAvmfetAowrhSb395/6FRwbCFoZRtNaLhYB12eL3R+e/dx +L//svscxjO4m5jpWC2sYDXM8kJDjAT9pFozKBbkLIQWS9m54PliO6dxK3jn OUeaRK4xkUp40zEkEfb1I0tyLjFyuakUQoJ9/kknzxCcvkn/qZxnSj4IHLhm BrOWKY5vCfk3Wj581JZnRHLOeGmUyeQfonNZiqSxZlKzTHhPwQugaiDGTOXJ 9H8h8S0rBUfDt4Cc8xKqVY4+0vzzdJvdE2yXcJoHSEOwopV0+H5UeeVzOPw5 LohOaQ/+wnUm7jyxo57KFJQbBMQ3ZJuNh2yuiTCUPdnZED8M/9xwz5mxMoN3 SAcgUCYhwwawhSCBcTyzvMypqnjhMIP4Gw1fYQM7tWnkI18YcDcxGvChJE22 8iQRpecLJV6CRGxtKnALYV+zQnAdTjjz+dWOf/tG3QKE2ybF9EJ55f378/PT iwGR235u+H7n1woUmq64uhxcN7z6IpbglU4EeYVc16yNcuJsX1B08CZ/xC9x 167Lx1sunxxwOUFfkFtsJxHJhtyIRPgApEidqIpKOSNuZtJzxZzMNPcVNmJt L0oYY2MTPcLoV4oLzqavmz2FAH21dMUVlsxpFkvubn++wU7mTCHwAeJSuQwe 8ldsjkHKtCHsgrLbukq/C9K+Nzaxir747rEKgmJkjo/VpB8ramT2a9HpkHLz psoA2KhzAlUmgBtoDj5CbimqJGdAf4XagR20UPxWEdxc4IZFAgwx1QgwL1E8 kALAJYy8sAXSLQ0s9gv7Eh8z1EOH01MKLxOb4ZBdK8Et2HPzyx3BgcRtrUdw OSsNGo2mUwt5nVheoENEK9aQmxJ7Kl2ijCNcJWDigkKdGeAN1RVj7j1B0rI6 hxgrifiGTPPWqCCX9IVskvCOwBmw3WR36VwVMgWVcg6fxeJBUmpUHhLyYyls zku4iLYGixqhSL/BoTClKFVP66CSe3EgIcOlZnlroe3Ur0u0FMhYRUiH/TjP 3ul1A3eoTrHswtWLKzT78uH67OLN+MVxaamF0kEVQIhWge9OhKDG84lw2nfQ YSKcPUWErqhIpH3AKxYIVyIiBHr4xbd1p8UZvqzg8NA7KakfKCkhdbWf0Sno B/QHa0JN7PC6LBYaFSDuEy369NgiVoCVoA79IZLmQpWEmjlgrqRAlSoMQCh1 c9GhmgjiaCFIK8IxLf40QY1qk6frjopaAtW/VUTbnn2ATlUC1a32PE0DkRfk Gp0F1akKI+mCcg6e2hbRZpQowZnKJjHB9xM/qRsZUqC/htudh8LecrptRY1g Si19HjCegawlljyI0AntlFtI3GaPK4VS+/T5Kj/Io7ZuYP9E1x3ay6DYJs7c OZMgGzbtg2YXJ5Ph+N0t+/Gnd9d3t9cvdqQfrj0R0n3Kvbk9vzg7/5v7hCBo i3KPXGuG39RAHmgdC+M8sn+8DWz38DvO2Yvq4Zw4PWbbdkDDbWrL7qfvV9R9 IpeDdEF7FJFEWA18bmqmQrGhopDidqND+9gZud8HdbQkmn5uq0hobMBiwR1d mOhGiNLRZJmdJgblTfwum5oMqCddidmL054Pd5mxt+Cwk+fe/ZWbw8mdnw+e 282GPucRrIWEl1CbQAUbqaam5EqNwpaprA63ORTkrg5TV3h19aJtFDe9YZsX 6Y6QNq391eN4fvRqP6Fg3UMNKx1SPmLdtJh0hw+XspBK0bqgBaEOgWYDGhBC iA4GxHKw04q19xpCGZX3B/qNm3Q0kLI/7nEv2QINWiwJMNyhrUmITlrQ0wy3 61ZFKg1oQihP06Wc8i3UpZLzaqfk0NGkPRQMyzn5GLd4LCcdGpFHRb6XbQ/G vjffRH8m/y+Ygi8CoFAYLU/QsBKPEirhgimD14vd0k3oCb0jzKKyv8ex/aZ9 84Vecq5zgdfOv3LiYd69PGbbNq0eT26zfxuxdR5SYEkFjvD3mXrPRx7C7jDf ex6jLWV29wc21HjBnUzO8IZbT3P8//oC/4eLe5n9BAbDfoMXx/FZswQ39Rwn xeHCeG/w/BnHSix7s3novC8H55Nw/NKgD8PLazvMKrwwYdiKS4wCY+IliNYE LfD09tHiNlhP0ZWJz9In0PL0TZiF9Y3h4UbdvAfiW3ytm/0JAAD//wMAUEsD BBQABgAIAAAAIQDpGl81PwkAAFkmAAARAAAAd29yZC9jb21tZW50cy54bWzc WMtu4zYU3RfoPxBatcDYlhTFDzX2IJNMgAGKNvC4i3ZHS5TFjkSqJGXHWeVD 2m0/LF/SQ0l2bCexMzNok3Rlm7yPQ95zH/TJ26s8I3OmNJdi6Hht1yFMRDLm YjZ0fplctPoO0YaKmGZSsKGzZNp5O/r2m5NFGMk8Z8JoAhNCh3PspsYUYaej o5TlVLdlwQQ2E6lyavBTzTo5VZ/KogXdgho+5Rk3y47vul2nMSOHTqlE2Jho 5TxSUsvEWJVQJgmPWPOx0lBP8VtrnsuotJgrjx3FMmCQQqe80Ctr+ZdawxHT lZH5vkPM82wltyie4i1WdIF45FkNeyFVXCgZMa2xel5vri167j7fzQVaE2uN p0DY9rlCklMu1mYsO3bivw5eG8Hr1L471tTdQXAXozsukUXI46EDEi5CWppU IrbZte8FkV2JqYEP3/X8lhu0/KOJOwg9L3Td3+wuF9xwmumhc/HjpDJaYBXE jsew6L571+sdgczN0jlLaJmZjR0Lo7hU1cdHs8wYROc0GzpnNc8n7Mo4ndFJ Zy1WyapaRT2kMmYJU0gn1ug1slQIaSrmQaC2WJuyvs3oV1kSqhiJpFIsMj8Q k3JNdCrLLCaaLvGbkcDiMBWaWnd1sEtc2fq01mDjFDluTjM+E6tj6bJA2keK F6tjNZJmZNJd6xUym6GhLmiEKBSKaabmzBkRFAcSUUGmjCT8isWEiwqiwIWt Skt7y6C9wgo6aGHT0VpvvgKdZYD3GQwI/ncMmCDAMZ9xQzOiETJqSvAhZ1FK Bdc5AR1kaYhMiI5QYwkKbE2SuKlvbWJNGBuAqKINYkPj30ttEB4jLYtCcnvz 5+3N32/I6fvxz0TImGmSg10QlVMQpZZU7I+Sw7nlXKmxldxHpgktioxbhVTJ cpYCKhUVRmRfrVsDhXZF5jXO25u/PpMZ/tOZ4R9/GTPqFOq+7/WD3ssuGNtJ 3yCuq8ilkoXUiAkSVWal7XOWNwi+Yq2F4qaOS8KVNqSgis4ULVIb348oOla6 uxUZFJKVN1tgNn09Vhce09+63xqtBoezTC50uKVUFwpUi03XO5V8y9pK7uvL +9Nd7+C577oBdblTmJtmY+hUV5dApxCsOk7GEmOJhwAOnYHXte0D1f4RAa9/ 5O+X8HtBf7/EUbcb7JcIjvvufonjYHAAaTfwDiDtHfkHkPb94ABSXNgBpJ7r 9g5A9dzB4ABWzxu4B8B6PuDuvzXvqBccght0jyu4tuU3bLFtGNMfSEITw2zP t4TJuJ3CfBhsfozLDAsYpWSNYjWtXEg7uENZR5zbEadUnCnyE1tYTUa1OdWc Dp0Jz9EWsEzGMqcY9hZheir0fZUITN20UjFWX0O+YrTfHFFfn1m3G2s4UwXK 5lszSkGgGtu2MttmwC76vTi/GpGdr9AjtwrSRhWs0TXJ/yzoHq67VTsHET4R zSKE1SzJ/iNslPL//IIfPkKENxkGB1W/zqph2M4fmuYYY2yrUM2bVMXkw+W8 C4LyWTrF8jnHoIFRd0m+G1+cBf2u9z1hVxErDAYPaupZh+d4Ps3BazQ5LSub BXqebpMPwrZCw6Myo6qZjPZf3suLP5p8zPDwjjFY2xNSYhQGPzKlGltTZhaM iVdHiYrVLzcUIxbPWD1E7wf58pLtABWek+Aj+7TkwrDXdqcqZzHHvxUEzyF0 Z/2GLFL8E1C9ovaf5Vmv+47EJLclQ4psib8DZ3T26iLwr7P6HwAAAP//3FfR bts2FP2VCz21QOy6TtC0Ri0gzRx0QNYZiYEBfWOkK4uIRGokFcd96odsP9cv 2SElebbrps28JMNeBIqUyMt7zzn3XkMfeBG9iN8uRvYTLUY3ohhHw0E3c2o3 514sRmZq/NculopcznQyufiVSk5yoaQtaZGzIulIWspEIgvphOOUrpYkyJna 4uUtdnGxf4adDI4wVqYXUzOOBoNXk+PXR8eRP6M9ypxp5bwhLKw7sVKMo5ks 2XrT6UKXQkVYTOw4OtW1kfzP70S3ZTGylUh4HFWGLZsbjmK62+B3746PD18/ jcEIgmNTcirhZTK6xlv/bnOf0r/xl89/blgHDFQBCYkuS1ZABQLZDBFSmY6j Qx9bUbtcAx3Fp+HLo8TPpLivB+rLYW9w1BsezgZvRsM3o8Hgo1+VSjopCiDi 7HwWIlNhNoBsDWLd1E+cibpwayvejKrBeXXplgXj08CM08a2Gd86TxFvfvNZ g+R2vOuXC87YsEq4/a/FtlBKgyFSK3zQ7NhsFTj2DTxOja60BasAUV3U/m/P N6cx0VsYCSh4ZlpOtEqpEkbMjahy0hldchI+f0UCBNVFoRd2tCMkuFjnnjW/ dFP7e6wJ/H1Pac+frpn0zVC9n/1yPjWcaVMKB9VpJG1bUoRNpJzlXAJNpVTa vD9RVnoM5X7w9UobIx/pteh3jvmuhO1znlfNL5//CIJbSHVtqaztRuw6RW1x 2OnmnofuRqGjK6bKaAdEAYpiLqSyjmyldSbVnOB0kcBGpIlFLpOchPqOkN6h THveIBaP4KY4XBjZB2z09PMhgoPYsUoDOeGvVQ4kxXKeX2nTJzrfNu7R0BRA 5HLhfCBvZNoY3SvEEteAfCCbIpKr5P50YKNn3J/3D7YBBKt1NjEGDnPLChS2 FRfFpRMmyPPD0CH+TZ7JrZDtNmSiOtXxKvVvSg/uu5uVwJVbaHNtn4Nv6ba/ vKN+rNTal3BBn7actJEjH1SbwL81TFf50spEFC2i3fLp3PKMH8EncaAKqik2 lZGWO0zQ+ckH4KKjulaFL8ozaV0P4WJfHqSoUpTlzRLy/5Srf+QuG0m8Y8zX JU+78t8rRh5NbH5WZHXJSPHWCZS29sAnvlBz8QGJNEUVrtWKeEgl2+jvvLvh 8gewPxbW1ibYuKpUtPKwvw4Vy7ZdD2HCRlUkDNo1/r2WhtM+nWlDfCvKqoDf ZNZU7+hlE6YEZZPL0dnN88bZJQtlKZVzdNYFGGzl3DfcKAbZWjFHW+yLj5St kyo0FmGLGzYyWzYb4wfhavQOvmMA3TEk9FOCtMGuiny3BfWAZPrw9WlyKxK3 VgWgbzBbBoSCD/mmOca/ebPaU/xd0ZmixW/7kkRXQW1cjq4l1UntW7/+7t7w vi2Cj9x9WrdGEPBcdaB/j238FwAAAP//AwBQSwMEFAAGAAgAAAAhAJa1reKW BgAAUBsAABUAAAB3b3JkL3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0 b2MndhoHdYrYsZstTRvEboceaYmW2FCiQNJJfRva44ABw7phhxXYbYdhW4EW 2KX7NNk6bB3Qr7BHUpLFWF6SNtiKrT4kEvnj+/8eH6mr1+7HDB0SISlP2l79 cs1DJPF5QJOw7d0e9i+teUgqnASY8YS0vSmR3rWN99+7itdVRGKCYH0i13Hb i5RK15eWpA/DWF7mKUlgbsxFjBW8inApEPgI6MZsablWW12KMU08lOAYyN4a j6lP0FCT9DZy4j0Gr4mSesBnYqBJE2eFwQYHdY2QU9llAh1i1vaAT8CPhuS+ 8hDDUsFE26uZn7e0cXUJr2eLmFqwtrSub37ZumxBcLBseIpwVDCt9xutK1sF fQNgah7X6/W6vXpBzwCw74OmVpYyzUZ/rd7JaZZA9nGedrfWrDVcfIn+ypzM rU6n02xlsliiBmQfG3P4tdpqY3PZwRuQxTfn8I3OZre76uANyOJX5/D9K63V hos3oIjR5GAOrR3a72fUC8iYs+1K+BrA12oZfIaCaCiiS7MY80QtirUY3+Oi DwANZFjRBKlpSsbYhyju4ngkKNYM8DrBpRk75Mu5Ic0LSV/QVLW9D1MMGTGj 9+r596+eP0XHD54dP/jp+OHD4wc/WkLOqm2chOVVL7/97M/HH6M/nn7z8tEX 1XhZxv/6wye//Px5NRDSZybOiy+f/PbsyYuvPv39u0cV8E2BR2X4kMZEopvk CO3zGBQzVnElJyNxvhXDCNPyis0klDjBmksF/Z6KHPTNKWaZdxw5OsS14B0B 5aMKeH1yzxF4EImJohWcd6LYAe5yzjpcVFphR/MqmXk4ScJq5mJSxu1jfFjF u4sTx7+9SQp1Mw9LR/FuRBwx9xhOFA5JQhTSc/yAkArt7lLq2HWX+oJLPlbo LkUdTCtNMqQjJ5pmi7ZpDH6ZVukM/nZss3sHdTir0nqLHLpIyArMKoQfEuaY 8TqeKBxXkRzimJUNfgOrqErIwVT4ZVxPKvB0SBhHvYBIWbXmlgB9S07fwVCx Kt2+y6axixSKHlTRvIE5LyO3+EE3wnFahR3QJCpjP5AHEKIY7XFVBd/lbobo d/ADTha6+w4ljrtPrwa3aeiINAsQPTMR2pdQqp0KHNPk78oxo1CPbQxcXDmG Avji68cVkfW2FuJN2JOqMmH7RPldhDtZdLtcBPTtr7lbeJLsEQjz+Y3nXcl9 V3K9/3zJXZTPZy20s9oKZVf3DbYpNi1yvLBDHlPGBmrKyA1pmmQJ+0TQh0G9 zpwOSXFiSiN4zOq6gwsFNmuQ4OojqqJBhFNosOueJhLKjHQoUcolHOzMcCVt jYcmXdljYVMfGGw9kFjt8sAOr+jh/FxQkDG7TWgOnzmjFU3grMxWrmREQe3X YVbXQp2ZW92IZkqdw61QGXw4rxoMFtaEBgRB2wJWXoXzuWYNBxPMSKDtbvfe 3C3GCxfpIhnhgGQ+0nrP+6hunJTHirkJgNip8JE+5J1itRK3lib7BtzO4qQy u8YCdrn33sRLeQTPvKTz9kQ6sqScnCxBR22v1VxuesjHadsbw5kWHuMUvC51 z4dZCBdDvhI27E9NZpPlM2+2csXcJKjDNYW1+5zCTh1IhVRbWEY2NMxUFgIs 0Zys/MtNMOtFKWAj/TWkWFmDYPjXpAA7uq4l4zHxVdnZpRFtO/ualVI+UUQM ouAIjdhE7GNwvw5V0CegEq4mTEXQL3CPpq1tptzinCVd+fbK4Ow4ZmmEs3Kr UzTPZAs3eVzIYN5K4oFulbIb5c6vikn5C1KlHMb/M1X0fgI3BSuB9oAP17gC I52vbY8LFXGoQmlE/b6AxsHUDogWuIuFaQgquEw2/wU51P9tzlkaJq3hwKf2 aYgEhf1IRYKQPShLJvpOIVbP9i5LkmWETESVxJWpFXtEDgkb6hq4qvd2D0UQ 6qaaZGXA4E7Gn/ueZdAo1E1OOd+cGlLsvTYH/unOxyYzKOXWYdPQ5PYvRKzY Ve16szzfe8uK6IlZm9XIswKYlbaCVpb2rynCObdaW7HmNF5u5sKBF+c1hsGi IUrhvgfpP7D/UeEz+2VCb6hDvg+1FcGHBk0Mwgai+pJtPJAukHZwBI2THbTB pElZ02atk7ZavllfcKdb8D1hbC3ZWfx9TmMXzZnLzsnFizR2ZmHH1nZsoanB sydTFIbG+UHGOMZ80ip/deKje+DoLbjfnzAlTTDBNyWBofUcmDyA5LcczdKN vwAAAP//AwBQSwMEFAAGAAgAAAAhAJ/vCwLxAgAAsgYAABEAAAB3b3JkL3Nl dHRpbmdzLnhtbJxVW2+bMBR+n7T/gHheAuTaoNJKSdZd1G7TaH+AAQNWfZNt QrNfv2PApdmyqtpTzPed8/ncfHJ5/cSod8BKE8ETP5qGvod5LgrCq8R/uL+Z XPieNogXiAqOE/+ItX999f7dZRtrbAyYaQ8kuI5F4jeKxzqvMUN6wkiuhBal meSCxaIsSY6HH3/wUIlfGyPjIBicpkJiDmqlUAwZPRWqCnrPvcgbhrkJZmG4 ChSmyEDAuiZSOzX2v2pwVe1EDq8lcWDU2bVR+JrlkG4rVPHs8ZbwrINUIsda Q2UZ7dNliHAno+lbdPp63pJMIXV8IXIFbfslBPPaWGKVQ0Gh52HoB5aAi0WZ GmQw0FpiSrshyClGcH0bVwoxhqBpPdL5FLhEDTX3KEuNkGB0QBDgejZI5jVS KDdYpRLloLYT3ChBnV0hvgmzE0wqSLgPAoZFItNpw0wW2gZmDz+FMM4tDJfb 9W4Z9R6WHZlwv9rshttPmWg730frcz7z3Xod7c4x/75n9XF9sTirttnMV/vN ObXtdr2eX1gm6JOC7Fhsx++HcqcbqJDH+jLuEMsUQd6dHVDwYnGmHreEOz7D 8FDwSyZtMkdOJj2hGaL0BrrgCJjNnimIlntcdsL0DqlqVO4KyGJ1FoWef31W szOE1SclGtmrtgrJL7wA2F0YLRaDHuHmljCH6yZLnReHOX1BNbz4flBWMBgL 1MYGVgu2FbpFvHI9x3zykFrTNs6pSu36wXdIShg3MMmqKPEpqWoT2Rk28FUg 9dh9ZNVs4GYdB1+W6z5QbjMD6+FgDfojWA2HEZs7bD5iC4ctRmzpsOWIrRy2 slh9hIcJD+8Rnrk7WrwUlIoWF58dmPh/QX0RdI0khr7adwkDJuIOGB6q9g4x foJXjwtiYLNLUjD0lPizcNn1aLCm6Cgac2JrlayxPEG9AhkEO6Rr1YlzN+R/ xNLGBc4JDGR6ZNm4BqZ94JRok2IJG8MIBSl3q+RDpzz+2Vz9BgAA//8DAFBL AwQUAAYACAAAACEAjNX2vU8BAAA0BAAAFAAAAHdvcmQvd2ViU2V0dGluZ3Mu eG1s7FPJbsIwEL1X6j9EvpckbA0RAQkhTj11+QATT4il2GPZJil8fYeEttD2 0Eg99uTxLM9v5nnmy1dVBTVYJ1FnLB5ELACdo5B6l7GX581dwgLnuRa8Qg0Z O4Bjy8XtzbxJG9g+gfeU6QJC0S61GSu9N2kYurwExd0ADWiKFWgV93S1uxCL QuawxnyvQPtwGEXT0ELFPTFwpTSOndGa36A1aIWxmINzRERVHZ7iUrMFcRSy duczaFIpMpZMx/H9ZDYetfEtisNa1hSreUX9s/CUrbh9gMK/e6MP76PclT+4 n9F8z12h96i++InPStjTG/6zRtNkGSW6Y8Zo/mQYntOsWzvHCmmufO+xo1Fd MOtXub1i1K/WXnbepzRsRWib7sxrOeIkSkaTeDyc/evR5xf8pR6dLu2eoPFS ySNs0K4sNg4sLQTFL3Z98QYAAP//AwBQSwMEFAAGAAgAAAAhAEyH+0d3AQAA 4wIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAIxSwU7DMAy9I/EPVe5t0nYaqGo7CdBOTEJi CMQtJN4W1qRRkq2Mrydtt24VHLjFfs/P9nPy2Zesgj0YK2pVoDgiKADFai7U ukAvy3l4iwLrqOK0qhUU6AAWzcrrq5zpjNUGnkytwTgBNvBKymZMF2jjnM4w tmwDktrIM5QHV7WR1PnQrLGmbEvXgBNCpliCo5w6ilvBUA+K6CjJ2SCpd6bq BDjDUIEE5SyOoxifuQ6MtH8WdMgFUwp30H6n47iX2pz14MD+smIgNk0TNWk3 hp8/xm+Lx+du1VCo1isGqMw5y5xwFZQ5Pj/9y+4+PoG5Pj0EHmAGqKtNWX0n 8YR1VadUa/YWDk1tuPWFo8hXcrDMCO38CXvZUcKzK2rdwt90JYDfHYYOv5G2 kYG9aH9DmXadhtBv1BnYDwo88JZkvYEn5DW9f1jOUZmQOAnJJEzSZTzJ4puM kPd2oVF9a1GfkMfR/qk4zVIyVjwJ9N6Mv2X5AwAA//8DAFBLAwQUAAYACAAA ACEAmNZi1moJAAC6SAAADwAAAHdvcmQvc3R5bGVzLnhtbMRcbXObOBD+fjP3 Hxi+9+K32EmnbqdJr9fOtL1cncx9xiDHXDHyAW6a/vpbrYQsA4JVIHOfHITY Z9/0rOxoefXmxy7xvrMsj3m69Me/jXyPpSGP4vR+6d/dvn9x4Xt5EaRRkPCU Lf1HlvtvXv/6y6uHl3nxmLDcAwFp/jJb+tui2L88O8vDLdsF+W98z1K4t+HZ LijgMrs/45tNHLJ3PDzsWFqcTUaj+VnGkqAA8Hwb73NfSXugSHvgWbTPeMjy HLTdJVLeLohT/zWoF/HwHdsEh6TIxWV2k6lLdYUf73la5N7DyyAP4/gWFAcT d3HKsw9v0zz24Q4L8uJtHgeNN7diVuOdMC8MaVdxFPtnAjH/CTK/B8nSn0zK kWuhwclYEqT35RhLX9ytTE2Wvh5ag9ylH2QvVm+FsDM0s/w0zN2fGA9XqMo+ CMFxgBNsCgYBhHgInCQWgZ4s5uXF10MCA8Gh4AoEBQCYKRYuKx6HuEKUVzJL 4C7bfOLhNxatCrix9BELBu8+3mQxz+LicelfXgpMGFyxXfwhjiImklKN3aXb OGJ/b1l6l7PoOP7Xe0wxJTHkh7QA9ecLzIIkj37/EbK9SDEQnQYiwl/EA4kQ mxs4qNAhPmojByqoOPhvCTmWMWxE2bJALCMP9W8FQqsPvYEmwiLTAJTrpOu0 v4hZfxHn/UVg8vbzxaK/FkCefSMic8PISnpQCx7K5DP9ML1sSVnxRC2LOp+o JU3nE7Uc6XyilhKdT9QyoPOJWsA7n6jFt/OJWjhbnwgDJK5qFk3RG6SFfRsX CRPPtxLQuCfVqVLj3QRZcJ8F+60nCmtV7TayXB3WBU1VpNOnk+WqyHh63+kR qM5i6T6Zk3/f7bdBHsOOpsP1k56uvw3WCfP+yOKoE+pcJl/NJtyYNJawmyQI 2ZYnEcu8W/ZDRtTh+S/cW8ldRqdyPcP6Kb7fFt5qiyW3E2xucbrdE1L+pzhH H7QuprnFlC7hpBjOLXlpF/6ZRfFhV7qGsBuZSz53CHMFAlVsd9FMhKi+ujqt EAGgmCDLhbsJKJ+gvywu7vJFjCn6y1L0RPkE/WXheqJ8zI/2+Dozzbsg++aR ltfCee1e84Rnm0NSroFOelg4r2ANQTPBeRFr+SSSWDiv4BP69N6GIXxzo+Sp cyyOPOqA4hwOiYKLjW6Lc1AqtDd2sMg5QBWsiQNWP651AHIm3a/seyx+eHIt BsjSeq/ZuZynFg9ACSLtof868KJ7Dz2xcB4V5WMKP5fkzKOhTS0rj4qm8knW O4cY9yt8DkD9KqADUL9S6ABkyQ/7nkfXRDpI/+LogOVMy7qKYdqRmXnhzMwa yK0EDFQ3Cfsvy+q150K9bhJQnANUr5sEFOfoVGqZrpsErMHqJgHLUjXsMTI5 1cUo57ppAumdAMGiYcibADQMeROAhiFvAlB/8u4GGY68CVjO3KA51SRvAhBO cfmqr4FM8iYAOXODZDv1m1FZ91BK+5fbAcibgOIcoDp5E1Cco2MjbwIWTnHJ hAqWpjoC1jDkTQAahrwJQMOQNwFoGPImAA1D3gSg/uTdDTIceROwnLlBc6pJ 3gQgZ3rQQCZ5E4Bwigs3NJI3rvpnJ28CinOA6uRNQHGOToVQ9SaVgOUcoAqW Jm8CFk5xSQaFhcntYtQw5E2waBjyJgANQ94EoGHImwDUn7y7QYYjbwKWMzdo TjXJmwDkTA8ayCRvApAzNzSSNy7GZydvAopzgOrkTUBxjk6FUDXPEbCcA1TB 0uRNwMJ86U3eBCCc8lQgF4uGIW+CRcOQNwFoGPImAPUn726Q4cibgOXMDZpT TfImADnTgwYyyZsA5MwNjeSNa+TZyZuA4hygOnkTUJyjUyFUTd4ELOcAVbA0 1RGwhiFvAhAmZm/yJgDhlCcA4SpyCdMw5E2waBjyJgD1J+9ukOHIm4DlzA2a U03yJgA504MGMsmbAOTMDeKcLZwXJR9PHVuSgHrOoDzVQAacWIJEBVQGfmUb lkEnE+s+HdITsLTQAdGSHlQTrzj/5tEOdk8tCUKGitdJzPFI9yOe0jEaEaaL lk6C2z+vvQ+yAab2HKbU6ckb6B4y24WwPUk0DoGexeMeWnb25clyIQ0ahERf l2oBwj60j9AQpNp6xMOizwcmYlOVGsb/2ypU/Bt63qJyzmg0vpq+G6NFoAuK rCsRbkGLEHqlWpRQR+H16SQ8CF9VyXJeHtU6NmuUyqlz88fdlZx3cnoThux6 F+KMeIvOeIa81XseTpHxrisIbVuoUpeG+rwVzi7WiWxEgz8+piIU0PaH/1uT IY9+BFIs3L9mSfI5wLa1gu/tUxO2KeTd8QjrZEXUmhcF39mfz/AYOWrSJABc bCojL4URdt+nh92aZdAH1uL/L1zUF+xXO01ceSJWhluvPNAe85rqdbtuJ/ms l9E134n2zCOfVbM3SFMOPXyioy7TNItKrgPozPtTNNqhho1roac10OJ4sm6v rhaL6YVMFOjxxEWreyzHc5WYP489lnIMnIKz7c45YZyqc7AZosUvhWiWaHKJ SUbQaPmtdJVyupB7DSwjn+2z0uxeqrV/qobPGa49cdHc8Kk8Buyo/QvNK2hk bvhXjnX79yT5wkMO63IlKL/K6lXPVL2u7mN/inf0HTkVLVFwjIDd3bWk7OO0 1qSErc8/LKzziLFeczWlKTUNR0vjU0jGhvyUNxvcpvCPMXie/FUOXUsbrnP4 HDzbTFNsCafm2HPOcOjRJ3a/DZ1xbg5qzqyrIEk4TxvpTt2TjWFNCWXjOkPo 0S/Pkys1rlOt7prqoFOczHvZydsClv5tsOW7QNR1fA+AORDm+go9c6TMPiUp NPefLZRZdXA1g83I2dPXXr3NHDawhk7g/93fzWviw+3nTzew8cG3DhQsqu3b xATvZIbL6qiKpyyR09+3EM1ekNSagC8F+GIM+CxJXuyeRTrvOaTvZZmptgnj i6l6hYVtxmQxUzsz24zpfD6TaWObMTu/UJsM24zz2aXa5tlmzGfjDk0X00mH pheTWYem4LAOTcejEbxVA8NjU3U8urzs0HU8voTvNu1SJqBux5TpAoivXcps fo7qQnkFfTFb8upLQwZh0mt+yGLoMf7CHkT+le9cAQ6Nd/CKGRj2vgLVYqOQ 4trKI4JwzSE07Mi6ffZcVNZtXLhV6q1xQ1/+raLKkNqrqZ0X1L6qyrqmV//3 2JRf1/LX/wEAAP//AwBQSwMEFAAGAAgAAAAhADJeFme/AQAAHAYAABIAAAB3 b3JkL2ZvbnRUYWJsZS54bWzElG9PgzAQxt+b+B1I3yuFzf3LmNHpXvrC6Afo 4BhNaEt63dBv75WixswlkmgsCQnPtcfx47lbXr+oOjqARWl0xpJLziLQuSmk 3mXs+WlzMWMROqELURsNGXsFZNer87NluyiNdhjReY0Lm7HKuWYRx5hXoARe mgY0xUpjlXD0aHexKUuZw53J9wq0i1POJ7GFWjh6N1ayQdZna3+SrTW2aKzJ AZGKVXXIp4TUbNVXF7ULLRRVvRa13FrZBRqhDUJCsYOoM8ZTvuFXdPfXmI/8 ncU+Q14Ji+A+NvIgl0LJ+vVdxVYihkAjXV696wdhpdjWEEIodxTY45Zn7IbT Su83LChJxsZe4NPbXkmpqH71yuirknd5wpZ5l4cUyvNxisqPw/85IvEkFWD0 AG30aJQIqI6JpHxCJK6IhyczGkTEdnk7gj8kQkbg6c1s+klk9vX7P4mQGzuO p4kkm6FEREUVn7DGLYHwpvAoxn9ujUnyayASPhjE2uytBOvNcYLGlEjMiULa 2YKIDGgUZQqw+ptOKeULFMdt8r+mWAtF8+KUK3xbBE/4Nhk2MIa3x/cDg/Px 3wyMfnLg6g0AAP//AwBQSwMEFAAGAAgAAAAhAFwLZV7rAQAA7gMAABAACAFk b2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAnFPLbtswELwX6D8IuseUnKYJjDWD1kGRQ9sYsJKcWWplEaVI gmSMuF/fpWQ7dNtTdZp9aDmcHcLt66CLHfqgrFmW9awqCzTStspsl+Vj8+Xi pixCFKYV2hpclnsM5S1//w7W3jr0UWEoaIQJy7KP0S0YC7LHQYQZlQ1VOusH ESn0W2a7Tkm8s/JlQBPZvKo+MnyNaFpsL9xpYDlNXOzi/w5trUz8wlOzd0SY Q4OD0yIi/57oaGCnBDQ2Ct2oAXld31DhFMJabDHwGtgE4Nn6NvDL6ytgE4RV L7yQkeTj8/qS/s4S8Mk5raSIpCz/pqS3wXaxeBg1KNIAYHkLkC4blC9exT2v gOUhfFUmUbkGNiHi5sXWC9cHTnSyCDZSaFzR7XkndEBgbwm4R5E2uxaKGMMu LnYoo/VFUL9ot/Oy+CECJs2W5U54JUwk7VLbFIxYuxA9b1TUNJtqUzzCvC3H 6kNSkXoJnDem5MSBCufsxhPCQ0d3i/8gW+dkRw4T1YxOBk9n/DF1ZQcnzJ43 PRafLZI2xSFFuzzUkvg/w6Nr7F1y0EHV82TmhGcV+40TkvY1v6rOPJGVYEPW wZaWfBz4loB72oDX6VTyk9lie+z5u5Bc9jQ9X17PZxV9o62OOfLG6V3x3wAA AP//AwBQSwECLQAUAAYACAAAACEA69NSqHQBAACjBQAAEwAAAAAAAAAAAAAA AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAekRq3 8wAAAE4CAAALAAAAAAAAAAAAAAAAAK0DAABfcmVscy8ucmVsc1BLAQItABQA BgAIAAAAIQCbO7XDCQEAALQDAAAcAAAAAAAAAAAAAAAAANEGAAB3b3JkL19y ZWxzL2RvY3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEJevjbsBwAA qhYAABEAAAAAAAAAAAAAAAAAHAkAAHdvcmQvZG9jdW1lbnQueG1sUEsBAi0A FAAGAAgAAAAhAOkaXzU/CQAAWSYAABEAAAAAAAAAAAAAAAAANxEAAHdvcmQv Y29tbWVudHMueG1sUEsBAi0AFAAGAAgAAAAhAJa1reKWBgAAUBsAABUAAAAA AAAAAAAAAAAApRoAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAI AAAAIQCf7wsC8QIAALIGAAARAAAAAAAAAAAAAAAAAG4hAAB3b3JkL3NldHRp bmdzLnhtbFBLAQItABQABgAIAAAAIQCM1fa9TwEAADQEAAAUAAAAAAAAAAAA AAAAAI4kAAB3b3JkL3dlYlNldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQBM h/tHdwEAAOMCAAARAAAAAAAAAAAAAAAAAA8mAABkb2NQcm9wcy9jb3JlLnht bFBLAQItABQABgAIAAAAIQCY1mLWagkAALpIAAAPAAAAAAAAAAAAAAAAAL0o AAB3b3JkL3N0eWxlcy54bWxQSwECLQAUAAYACAAAACEAMl4WZ78BAAAcBgAA EgAAAAAAAAAAAAAAAABUMgAAd29yZC9mb250VGFibGUueG1sUEsBAi0AFAAG AAgAAAAhAFwLZV7rAQAA7gMAABAAAAAAAAAAAAAAAAAAQzQAAGRvY1Byb3Bz L2FwcC54bWxQSwUGAAAAAAwADAAAAwAAZDcAAAAA ---83809723-123150112-1335198667=:40720-- From fltemplin@yahoo.com Mon Apr 23 09:52: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 5B2E121F85E5 for ; Mon, 23 Apr 2012 09:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[AWL=1.068, BAYES_00=-2.599, HTML_MESSAGE=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 q7Kbe89p5nkd for ; Mon, 23 Apr 2012 09:52:44 -0700 (PDT) Received: from nm39-vm7.bullet.mail.bf1.yahoo.com (nm39-vm7.bullet.mail.bf1.yahoo.com [72.30.239.151]) by ietfa.amsl.com (Postfix) with SMTP id B9FB621F85F9 for ; Mon, 23 Apr 2012 09:52:39 -0700 (PDT) Received: from [98.139.212.151] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 23 Apr 2012 16:52:36 -0000 Received: from [98.139.212.214] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 23 Apr 2012 16:52:36 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 23 Apr 2012 16:52:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 605944.70754.bm@omp1023.mail.bf1.yahoo.com Received: (qmail 27268 invoked by uid 60001); 23 Apr 2012 16:52:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1335199956; bh=V5jPApH5kPbt/6VvhHvjPYUMje4asNCu+/Y2H1J2siQ=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=krqHKTuuJmZ/B77dHqR4zJGH0QHhPUVIPOl3xIDqDAne2op5ZRel2epRonwKrMW+I3K4xy7iv8M9gBhnV4AMBmfkTCJblaJQdeKIt9QdAUzZLXkuZd3eRIJSq8nhwxzCRBB0CVptIRaqH0nOtoirbMSEe3a2ALz1xbmSECDd13E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=5++V9Q2zzvFFO7VYUvO+6LGu4NrIf+IEe4uDmkHYhTnaP7xUqU3vmhuEAZa3aeGcEs8kUFcIigWjlZ2qoEId9ZiY7gQL3gcmPv8XnT7DmiB6wY8jkKsJZg6OO6Ki8X4EgJjmnoyLgRyt56qP0l3Fpu3WiIXTk4iNCoc3PT1oNUY=; X-YMail-OSG: O061kb4VM1lzSjYGLeiYKZfgH3UCVO4LIpiHxgmgysDQkQ9 dTA0._DCTFFXo_vEJAMJUb3oFD9GNO0lCBTGQhwWVgM4uGP1PAQVJyr3gfyU mPUUb5RWVtWpAPAPLoC8p5FiAwX97cMtuUNdJObl8whhc7WL3J.HRP__GU1I hY345a70A43tURlGu58OE0Z3TfWTGVnT.pH3CP8Bz5_csChs6aJXS_bJB55J OdHHvmkXwuhB7HSHSnlw1veDRVvkPwbaDvh15H6K6co2ZF6_DY4HdEPYhTBV QQgPRzsVLqDSDBBPRR6BGcfPieC0MZZ8A_hv4JYPeCKRfUjyV7MiA01OY.90 zVMNac.4hQlMI4K3sCNSTfPqlqa9OQcIhalZSN.JxeOSab0xA3QJB8bLcN_9 61gjP2a6d47YdUjCLGNVG0EKfOnnTFB4K50Pmh44tOEp3Hvxtwk9cqEZ.Kd9 qVGg7zNGVzEiZtVVyV9AC79wC8E9uh76tDNU4yfkDPPdYCb7AcoVJyTB.xh4 g2VGTT03e1hltzl.wyp9YTt2X_k1ucglcnq_JLfMIWxtUgrARzBwY Received: from [130.76.32.197] by web161604.mail.bf1.yahoo.com via HTTP; Mon, 23 Apr 2012 09:52:36 PDT X-Mailer: YahooMailWebService/0.8.117.340979 References: <36214B77-821E-47B9-8349-A89D2800E24C@cisco.com> Message-ID: <1335199956.12137.YahooMailNeo@web161604.mail.bf1.yahoo.com> Date: Mon, 23 Apr 2012 09:52:36 -0700 (PDT) From: Fred Templin To: Joe Salowey , "secdir@ietf.org" , The IESG , "draft-templin-aero.all@tools.ietf.org" In-Reply-To: <36214B77-821E-47B9-8349-A89D2800E24C@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="397762125-199359350-1335199956=:12137" X-Mailman-Approved-At: Mon, 23 Apr 2012 09:56:23 -0700 Subject: Re: [secdir] secdir review of draft-templin-aero-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Fred Templin List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 16:52:46 -0000 --397762125-199359350-1335199956=:12137 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable (Resending with comments as inline text)=0A=0AHello Joe,=0A=0AThank you for= these comments. Please see below for my proposed=0Aresolutions:=0A=0AFred= =0Afltemplin@acm.org=0A=0A=0A=0A>________________________________=0A> From:= Joe Salowey =0A>To: secdir@ietf.org; The IESG ; draft-templin-aero.all@tools.ietf.org =0A>Sent: Sunday, April 22, = 2012 3:00 PM=0A>Subject: secdir review of draft-templin-aero-10=0A> =0A>I h= ave reviewed this document as part of the security directorate's =0A>ongoin= g effort to review all IETF documents being processed by the =0A>IESG.=C2= =A0 These comments were written primarily for the benefit of the =0A>securi= ty area directors.=C2=A0 Document editors and WG chairs should treat =0A>th= ese comments just like any other last call comments.=0A>=0A>I apologize for= the delay in getting this review out.=C2=A0 Hopefully it is still useful.= =C2=A0 =0A>=0A>This first set of comments is primarily for the authors.=0A>= =0A>1. In section 4.4.4 on Data origin authentication the last paragraph st= ates that only the 3rd of the above conditions is acceptable, do you really= mean the 4th?=0A>=0A>>>> Begin FLT response=0A>=0A>You are correct; this s= hould say the 4th and=0Acan be fixed in the next version.>>> End FLT respon= se=0A>=0A>2. In section 4.4.4 there is reference to the packet including a = digital signature to authenticate the origin.=C2=A0 What is the signature m= echanism?=C2=A0 Is this SEND or something different? I did not see a refere= nce to it.=0A>=0A>>>> Begin FLT response=0A>=0A>The digital signature mecha= nism is out of scope for=0Athis document. The text=0A>could be adjusted to = say: =E2=80=9C=E2=80=A6, AERO nodes may be obliged=0Ato require the=0A>use = of digital signatures applied through means outside the=0Ascope of this=0A>= document.=E2=80=9D>>> End FLT response=0A>=0A>3. The security consideration= s do not say much about the consequences of trusting an inappropriate inter= mediate router, ingress node or egress node. Clearly DOS to the ingress nod= e is a possibility.=C2=A0 Data modification and disclosure can be a goal o= f an attacker who tries to control the routing.=C2=A0 Are there other issu= es the reader should be aware of (perhaps other DOS attacks such as amplifi= cation attacks).=C2=A0 Anything outside the considerations of RFC4861)?=0A>= =0A>>>> Begin FLT response=0A>=0A>Proposed resolution is to re-write the fi= rst paragraph=0Aof Section 6 as follows:=0A>=C2=A0=0A>=E2=80=9CAERO link se= curity considerations are the same as for standard=0AIPv6 Neighbor Discover= y=0A>(RFC4861) except that AERO improves on some aspects. In=0Aparticular, = AERO is dependent=0A>on a trust basis between AERO edge nodes and intermedi= ate=0Arouters, where the edge nodes=0A>must only engage in the AERO mechani= sm when it is=0Afacilitated by a trusted intermediate=0A>router.=E2=80=9D>>= > End FLT response=0A>=0A>4. The security consideration section indicates t= hat spoofing protection can be provided by links that provide link layer se= curity mechanisms.=C2=A0 =C2=A0 Link Layer security mechanisms may or may n= ot help.=C2=A0 I believe more information is needed here.=C2=A0 L2 mechani= sms may not provide adequate protection of upper layer address bindings.=C2= =A0 In some cases L2 mechanisms do not provide source origin authentication= such as multicast=C2=A0 traffic protected with the group=C2=A0 key in WiFi= and group security associations in 802.1AE (MACSEC).=0A>=0A>>>> Begin FLT = response=0A>=0A>Proposed resolution is to re-write the second paragraph=0Ao= f Section 6 as follows:=0A>=E2=80=9CAERO links must be protected against sp= oofing attacks in which an attacker=0A>on the link pretends to be a trusted= neighbor.=C2=A0 Links that provide link-layer=0A>securing mechanisms (e.g.= , WiFi networks) and links that provide physical=0A>security (e.g., enterpr= ise network LANs) provide only a fist-line of defense.In some instances, th= erefore, additional=0Asecuring assurances against on-link=0A>spoofing attac= ks are required. For example,=0Aif the source can through some=0A>means dig= itally sign its messages the=0Adestination can verify the signatures to=0A>= ensure data origin authentication.=0AExact mechanisms for digitally signing= and=0A>verifying signatures are outside the=0Ascope of this document.=E2= =80=9D=0A>>>> End FLT response=0A>=0A>This set of comments is mostly for th= e area directors:=0A>=0A>1. I am mostly concerned about the lack of definit= ion for the digital signature mechanism.=C2=A0 Perhaps this is easily recti= fied by a reference to an existing specification. Its not clear to me what = the specification would be (perhaps SEND??)?=C2=A0 Is something needed in a= ddition? =0A>2.=C2=A0 The risks of not securing the proposal are not define= d in the security considerations section. I think this would be helpful, bu= t may not be strictly necessary.=C2=A0 There is some mention of Link-Layer = security helping in some aspects of this, but its not clear on what charact= eristics the lower layer security needs to provide. =0A>=0A>Cheers,=0A>=0A>= Joe=0A>=0A> --397762125-199359350-1335199956=:12137 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
(Resending= with comments as inline text)
=0A=0A

=0A
=0A=0AHello Joe,
=0A=0A

=0A=0AThank you for these comments. Please see below for my proposed=0A=0A
resolutions:
=0A=0A

=0A=0A
Fred
=0A=0A= =0A

From: Joe Salowey <jsalowe= y@cisco.com>
To: se= cdir@ietf.org; The IESG <iesg@ietf.org>; draft-templin-aero.all@tools= .ietf.org
Sent: Sunda= y, April 22, 2012 3:00 PM
Subject= : secdir review of draft-templin-aero-10

= =0AI 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
se= curity area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

I apologize= for the delay in getting this review out.  Hopefully it is still usef= ul. 

This first set of comments is primarily for the authors.<= br>
1. In section 4.4.4 on Data origin authentication the last paragraph= states that only the 3rd of the above conditions is acceptable, do you rea= lly mean the 4th?

>>> Begin FLT response
=0A=0A
You are corre= ct; this should say the 4th and=0Acan be fixed in the next versi= on.
=0A=0A>>> End FLT response

2. In section 4.4.4 the= re is reference to the packet including a digital signature to authenticate= the origin.  What is the signature mechanism?  Is this SEND or s= omething different? I did not see a reference to it.

>>> Be= gin FLT response
= =0A=0A
The digital signature mechanism is out = of scope for=0Athis document. The text
c= ould be adjusted to say: =E2=80=9C=E2=80=A6, AERO nodes may be obliged=0Ato= require the
use of digital signatures a= pplied through means outside the=0Ascope of this
document.=E2=80=9D
=0A=0A>>> End FLT response
3. The security considerations do not say much about the consequences of t= rusting an inappropriate intermediate router, ingress node or egress node. = Clearly DOS to the ingress node is a possibility.  Data modification = and disclosure can be a goal of an attacker who tries to control the routin= g.  Are there other issues the reader should be aware of (perhaps oth= er DOS attacks such as amplification attacks).  Anything outside the c= onsiderations of RFC4861)?

>>> Begin FLT response
=0A=0A
Proposed resolution is to re-write= the first paragraph=0Aof Section 6 as follows:
=0A=0A
 
=0A=0A
=E2=80=9CAERO link security considerations are the sa= me as for standard=0AIPv6 Neighbor Discovery
(RFC4861) except that AERO im= proves on some aspects. In=0Aparticular, AERO is dependent
on a trust basis= between AERO edge nodes and intermediate=0Arouters, where the edge nodes
m= ust only engage in the AERO mechanism when it is=0Afacilitated by a trusted= intermediate
router.=E2=80=9D
=0A=0A>>>= ; End FLT response

4. The security consideration section indicates t= hat spoofing protection can be provided by links that provide link layer se= curity mechanisms.    Link Layer security mechanisms may or may n= ot help.  I believe more information is needed here.  L2 mechani= sms may not provide adequate protection of upper layer address bindings.&nb= sp; In some cases L2 mechanisms do not provide source origin authentication= such as multicast  traffic protected with the group  key in WiFi= and group security associations in 802.1AE (MACSEC).

>>> B= egin FLT response
= =0A=0A
Proposed resolution is to re-write the = second paragraph=0Aof Section 6 as follows:
=0A=0A=0A=0A
=E2=80=9CAERO links=
 must be protected against spoofing attacks in which an attacker
on the =
link pretends to be a trusted neighbor.&nb=
sp; Links that provide link-layer
securing mechanisms (e.g., WiFi=
 networks) and links that provide physical
security (e.g., enterprise ne=
twork LANs) provide only a fist-line of defense.
In some instances, therefore, additional=0Asecuring assuran= ces against on-link
spoofing attacks are required. For example,=0Aif the= source can through some
means digitally sign its messages the=0Adestina= tion can verify the signatures to
ensure data origin authentication.=0AE= xact mechanisms for digitally signing and
verifying signatures are outsi= de the=0Ascope of this document.=E2=80=9D
>>> End FLT re= sponse

This set of comments is mostly for the area directors:
1. I am mostly concerned about the lack of definition for the digital sign= ature mechanism.  Perhaps this is easily rectified by a reference to a= n existing specification. Its not clear to me what the specification would = be (perhaps SEND??)?  Is something needed in addition?
2.  Th= e risks of not securing the proposal are not defined in the security consid= erations section. I think this would be helpful, but may not be strictly ne= cessary.  There is some mention of Link-Layer security helping in some= aspects of this, but its not clear on what characteristics the lower layer= security needs to provide.

Cheers,

Joe

--397762125-199359350-1335199956=:12137-- From jsalowey@cisco.com Mon Apr 23 14:06: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 9111411E8080; Mon, 23 Apr 2012 14:06:46 -0700 (PDT) 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 XU+tgra5LSZH; Mon, 23 Apr 2012 14:06:44 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id E22E111E8072; Mon, 23 Apr 2012 14:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=21099; q=dns/txt; s=iport; t=1335215204; x=1336424804; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=0voL154cOWEujyd81yhd6E8kIsLzlYV4mBdmYaAnjyc=; b=cbINo9eh8Bgkx6jYsaPjAXmrRSJaxaOHbFkDYjbmF4b79H6sz5dJ1xId DFiYDKUVjSk0XlfjiNNOqMo0/jzA+6Ronx1b4y2R3DbycruVJH1RuFnxZ lvJbgLWVL7m1bAxAK9FG8buM3gG8tOHVyaTHCswTVRvJvdUzdCvGJ4kY1 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgFAF3DlU+rRDoI/2dsb2JhbAAuDAEJgx2uQoEHggkBAQEDAQEBAQ8BJy0FAggDBQsLDh0bJzAGEQIih2gEDJpFoDCJaHsLAQiFdWMEiGOCY4o0gRGEY2yHdYFpgwkegRgGEQ X-IronPort-AV: E=Sophos;i="4.75,469,1330905600"; d="scan'208";a="38722353" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 23 Apr 2012 21:06:44 +0000 Received: from [10.33.248.250] ([10.33.248.250]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3NL6hew019524; Mon, 23 Apr 2012 21:06:43 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: Date: Mon, 23 Apr 2012 14:06:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stephen Hanna X-Mailer: Apple Mail (2.1084) Cc: Sam Hartman , draft-ietf-emu-chbind@tools.ietf.org, IETF-Discussion list , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-emu-chbind-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: Mon, 23 Apr 2012 21:06:46 -0000 Hi Steve, Thanks for taking time to perform a detailed review the document. = Comments inline below: On Apr 13, 2012, at 11:26 AM, Stephen Hanna wrote: > 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. I apologize > for submitting these comments a day after the IETF LC closed. > Other commitments delayed my work. I hope these are still useful. >=20 > Thanks, >=20 > Steve >=20 > ------ >=20 > secdir review of draft-ietf-emu-chbind-14 >=20 > This document defines channel bindings for EAP methods, providing > a way to address the lying NAS and lying provider problems. >=20 > Overall, I have no objections to this document. However, > I do have some comments. I have divided these comments > into substantive and non-substantive ones. >=20 > Substantive Comments > -------------------- >=20 > In the Introduction, the second paragraph says that the > problem "results when the same credentials are used to > access multiple services that differ in some interesting > property". Do you mean client or server credentials? > I think you mean EAP server credentials. Please be more=20 > explicit to make this clearer, since many people will > assume that you mean client (EAP peer) credentials. If > I'm correct and you do mean EAP server credentials, > I suggest that you say so in the first sentence of > this paragraph and also in the last sentence. >=20 [Joe] The case here is both client and server credentials. If = different credentials are required for each type of service then the = authenticator will not be able to lie about the type of service it is = representing to the client because the client credentials are bound to = the service.=20 > In the next paragraph, you give an example where a low > security network is used to read email and a high security > network is use to access valuable confidential information. > A better example would be to use the low security network > for web surfing. Reading email can require a lot of security. >=20 [Joe] OK=20 > In the first paragraph of the Problem Statement, the second > sentence says "However, when operating in pass-through mode, > the EAP server can be far removed from the authenticator." > While this is true, I think the more relevant statement here > is that the EAP server can be far removed from the EAP peer. > This paragraph is all about problems that can arise when > parties between the EAP peer and the EAP server (including > the authenticator) are malicious or compromised. So the > important thing to point out at the start of the paragraph > is the large number of parties that may come between the > EAP server and the EAP peer. >=20 [Joe] I think I see your point, but I'm not sure. Traditionally, we = have often thought of the path between EAP peer and EAP authenticator as = being vulnerable to having multiple parties able to insert themselves = into the conversation. However it may be the case that the = authenticator the peer is talking to isn't the one it thinks it is and = the "real" authenticator may be somewhere in the path as well. The = conversation between the EAP peer and EAP server will not be = compromised, however the result of the conversation may not have its = intended effect. =20 > In the second bullet of section 3 (on page 7), the EAP GSS-API > mechanism is a good example. However, I wonder if this attack > might take a slightly different form. Could the IM server > pretend to be the mail server? I think so. That's just one > specific example of a relatively untrusted service pretending > to be a relatively trusted service. I suggest that you add > an example like that since the current language is quite > abstract. >=20 [Joe] I agree having a more concrete example would be helpful. =20 > Overall, I found the document too abstract for my taste. When > I read an RFC that's defining a protocol to be implemented, > I prefer to read a description of the problem to be solved > and then a clear definition of the protocol. This document > reads like a combination of an academic paper and a protocol > definition. For example, section 4.1 describes two categories > of approach to EAP channel bindings: exchanging the actual > network information or encoding the network information into > a blob that is used to derive EAP session keys. The rest of > section 4.1 goes on to discuss the pros and cons of these > approaches. Then section 4.2 defines a bunch of requirements > for transporting channel bindings in a lower layer's secure > association protocol. While that's interesting, the actual > protocol defined in this document sends the actual network > information in EAP. Why bother spending several pages talking > about things that this protocol doesn't actually do? [Joe] THis is historical and reflects the discussion we had in the = working as the document was being developed.=20 > I see > several downsides to including that text in this document. > First, you're making it harder for the reader to understand > what they actually need to do to implement this protocol. > You've probably decreased by half the number of people who > will actually read all of this document. Second, some people > will use that digression to support arguments like ("My > incompatible implementation is compliant with RFC XXXX > because I encoded the network information into a blob > and used that to generate EAP session keys"). IETF is an > engineering organization. We should make our specs as clear > and simple as possible and no simpler. This document includes > lots of interesting theory that's not needed for its purpose. > If you're interested in seeing this document widely implemented, > I suggest that you remove as much of that as possible and focus > the document on explaining the problem and defining a protocol > that solves it. Or you can leave it as is. I'm sure some people > will implement it. Just not as many. Friendly suggestion. Take > it or leave it. >=20 [Joe] I can see your point, but I think some members of the working = group would object if we removed some of this material. If its not = clear perhaps we can so a better job of indicating what is normative and = what is informative.=20 > In the first paragraph of section 5.1, you say that "the > EAP server needs to be able to access information from the > AAA server that is utilized during the EAP session and a > local database". Which information? A parenthetical example > (an e.g.) would help with understanding what you mean. >=20 [Joe] OK > In section 7.1, you explain that this document isn't useful > without an accompanying document defining what information > should be included in i1 for each lower layer. Are those > documents being prepared for all or at least some of the > lower layers? I couldn't find any in a quick search. I know > we can't wait for everything to be ready but it would be > nice to see at least one or two of those documents so that > we can have confidence that this protocol can support all > the things that those documents will need. >=20 [Joe] That not how I interpret the text in section 7.1. This document = does specify a general attribute that can be used to specify the type of = lower layer used to carry EAP. Section 7.1 states that additional = documents will be needed to specify attributes specific to a particular = lower layer. ABFAB is working on a document that contains this = information for their lower layer, draft-ietf-abfab-gss-eap. > In section 7.2, you define a new RADIUS attribute that > identifies the EAP lower layer in use. But you say in > the first sentence of that section that this attribute > is defined to "carry the EAP lower layer". That sounds > like all the lower layer traffic will be encapsulated > in this attribute and carried in it. I think you should > change the word "carry" in that text to "identify". > Unless I misunderstood you. >=20 [Joe] OK > As I read section 8, I wonder whether include the User-Name > attribute in i2 could open the system up to attacks where > an authenticator or intermediate proxy could remove the > anonymity of a user who's using a pseudonym for the > username by changing the value of the User-Name attribute > to the username of the user suspected of being responsible > for this authentication. If the channel bindings checks > fail, the authenticator will know they were wrong but if > the channel bindings checks succeed, the authenticator > will have confirmation of the user's identity. >=20 [Joe] Perhaps, on the one hand I would think the system would not behave = this way, the server would be expecting a pseudonym or token and fail if = it got something else. On the other hand, I don' think the text for the = user-name check or the test itself are that useful. We could either = warn against the possible identity disclosure or remove the user-name = check. =20 > I didn't understand that sending i2 from the server to > the peer is optional until I got to section 9.1. In section > 5.3, you said that "For success, the server returns the > attributes that were considered by the server in making > the determination that channel bindings are successfully > validated". Which of these is right? >=20 [Joe] The server is required to return the channel-binding attributes = it verified because the client may require certain attributes to be = checked. This list of verified attributes is not equivalent to i2. i2 = is what attributes are sent in the AAA protocol and I don't think it = should be referenced here. Instead it should probably say: "sending the result from server to peer over integrity-protected = channel" > At the top of page 23, you say that "In many EAP deployments > today attacks where one NAS can impersonate another are > out of scope." Do you mean that these attacks are generally > not considered but they are a potential problem? Or that > they are not a problem? I think they are always a possible > problem. Even when all the NASes are owned and managed by > the same organization that runs the AAA server and no proxies > are used, there's still the potential for a NAS to become > compromised. So I think you should say these attacks are > "not considered although a real concern" not that they are > "out of scope". [Joe] As EAP is deployed in most cases today the authenticator is not = identified, it is merely authorized as being part of the network. The = peer does not expect differentiated service based on the NAS it is = connected to. Since the service is the same it does not matter to the = peer if one authenticator impersonates another. When we start = discussing use case such as ABFAB where different services are being = provided did the identity of the authenticator really become an issue. =20= Perhaps the following text is better "In many EAP deployments today attacks where one authenticator can = impersonate another not a real concern since different authenticators = provide the same service. In these situations an authenticator does not = gain significant advantage in impersonating another authenticator. " > And then the following sentence says that > "Channel bindings brings these attacks into scope". Again, > I think those attacks are always a potential issue. Channel > bindings provide a good way to address them, whereas there > were few ways to do so before. Maybe it would be better to > say that. >=20 [Joe] I see your point here, how about: "The use of EAP in situations where different authenticators provide = different services makes the ability to authorize different = authenticators more important. The system as a whole needs to be = analyzed to evaluate cases where one authenticator may impersonate another and to = evaluate the impact of this impersonation. Channel bindings provides a = way to address these issues. " > In the next paragraph, you say that when cryptographic binding > is used in a tunnel method, the MSK is disclosed to the NAS. > I don't think that's right. The MSK that's disclosed to the > NAS is the one generated by the outer method. The MSK that's > used in cryptographic binding is the one that's generated by > the inner method. I don't think there's a problem there. >=20 [Joe] OK, this test is referring to where there is separate between the = terminating server of the inner and outer methods. Maybe it would be = clearer if the text said the following: "Even when cryptographic binding does attempt to confirm that the inner = and outer server are the same, the Master Session Key (MSK) from the = inner method is typically used to protect the binding. However, if the = outer method tunnel terminates on the authenticator the inner MSK is = disclosed to the authenticator, which can attack cryptographic binding."=20= > Later in that paragraph, you say that an attack where the NAS > terminates an EAP tunnel method is not in scope for existing > models for cryptographic binding. I think that's wrong also. > EAP tunnel methods protect against just this sort of attack. > The first step in these methods is for the EAP peer and the > EAP server to build a TLS tunnel. This requires the EAP peer > to authenticate the EAP server and decide whether it's trusted. > If the NAS has credentials that will cause the EAP peer to > trust it as an EAP server, a MITM attack is possible. Of course, > that's true for any secure communications and it's a very bad > situation. That's why the EAP peer must be very careful about > who it trusts and how it authenticates them and the EAP server > (and any CAs or other TTPs) must also be similarly careful. > I don't see that any of this has much to do with channel bindings. > Am I missing something here? If so, please explain it. And maybe > you can clarify the text so that other folks get it also. >=20 [Joe] The issue is when you have different services the client may not = have enough information to determine what an authenticator is authorized = for based on its identity alone. In this case it would like help from = the server that terminates the inner method. However current crypto = binding is based on the MSK so the authenticator can generate whatever = channel binding quantities it wants because the authenticator has all = the necessary key material. In order for channel bindings to determine = if the authenticator is authorized or not, the method needs protect = the channel bindings with a key generated from the inner method EMSK = that the authenticator does not possess. Here is some text that may = help: "If the authenticator controls the cryptographic binding then it also = controls the channel binding parameters and results. If the channel = binding process is used to differentiate one authenticator from another = then the authenticator can claim to support services that it was not = authorized to. This attack was not in scope for existing threat models = for cryptographic binding because differentiated authenticators was not = a consideration. Thus, existing cryptographic binding does not = typically provide mutual authentication of the inner method server = required for channel binding." > In section 9.2, this paragraph appears: >=20 > Dishonest peers can only manipulate the first message i1 of the > channel binding protocol. In this scenario, a peer sends i1' to the > server. If i1' is invalid, the channel binding validation will = fail. > On the other hand if i1' passes the validation, either the original > i1 was wrong and i1' corrected the problem or both i1 and i1' > constitute valid information. A peer could potentially gain an > advantage in auditing or charging if both are valid and information > from i1 is used for auditing or charging. Such peers can be = detected > by including the information in i2 and checking i1 against i2. >=20 > In the penultimate sentence, I think you mean "information from > i1' is used for auditing or charging." There's no problem if > information from i1 is used for auditing. If that happens, the > bad peer's information is being ignored. >=20 [Joe] I think you are correct. > That paragraph does make me wonder about another attack that > could be enabled by channel bindings. What if a malicious peer > gets perfectly good i1 from a NAS but then sends bad i1' to > the EAP server with a goal of damaging the reputation of the > NAS? The EAP peer could be working for a competitor of the > organization that runs the NAS or just be malicious. Is that > a valid concern? If so, maybe you should cite it and suggest > a countermeasure. >=20 [Joe] I think this is a valid concern for some environments. I think we = should add a section for that. =20 > In section 9.4, you refer to "the optional result message". > I didn't know before this that the result message was optional. > Could you make that clear earlier? >=20 [Joe] The result message is not intended to be optional. This text = needs to be fixed.=20 > In the IANA Considerations, you talk about creating a new > "EAP Channel Binding Parameters" top level registry. That's > fine. But then you talk about a "Channel Binding Codes" > registry. Didn't you mean a "sub registry"? If you want > the Channel Binding Codes registry to be in the EAP Channel > Binding Paramters registry, I think the first one is really > a sub registry. [Joe] Yes > Also, you say that "Early allocation is > allowed" for that registry. What does that mean? I don't > see any description of "early allocation" in RFC 5226. > I expect that IANA will want to know what they need to > do to provide "early allocation". How early? Etc. >=20 [Joe] OK, I need to check if there is any convention here.=20 > In the definition of the "Channel Binding Namespaces" > registry, did you want to include a reference column > as you did in the "Channel Binding Codes" registry? > If so, maybe you should say so. >=20 [Joe] OK > At the end of section 11.1, a sentence says that > "Values skipped in the above table are available > for assignment." I don't think any values were skipped > so I don't think you need that sentence. >=20 [Joe] Yup, left over from previous version.=20 > Appendix A is pretty similar to section 1. Might you > be able to merge them somehow? >=20 [Joe] I think the authors attempted to do this and then decided it was = better to keep them separate.=20 > In section A.3, you describe downgrading attacks and > how channel bindings can prevent them. However, I think > this will only work if the EAP peer rejects all methods > that don't include channel bindings. Otherwise, the NAS > can just offer an unauthorized EAP method that permits > it to obtain the user's credentials and off to the bank. >=20 [Joe] I believe you are correct.=20 > Non-Substantive Comments > ------------------------ >=20 > In the top right header of the first page, the organization > for T. Clancy should probably be Virginia Tech not Electrical > and Computer Engineering. >=20 > In the fourth paragraph of the Introduction, I think you should > add the word "the" before "lying provider" problem. In the last > sentence of that paragraph, I'd suggest adding "also" before > "gain access". That should make things clearer. >=20 > In the first bullet in section 3 (at the bottom of page 6), > "virtual Lads" should probably be "virtual LANs". Unless you > are talking about some other phenomenon! ;-) >=20 > In the second paragraph of section 4.3, the phrase "More often > it is useful" can be confusing. The word "it" seems to refer > to the subject of the previous sentence ("verification of the > MAC or IP address of the NAS"). Actually, the word "it" refers > to the idea of making policy decisions about services but that > idea doesn't appear until later in the sentence. I suggest that > you reword the sentence to say "More often the best approach is > to make policy decisions [...]". >=20 > In the first sentence of section 8, the phrase "a AAA Accept- > Request messages" can't be right. Is it singular or plural? > I think it's plural so the word "a" should be removed. >=20 > In section 12 (Acknowledgements), I think Sam Hartman's last > name should be capitalized. >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From hartmans@mit.edu Mon Apr 23 17:56:36 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 A3AD321F86B4; Mon, 23 Apr 2012 17:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.085 X-Spam-Level: X-Spam-Status: No, score=-103.085 tagged_above=-999 required=5 tests=[AWL=-0.820, 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 LHMivpDuCW1F; Mon, 23 Apr 2012 17:56:36 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id DAAB021F8702; Mon, 23 Apr 2012 17:56:34 -0700 (PDT) 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 4CBDB2024B; Mon, 23 Apr 2012 20:52:08 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6EF444765; Mon, 23 Apr 2012 20:56:29 -0400 (EDT) From: Sam Hartman To: Joe Salowey References: Date: Mon, 23 Apr 2012 20:56:29 -0400 In-Reply-To: (Joe Salowey's message of "Mon, 23 Apr 2012 14:06:38 -0700") 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 Cc: Sam Hartman , draft-ietf-emu-chbind@tools.ietf.org, IETF-Discussion list , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-emu-chbind-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: Tue, 24 Apr 2012 00:56:36 -0000 First, Steve, thanks for an excellent review. You detected some really important fixes we need to make! Hi. I'll respond in more detail later. I generally agree with Joe's comments. I want to respond to the IANA issues so Joe doesn't have to dig around. Early allocation is a well-defined concept; I forgot to reference the appropriate RFC, but IANA does (and according to their last call comments did in this case) understand it. IANA also correctly assumed the codes registry is a sub-registry not a new top-level registry. I don't mind fixing, but I'll point out that IANA was not actually confused nor did they request clarification. From shanna@juniper.net Tue Apr 24 05:28:15 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 38BC021F879F; Tue, 24 Apr 2012 05:28:15 -0700 (PDT) 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 3b2tJLQ+W6Rn; Tue, 24 Apr 2012 05:28:14 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 5087921F87B5; Tue, 24 Apr 2012 05:28:07 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT5acVuOYK943RFH/ibq1enXYgFyAIuSm@postini.com; Tue, 24 Apr 2012 05:28:14 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 24 Apr 2012 05:27:52 -0700 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; Tue, 24 Apr 2012 08:27:51 -0400 From: Stephen Hanna To: Sam Hartman , Joe Salowey Date: Tue, 24 Apr 2012 08:27:50 -0400 Thread-Topic: [secdir] secdir review of draft-ietf-emu-chbind-14 Thread-Index: Ac0htRmuRcaFLJq2R/O+K2D8hhcQiwAX5ddA Message-ID: References: In-Reply-To: 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 Cc: "draft-ietf-emu-chbind@tools.ietf.org" , IETF-Discussion list , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-emu-chbind-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: Tue, 24 Apr 2012 12:28:15 -0000 Sam, I'm glad that my review was helpful. That's just what I hoped. I wanted to provide the perspective of a new reader, someone who wasn't deeply involved in the development of the document. After all, that's one of the main purposes of publishing an RFC: to get this information out to a broader community, a bunch of new readers. And I'm happy to hear that all the IANA Considerations were clear to the IANA team. I appreciate your plans to add a reference to the RFC that defines "early allocation". That will help ensure that the IANA Considerations are clear not only to IANA but also to the more casual reader. Joe's response to my review was very helpful also. He answered many of my questions and concerns. I'm working on a response to Joe's email now. And I look forward to seeing your more detailed response also. Thanks, Steve > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Monday, April 23, 2012 8:56 PM > To: Joe Salowey > Cc: Stephen Hanna; draft-ietf-emu-chbind@tools.ietf.org; > secdir@ietf.org; IETF-Discussion list; Sam Hartman > Subject: Re: [secdir] secdir review of draft-ietf-emu-chbind-14 > Importance: High >=20 >=20 > First, Steve, thanks for an excellent review. > You detected some really important fixes we need to make! >=20 > Hi. I'll respond in more detail later. I generally agree with Joe's > comments. > I want to respond to the IANA issues so Joe doesn't have to dig around. >=20 > Early allocation is a well-defined concept; I forgot to reference the > appropriate RFC, but IANA does (and according to their last call > comments did in this case) understand it. >=20 > IANA also correctly assumed the codes registry is a sub-registry not a > new top-level registry. >=20 > I don't mind fixing, but I'll point out that IANA was not actually > confused nor did they request clarification. From clonvick@cisco.com Tue Apr 24 07:22:38 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 4782821F87FD; Tue, 24 Apr 2012 07:22:38 -0700 (PDT) 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 FNLhobXYYQqw; Tue, 24 Apr 2012 07:22:37 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0324721F87F7; Tue, 24 Apr 2012 07:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=clonvick@cisco.com; l=803; q=dns/txt; s=iport; t=1335277356; x=1336486956; h=date:from:to:subject:message-id:mime-version; bh=bHQc1DY7Xl8Rk9CowAIN5jVsUAmnRBKNVEqebt2j6Dc=; b=TAo+/sahgwOpPbApyVP8q5vXv+BerGkp12IBIVHy2gPtE+LAPj5AMu75 Pj+XaRKfD0j4z4FTV8Z+ceXH6FjMWTHacW8KuIEsNtdTN9IgauL1teanW 9gbuElC1PVjMYZyZ9cJBgjAUCRkkoIiBOHLsvcxyirT7nrEgMWGTDGsEM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUHAMi2lk+rRDoJ/2dsb2JhbABEoDMBkUOBB4IiASUCgX40h2yaT6BQkVEEiGObbIFpgwk X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208";a="41849910" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 24 Apr 2012 14:22:35 +0000 Received: from sjc-cde-026.cisco.com (sjc-cde-026.cisco.com [171.69.20.33]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3OEMZRh030300; Tue, 24 Apr 2012 14:22:35 GMT Date: Tue, 24 Apr 2012 07:22:35 -0700 (PDT) From: Chris Lonvick To: draft-ietf-mboned-mcaddrdoc.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [secdir] SECDIR review of draft-ietf-mboned-mcaddrdoc-03.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, 24 Apr 2012 14:22:38 -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. Well, this is pretty straightforward. The document explains that it is requesting addresses to be set aside for examples in the documentation of multicast. It goes through each case and lists the addresses that are to be used. I find the document to be well written and to the point. The security considerations section is appropriate and consistent with other IETF documents requesting namespace for documentation purposes. Regards, Chris From kivinen@iki.fi Tue Apr 24 10:05:28 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 8FD9321E8093; Tue, 24 Apr 2012 10:05:28 -0700 (PDT) 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 vpSuqYx3brMr; Tue, 24 Apr 2012 10:05:28 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A9621E8086; Tue, 24 Apr 2012 10:05:25 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.3) with ESMTP id q3OH5NsK021734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2012 20:05:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q3OH5LvR024256; Tue, 24 Apr 2012 20:05:21 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20374.56656.896904.834654@fireball.kivinen.iki.fi> Date: Tue, 24 Apr 2012 20:05:20 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sipcore-rfc3265bis.all@tools.ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min Subject: [secdir] Secdir review of draft-ietf-sipcore-rfc3265bis-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, 24 Apr 2012 17:05:28 -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 is new version of the SIP-specific event notification mechanism (RFC3265). This document does not describe exact notifications, but only the mechanism over which such notifications can be created. As such its security considerations are very generic. The security considerations section is mostly same as what was in the RFC3265 and it seems to be ok. I do not have any comments related to this document. -- kivinen@iki.fi From jsalowey@cisco.com Tue Apr 24 10:47: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 50E2711E80B2; Tue, 24 Apr 2012 10:47:56 -0700 (PDT) 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 t+0cJoiQEG17; Tue, 24 Apr 2012 10:47:55 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6654E11E80B7; Tue, 24 Apr 2012 10:47:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=5649; q=dns/txt; s=iport; t=1335289675; x=1336499275; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=2rXQ40EjHyO8dWKSUcOVDevEr/uhZIAqnJvdra1OZLE=; b=bJmSsrn7a8fjNkTCMsKZ169gEjGpdNyOVtnShn7p3wRcWpC0hjrWPjaW 4TJ8/SaPnb8uUlV8fMLKfZxBIGsImBSN1cfm8PDeiVTV57POprY86sGr8 HPS+cHMKuVE8pH1TwPel0kf3MH3or6LMrNY1542Ahf+irAJdzH023/o/m g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0GADfmlk+rRDoG/2dsb2JhbABEgx2uXIEHggkBAQEDARIBZgULCw4DBAEBL08IBhMih2gEmlGgPZBuYwSIY40XhXSIYYFpgwk X-IronPort-AV: E=Sophos;i="4.75,474,1330905600"; d="scan'208";a="41977562" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 24 Apr 2012 17:47:53 +0000 Received: from [10.33.248.250] ([10.33.248.250]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3OHlqNx003082; Tue, 24 Apr 2012 17:47:52 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Joe Salowey In-Reply-To: <1335199956.12137.YahooMailNeo@web161604.mail.bf1.yahoo.com> Date: Tue, 24 Apr 2012 10:47:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <94CFA5A8-1D03-4BA2-993E-073B523538D7@cisco.com> References: <36214B77-821E-47B9-8349-A89D2800E24C@cisco.com> <1335199956.12137.YahooMailNeo@web161604.mail.bf1.yahoo.com> To: Fred Templin X-Mailer: Apple Mail (2.1084) Cc: "draft-templin-aero.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-templin-aero-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: Tue, 24 Apr 2012 17:47:56 -0000 Thanks for the quick response, comments inline: On Apr 23, 2012, at 9:52 AM, Fred Templin wrote: > (Resending with comments as inline text) >=20 > Hello Joe, >=20 > Thank you for these comments. Please see below for my proposed > resolutions: >=20 > Fred > fltemplin@acm.org >=20 > From: Joe Salowey > To: secdir@ietf.org; The IESG ; = draft-templin-aero.all@tools.ietf.org=20 > Sent: Sunday, April 22, 2012 3:00 PM > Subject: secdir review of draft-templin-aero-10 >=20 > 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. >=20 > I apologize for the delay in getting this review out. Hopefully it is = still useful. =20 >=20 > This first set of comments is primarily for the authors. >=20 > 1. In section 4.4.4 on Data origin authentication the last paragraph = states that only the 3rd of the above conditions is acceptable, do you = really mean the 4th? >=20 > >>> Begin FLT response > You are correct; this should say the 4th and can be fixed in the next = version. > >>> End FLT response >=20 [Joe] OK > 2. In section 4.4.4 there is reference to the packet including a = digital signature to authenticate the origin. What is the signature = mechanism? Is this SEND or something different? I did not see a = reference to it. >=20 > >>> Begin FLT response > The digital signature mechanism is out of scope for this document. The = text > could be adjusted to say: =93=85, AERO nodes may be obliged to require = the > use of digital signatures applied through means outside the scope of = this > document.=94 > >>> End FLT response >=20 [Joe] I was hoping that something would be specified for = interoperability, I think there are many cases where you would have to = resort to a signing mechanism, however it may be the case that AERO may = be deployed where spoofing of messages is not a concern (perhaps this = should be the recommendation until a signing mechanism is specified). = The ADs can decide if this is an issue or not.=20 > 3. The security considerations do not say much about the consequences = of trusting an inappropriate intermediate router, ingress node or egress = node. Clearly DOS to the ingress node is a possibility. Data = modification and disclosure can be a goal of an attacker who tries to = control the routing. Are there other issues the reader should be aware = of (perhaps other DOS attacks such as amplification attacks). Anything = outside the considerations of RFC4861)? >=20 > >>> Begin FLT response > Proposed resolution is to re-write the first paragraph of Section 6 as = follows: > =20 > =93AERO link security considerations are the same as for standard IPv6 = Neighbor Discovery > (RFC4861) except that AERO improves on some aspects. In particular, = AERO is dependent > on a trust basis between AERO edge nodes and intermediate routers, = where the edge nodes > must only engage in the AERO mechanism when it is facilitated by a = trusted intermediate > router.=94 > >>> End FLT response >=20 [Joe] OK thanks. > 4. The security consideration section indicates that spoofing = protection can be provided by links that provide link layer security = mechanisms. Link Layer security mechanisms may or may not help. I = believe more information is needed here. L2 mechanisms may not provide = adequate protection of upper layer address bindings. In some cases L2 = mechanisms do not provide source origin authentication such as multicast = traffic protected with the group key in WiFi and group security = associations in 802.1AE (MACSEC). >=20 > >>> Begin FLT response > Proposed resolution is to re-write the second paragraph of Section 6 = as follows: > =93AERO links must be protected against spoofing attacks in which an = attacker > on the link pretends to be a trusted neighbor. Links that provide = link-layer > securing mechanisms (e.g., WiFi networks) and links that provide = physical > security (e.g., enterprise network LANs) provide only a fist-line of = defense. > In some instances, therefore, additional securing assurances against = on-link > spoofing attacks are required. For example, if the source can through = some > means digitally sign its messages the destination can verify the = signatures to > ensure data origin authentication. Exact mechanisms for digitally = signing and > verifying signatures are outside the scope of this document.=94 > >>> End FLT response >=20 [Joe] Thanks. (same comment on the specification of the signing = mechanism as above).=20 > This set of comments is mostly for the area directors: >=20 > 1. I am mostly concerned about the lack of definition for the digital = signature mechanism. Perhaps this is easily rectified by a reference to = an existing specification. Its not clear to me what the specification = would be (perhaps SEND??)? Is something needed in addition?=20 > 2. The risks of not securing the proposal are not defined in the = security considerations section. I think this would be helpful, but may = not be strictly necessary. There is some mention of Link-Layer security = helping in some aspects of this, but its not clear on what = characteristics the lower layer security needs to provide.=20 >=20 > Cheers, >=20 > Joe >=20 From fltemplin@yahoo.com Tue Apr 24 11:14: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 35C1E21F87C1 for ; Tue, 24 Apr 2012 11:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, HTML_MESSAGE=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 QzQ6tQuxGBQX for ; Tue, 24 Apr 2012 11:14:38 -0700 (PDT) Received: from nm30.bullet.mail.bf1.yahoo.com (nm30.bullet.mail.bf1.yahoo.com [98.139.212.189]) by ietfa.amsl.com (Postfix) with SMTP id C533D21F87AB for ; Tue, 24 Apr 2012 11:14:37 -0700 (PDT) Received: from [98.139.212.152] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 24 Apr 2012 18:14:37 -0000 Received: from [98.139.215.250] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 24 Apr 2012 18:14:37 -0000 Received: from [127.0.0.1] by omp1063.mail.bf1.yahoo.com with NNFMP; 24 Apr 2012 18:14:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 125389.52475.bm@omp1063.mail.bf1.yahoo.com Received: (qmail 48257 invoked by uid 60001); 24 Apr 2012 18:14:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1335291276; bh=haN4SOq4VUp+W0RM3R9z7dkOK4bvl5nliwqV7SxJtn0=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bHVM0AJ3AxtsvPAEnXRZB8q20Om+bnv3iwur8tzX9U/0iTmBrJFssaM19A7kgOpgEWwLf4bTS/uEttjWoHedZpOBzHl04wl8bpDnD7naZHGTOcV+wG7BXI+HjhVpan0msglAg4gNYOGsahNyJuSH1PUBc4r1v+/hRvNI5uSE3d0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AAjv9izJNy/YVquka59iee48xAdE4oHEuZ2tRYXpjVxTqInAL7g0KKT0LveSDXl0XDWuw2If5Z7bTuIbeMqkkNJcmbknX4FgnJbjRMalSoVXD8/Idp1AezcJJoPayL4/F8UjxTE4/EyxTw1hVzCnepj/blFOQZ2h3ux1GHCF904=; X-YMail-OSG: CPIhuK4VM1nwp0AarbAYjacPeNc1pJ734rd1l6AAHVXRaSc QIugsl6SkEBcss9Nt3nHGgsgNJk_dPUbakD73fD.CNM9ohEm397YruJEladc f2ybup3W8o8LdRCGxnxgZy1FAVre5IRHo7GXBo5nG2jMSEUL5Ra2t40WZa.O sC_RWzkG9Ab8_4GxA_N1lbHYmqn6iq3S3923Fy01ZCJxemBKiYDrzwEFTLex m2T7oYz7uiZD1ggDKArxLvIBCPZVjDDgKEDi7n0OWxGmvB0WqdwMTZNeMCVu DVDUZtveGyvzpuLvBnWT38wcG8Us44ct7S1TiMuis9gIh7SRJcmcBgtlwHXF .T99q0lDq65elGgKQO1SDKEdy5edH2SyNaYPRT1HR5pKx0eFtjd28dPj0uV5 QGjhgs58S3ji6lU64BFCZmHfW2vsqnsHX2fNFgIiGW29VR_IS1io0hgpR79K 61nqrgMJzLlJtAeOjO4s5kjyeoGGGaUBgKlmPSgb2t1ZTVcE- Received: from [130.76.32.212] by web161603.mail.bf1.yahoo.com via HTTP; Tue, 24 Apr 2012 11:14:36 PDT X-Mailer: YahooMailWebService/0.8.117.340979 References: <36214B77-821E-47B9-8349-A89D2800E24C@cisco.com> <1335199956.12137.YahooMailNeo@web161604.mail.bf1.yahoo.com> <94CFA5A8-1D03-4BA2-993E-073B523538D7@cisco.com> Message-ID: <1335291276.47915.YahooMailNeo@web161603.mail.bf1.yahoo.com> Date: Tue, 24 Apr 2012 11:14:36 -0700 (PDT) From: Fred Templin To: Joe Salowey In-Reply-To: <94CFA5A8-1D03-4BA2-993E-073B523538D7@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2012143828-1748022034-1335291276=:47915" X-Mailman-Approved-At: Tue, 24 Apr 2012 13:57:40 -0700 Cc: "draft-templin-aero.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-templin-aero-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Fred Templin List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 18:14:39 -0000 ---2012143828-1748022034-1335291276=:47915 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Joe,=0A=0AThank you for your comments. To your question on specifying= a digital=0Asigning mechanism, would the concern be addressed if I were to= say=0Asomething like: "e.g., using IPsec AH, etc." ?=0A=0AFred=0Afltemplin= @acm.org=0A=0A=0A----- Original Message -----=0A> From: Joe Salowey =0A> To: Fred Templin =0A> Cc: "secdir@ie= tf.org" ; The IESG ; "draft-templin-aero.al= l@tools.ietf.org" =0A> Sent: Tuesday= , April 24, 2012 10:47 AM=0A> Subject: Re: secdir review of draft-templin-a= ero-10=0A> =0A>T hanks for the quick response, comments inline:=0A> On Apr = 23, 2012, at 9:52 AM, Fred Templin wrote:=0A> =0A>> (Resending with commen= ts as inline text)=0A>> =0A>> Hello Joe,=0A>> =0A>> Thank you for these c= omments. Please see below for my proposed=0A>> resolutions:=0A>> =0A>> Fr= ed=0A>> fltemplin@acm.org=0A>> =0A>> From: Joe Salowey =0A>> To: secdir@ietf.org; The IESG ; =0A> draft-templin-= aero.all@tools.ietf.org =0A>> Sent: Sunday, April 22, 2012 3:00 PM=0A>> S= ubject: secdir review of draft-templin-aero-10=0A>> =0A>> I have reviewed = this document as part of the security directorate's =0A>> ongoing effort t= o review all IETF documents being processed by the =0A>> IESG.=C2=A0 These= comments were written primarily for the benefit of the =0A>> security are= a directors.=C2=A0 Document editors and WG chairs should treat =0A>> these= comments just like any other last call comments.=0A>> =0A>> I apologize f= or the delay in getting this review out.=C2=A0 Hopefully it is =0A> still u= seful.=C2=A0 =0A>> =0A>> This first set of comments is primarily for the a= uthors.=0A>> =0A>> 1. In section 4.4.4 on Data origin authentication the l= ast paragraph states =0A> that only the 3rd of the above conditions is acce= ptable, do you really mean the =0A> 4th?=0A>> =0A>> >>> Begin FLT response= =0A>> You are correct; this should say the 4th and can be fixed in the nex= t =0A> version.=0A>> >>> End FLT response=0A>> =0A> =0A> [Joe] OK=0A> =0A>= > 2. In section 4.4.4 there is reference to the packet including a digital= =0A> signature to authenticate the origin.=C2=A0 What is the signature mec= hanism?=C2=A0 Is this =0A> SEND or something different? I did not see a ref= erence to it.=0A>> =0A>> >>> Begin FLT response=0A>> The digital signatur= e mechanism is out of scope for this document. The text=0A>> could be adju= sted to say: =E2=80=9C=E2=80=A6, AERO nodes may be obliged to require the= =0A>> use of digital signatures applied through means outside the scope of= this=0A>> document.=E2=80=9D=0A>> >>> End FLT response=0A>> =0A> =0A> [J= oe] I was hoping that something would be specified for interoperability,=C2= =A0 I =0A> think there are many cases where you would have to resort to a s= igning =0A> mechanism, however it may be the case that AERO may be deployed= where spoofing =0A> of messages is not a concern (perhaps this should be t= he recommendation until a =0A> signing mechanism is specified).=C2=A0 The A= Ds can decide if this is an issue or not.=0A>=0A>> 3. The security conside= rations do not say much about the consequences of =0A> trusting an inapprop= riate intermediate router, ingress node or egress node. =0A> Clearly DOS to= the ingress node is a possibility.=C2=A0 Data modification and =0A> disclo= sure can be a goal of an attacker who tries to control the routing.=C2=A0 A= re =0A> there other issues the reader should be aware of (perhaps other DOS= attacks such =0A> as amplification attacks).=C2=A0 Anything outside the co= nsiderations of RFC4861)?=0A>> =0A>> >>> Begin FLT response=0A>> Proposed= resolution is to re-write the first paragraph of Section 6 as =0A> follows= :=0A>> =C2=A0 =0A>> =E2=80=9CAERO link security considerations are the sam= e as for standard IPv6 =0A> Neighbor Discovery=0A>> (RFC4861) except that = AERO improves on some aspects. In particular, AERO is =0A> dependent=0A>> = on a trust basis between AERO edge nodes and intermediate routers, where = =0A> the edge nodes=0A>> must only engage in the AERO mechanism when it is= facilitated by a trusted =0A> intermediate=0A>> router.=E2=80=9D=0A>> >>= > End FLT response=0A>> =0A> =0A> [Joe] OK thanks.=0A> =0A>> 4. The securi= ty consideration section indicates that spoofing protection =0A> can be pro= vided by links that provide link layer security mechanisms.=C2=A0 =C2=A0 Li= nk =0A> Layer security mechanisms may or may not help.=C2=A0 I believe more= information is =0A> needed here.=C2=A0 L2 mechanisms may not provide adequ= ate protection of upper layer =0A> address bindings.=C2=A0 In some cases L2= mechanisms do not provide source origin =0A> authentication such as multic= ast=C2=A0 traffic protected with the group=C2=A0 key in WiFi =0A> and group= security associations in 802.1AE (MACSEC).=0A>> =0A>> >>> Begin FLT respo= nse=0A>> Proposed resolution is to re-write the second paragraph of Sectio= n 6 as =0A> follows:=0A>> =E2=80=9CAERO links must be protected against sp= oofing attacks in which an attacker=0A>> on the link pretends to be a trus= ted neighbor.=C2=A0 Links that provide =0A> link-layer=0A>> securing mecha= nisms (e.g., WiFi networks) and links that provide physical=0A>> security = (e.g., enterprise network LANs) provide only a fist-line of =0A> defense.= =0A>> In some instances, therefore, additional securing assurances against= =0A> on-link=0A>> spoofing attacks are required. For example, if the sour= ce can through some=0A>> means digitally sign its messages the destination= can verify the signatures =0A> to=0A>> ensure data origin authentication.= Exact mechanisms for digitally signing =0A> and=0A>> verifying signatures= are outside the scope of this document.=E2=80=9D=0A>> >>> End FLT respons= e=0A>> =0A> [Joe] Thanks. (same comment on the specification of the signing= mechanism as =0A> above). =0A> =0A>> This set of comments is mostly for t= he area directors:=0A>> =0A>> 1. I am mostly concerned about the lack of d= efinition for the digital =0A> signature mechanism.=C2=A0 Perhaps this is e= asily rectified by a reference to an =0A> existing specification. Its not c= lear to me what the specification would be =0A> (perhaps SEND??)?=C2=A0 Is = something needed in addition? =0A>> 2.=C2=A0 The risks of not securing the= proposal are not defined in the security =0A> considerations section. I th= ink this would be helpful, but may not be strictly =0A> necessary.=C2=A0 Th= ere is some mention of Link-Layer security helping in some aspects =0A> of = this, but its not clear on what characteristics the lower layer security = =0A> needs to provide. =0A>> =0A>> Cheers,=0A>> =0A>> Joe=0A>> =0A> ---2012143828-1748022034-1335291276=:47915 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello Joe,
Thank you for your comments. To your question on specifying a digital
signing mechanism, would the concern be addressed if I were to say
something like: "e.g., using IPsec AH, etc." ?

Fred
fltemplin@acm.org

----- Original Message -----
> From: Joe Salowey &= lt;jsalowey@cisco.com>
> To: Fred Templin <fltemplin@yahoo.com= >
> Cc: "secdir@ietf.org" <secdir@ietf.org>; The IESG <i= esg@ietf.org>; "draft-templin-aero.all@tools.ietf.org" <draft-templin= -aero.all@tools.ietf.org>
> Sent: Tuesday, April 24, 2012 10:47 A= M
> Subject: Re: secdir review of draft-templin-aero-10
>
>T hanks for the quick response, comments inline:
> On Apr 23= , 2012, at 9:52 AM, Fred Templin wrote:
>
>> (Resending wi= th comments as inline text)
>>
>> Hello Joe,
>&g= t;
>> Thank you for these comments. Please see below for my pro= posed
>> resolutions:
>>
>> Fred
>>= fltemplin@acm.org
>>
>> From: Joe Salowey <jsalow= ey@cisco.com>
>> To: secdir@ietf.org; The IESG <iesg@ietf.o= rg>;
> draft-templin-aero.all@tools.ietf.org
>> Sent: = Sunday, April 22, 2012 3:00 PM
>> Subject: secdir review of draft= -templin-aero-10
>>
>> I have reviewed this document a= s 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
>>=20 security area directors.  Document editors and WG chairs should treat=
>> these comments just like any other last call comments.
&g= t;>
>> I apologize for the delay in getting this review out.=   Hopefully it is
> still useful. 
>>
>&= gt; This first set of comments is primarily for the authors.
>> =
>> 1. In section 4.4.4 on Data origin authentication the last pa= ragraph states
> that only the 3rd of the above conditions is accept= able, do you really mean the
> 4th?
>>
>> >&= gt;> Begin FLT response
>> You are correct; this should say th= e 4th and can be fixed in the next
> version.
>> >>&= gt; End FLT response
>>
>
> [Joe] OK
>
&g= t;> 2. In section 4.4.4 there is reference to the packet including a di= gital
> signature to authenticate the origin.  What is the signature mechanism?  Is this
> SEND or something differen= t? I did not see a reference to it.
>>
>> >>>= Begin FLT response
>> The digital signature mechanism is out of = scope for this document. The text
>> could be adjusted to say: = =E2=80=9C=E2=80=A6, AERO nodes may be obliged to require the
>> u= se of digital signatures applied through means outside the scope of this>> document.=E2=80=9D
>> >>> End FLT response>>
>
> [Joe] I was hoping that something would be spe= cified for interoperability,  I
> think there are many cases wh= ere you would have to resort to a signing
> mechanism, however it ma= y be the case that AERO may be deployed where spoofing
> of messages= is not a concern (perhaps this should be the recommendation until a
&g= t; signing mechanism is specified).  The ADs can decide if this is an = issue or not.
>
>> 3. The security considerations do not say much a= bout the consequences of
> trusting an inappropriate intermediate ro= uter, ingress node or egress node.
> Clearly DOS to the ingress node= is a possibility.  Data modification and
> disclosure can be a= goal of an attacker who tries to control the routing.  Are
> t= here other issues the reader should be aware of (perhaps other DOS attacks = such
> as amplification attacks).  Anything outside the conside= rations of RFC4861)?
>>
>> >>> Begin FLT resp= onse
>> Proposed resolution is to re-write the first paragraph of= Section 6 as
> follows:
>>  
>> =E2=80=9CA= ERO link security considerations are the same as for standard IPv6
>= Neighbor Discovery
>> (RFC4861) except that AERO improves on som= e aspects. In particular, AERO is
> dependent
>> on a trust basis between AERO edge nodes and intermediate routers, where
&g= t; the edge nodes
>> must only engage in the AERO mechanism when = it is facilitated by a trusted
> intermediate
>> router.= =E2=80=9D
>> >>> End FLT response
>>
> =
> [Joe] OK thanks.
>
>> 4. The security considerati= on section indicates that spoofing protection
> can be provided by l= inks that provide link layer security mechanisms.    Link
>= ; Layer security mechanisms may or may not help.  I believe more infor= mation is
> needed here.  L2 mechanisms may not provide adequat= e protection of upper layer
> address bindings.  In some cases = L2 mechanisms do not provide source origin
> authentication such as = multicast  traffic protected with the group  key in WiFi
>= and group security associations in 802.1AE (MACSEC).
>>=20
>> >>> Begin FLT response
>> Proposed resolu= tion is to re-write the second paragraph of Section 6 as
> follows:<= br>>> =E2=80=9CAERO links must be protected against spoofing attacks= in which an attacker
>> on the link pretends to be a trusted nei= ghbor.  Links that provide
> link-layer
>> securing m= echanisms (e.g., WiFi networks) and links that provide physical
>>= security (e.g., enterprise network LANs) provide only a fist-line of
= > defense.
>> In some instances, therefore, additional securin= g assurances against
> on-link
>> spoofing attacks are req= uired. For example, if the source can through some
>> means digit= ally sign its messages the destination can verify the signatures
> t= o
>> ensure data origin authentication. Exact mechanisms for digi= tally signing
> and
>> verifying signatures are outside the scope of this document.=E2=80=9D
>> >>> End FLT res= ponse
>>
> [Joe] Thanks. (same comment on the specificatio= n of the signing mechanism as
> above).
>
>> This = set of comments is mostly for the area directors:
>>
>>= 1. I am mostly concerned about the lack of definition for the digital > signature mechanism.  Perhaps this is easily rectified by a refe= rence to an
> existing specification. Its not clear to me what the s= pecification would be
> (perhaps SEND??)?  Is something needed = in addition?
>> 2.  The risks of not securing the proposal = are not defined in the security
> considerations section. I think th= is would be helpful, but may not be strictly
> necessary.  Ther= e is some mention of Link-Layer security helping in some aspects
> o= f this, but its not clear on what characteristics the lower layer security
> needs to provide.
>>
>> Cheers,
>>=
>> Joe
>>
>
---2012143828-1748022034-1335291276=:47915-- From shanna@juniper.net Tue Apr 24 14:07: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 83AB511E8081; Tue, 24 Apr 2012 14:07:04 -0700 (PDT) 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=[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 zUErO+thB3en; Tue, 24 Apr 2012 14:07:03 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6F60021F85DD; Tue, 24 Apr 2012 14:06:53 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKT5cV7ADTri6r063PkJRpNiQjldgenBxC@postini.com; Tue, 24 Apr 2012 14:07:02 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 24 Apr 2012 14:05:37 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 24 Apr 2012 17:05:37 -0400 From: Stephen Hanna To: Joe Salowey Date: Tue, 24 Apr 2012 17:05:35 -0400 Thread-Topic: [secdir] secdir review of draft-ietf-emu-chbind-14 Thread-Index: Ac0hlP8wicscpjIeTuio0dAKOVPhTQAgv08A Message-ID: References: In-Reply-To: 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 Cc: Sam Hartman , "draft-ietf-emu-chbind@tools.ietf.org" , IETF-Discussion list , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-emu-chbind-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: Tue, 24 Apr 2012 21:07:04 -0000 Joe, I'm glad that my comments were useful to you and to the editors of this draft. I will respond to your comments below inline. I'm going to clip out as much as I can, including anything that has already been agreed on. Thanks, Steve ---------- Joe Salowey wrote: > > On Apr 13, 2012, at 11:26 AM, Stephen Hanna wrote: > > > In the Introduction, the second paragraph says that the > > problem "results when the same credentials are used to > > access multiple services that differ in some interesting > > property". Do you mean client or server credentials? > > I think you mean EAP server credentials. Please be more > > explicit to make this clearer, since many people will > > assume that you mean client (EAP peer) credentials. If > > I'm correct and you do mean EAP server credentials, > > I suggest that you say so in the first sentence of > > this paragraph and also in the last sentence. > > [Joe] The case here is both client and server credentials. If > different credentials are required for each type of service then the > authenticator will not be able to lie about the type of service it is > representing to the client because the client credentials are bound to > the service. SH> I don't see what the problem is with using the same client credentials with two different services if the server credentials are different. The client will be able to detect a lying NAS easily since the server credentials won't match what it expects for that service. Could you please explain this more? > > In the first paragraph of the Problem Statement, the second > > sentence says "However, when operating in pass-through mode, > > the EAP server can be far removed from the authenticator." > > While this is true, I think the more relevant statement here > > is that the EAP server can be far removed from the EAP peer. > > This paragraph is all about problems that can arise when > > parties between the EAP peer and the EAP server (including > > the authenticator) are malicious or compromised. So the > > important thing to point out at the start of the paragraph > > is the large number of parties that may come between the > > EAP server and the EAP peer. > > > > [Joe] I think I see your point, but I'm not sure. Traditionally, we > have often thought of the path between EAP peer and EAP authenticator > as being vulnerable to having multiple parties able to insert > themselves into the conversation. However it may be the case that the > authenticator the peer is talking to isn't the one it thinks it is and > the "real" authenticator may be somewhere in the path as well. The > conversation between the EAP peer and EAP server will not be > compromised, however the result of the conversation may not have its > intended effect. My point is that having a long distance between the EAP server and the authenticator has little to do with the "lying NAS" problem. The problem is that there are potentially untrustworthy parties (the NAS and any proxies) between the EAP peer and the EAP server and the EAP peer is trusting what it's told by them. If the EAP server and the authenticator were two inches apart with no intermediaries, that wouldn't help. The problem is the potentially untrustworthy folks between the EAP server and the EAP peer. You're trying to verify some of what they're telling the EAP peer. So I'm not sure that sentence helps but if it does, the problem is between the EAP peer and the EAP server. > > Overall, I found the document too abstract for my taste. When > > I read an RFC that's defining a protocol to be implemented, > > I prefer to read a description of the problem to be solved > > and then a clear definition of the protocol. This document > > reads like a combination of an academic paper and a protocol > > definition. For example, section 4.1 describes two categories > > of approach to EAP channel bindings: exchanging the actual > > network information or encoding the network information into > > a blob that is used to derive EAP session keys. The rest of > > section 4.1 goes on to discuss the pros and cons of these > > approaches. Then section 4.2 defines a bunch of requirements > > for transporting channel bindings in a lower layer's secure > > association protocol. While that's interesting, the actual > > protocol defined in this document sends the actual network > > information in EAP. Why bother spending several pages talking > > about things that this protocol doesn't actually do? > > [Joe] THis is historical and reflects the discussion we had in the > working as the document was being developed. > > > I see > > several downsides to including that text in this document. > > First, you're making it harder for the reader to understand > > what they actually need to do to implement this protocol. > > You've probably decreased by half the number of people who > > will actually read all of this document. Second, some people > > will use that digression to support arguments like ("My > > incompatible implementation is compliant with RFC XXXX > > because I encoded the network information into a blob > > and used that to generate EAP session keys"). IETF is an > > engineering organization. We should make our specs as clear > > and simple as possible and no simpler. This document includes > > lots of interesting theory that's not needed for its purpose. > > If you're interested in seeing this document widely implemented, > > I suggest that you remove as much of that as possible and focus > > the document on explaining the problem and defining a protocol > > that solves it. Or you can leave it as is. I'm sure some people > > will implement it. Just not as many. Friendly suggestion. Take > > it or leave it. > > [Joe] I can see your point, but I think some members of the working > group would object if we removed some of this material. If its not > clear perhaps we can so a better job of indicating what is normative > and what is informative. OK. If you think the WG really wants this confusing text, leave it in. But maybe you should start section 4 by saying "This section describes several possible design choices for channel bindings. It is not normative." And then you'll need to change, delete, or move the paragraph in section 4.2 that includes a MUST and a SHOULD. I think that paragraph is redundant with the first paragraph in section 6.1 and not specific to sending channel bindings in the Secure Association Protocol (which is the topic of section 4.2) so I'd suggest that you just delete it. You won't lose anything. > > In section 7.1, you explain that this document isn't useful > > without an accompanying document defining what information > > should be included in i1 for each lower layer. Are those > > documents being prepared for all or at least some of the > > lower layers? I couldn't find any in a quick search. I know > > we can't wait for everything to be ready but it would be > > nice to see at least one or two of those documents so that > > we can have confidence that this protocol can support all > > the things that those documents will need. > > [Joe] That not how I interpret the text in section 7.1. This document > does specify a general attribute that can be used to specify the type > of lower layer used to carry EAP. Section 7.1 states that additional > documents will be needed to specify attributes specific to a particular > lower layer. ABFAB is working on a document that contains this > information for their lower layer, draft-ietf-abfab-gss-eap. Without a document that defines what information should be included in i1 for a given lower layer, the only thing this protocol gives you is a way to confirm that the EAP server is OK with the lower layer advertised by the authenticator. Whoop-dee-do. That doesn't address any of the use cases described in the Problem Statement. In all those cases, the authenticator is advertising a lower layer that's supported by the EAP server. I'm not saying that EAP channel bindings have no value. I'm just saying that they don't have much value without a document that specifies the attributes relevant to the lower layer that's in use. So let's publish this spec and the GSS-EAP spec. But let's also work on a spec that describes the attributes for 802.11. > > As I read section 8, I wonder whether include the User-Name > > attribute in i2 could open the system up to attacks where > > an authenticator or intermediate proxy could remove the > > anonymity of a user who's using a pseudonym for the > > username by changing the value of the User-Name attribute > > to the username of the user suspected of being responsible > > for this authentication. If the channel bindings checks > > fail, the authenticator will know they were wrong but if > > the channel bindings checks succeed, the authenticator > > will have confirmation of the user's identity. > > [Joe] Perhaps, on the one hand I would think the system would not > behave this way, the server would be expecting a pseudonym or token and > fail if it got something else. On the other hand, I don' think the > text for the user-name check or the test itself are that useful. We > could either warn against the possible identity disclosure or remove > the user-name check. I'd be inclined to warn about the problem since there may still be some utility in checking the value. Whichever you prefer. > > I didn't understand that sending i2 from the server to > > the peer is optional until I got to section 9.1. In section > > 5.3, you said that "For success, the server returns the > > attributes that were considered by the server in making > > the determination that channel bindings are successfully > > validated". Which of these is right? > > [Joe] The server is required to return the channel-binding attributes > it verified because the client may require certain attributes to be > checked. This list of verified attributes is not equivalent to i2. > i2 is what attributes are sent in the AAA protocol and I don't think it > should be referenced here. Instead it should probably say: > > "sending the result from server to peer over integrity-protected > channel" OK, fine. > > At the top of page 23, you say that "In many EAP deployments > > today attacks where one NAS can impersonate another are > > out of scope." Do you mean that these attacks are generally > > not considered but they are a potential problem? Or that > > they are not a problem? I think they are always a possible > > problem. Even when all the NASes are owned and managed by > > the same organization that runs the AAA server and no proxies > > are used, there's still the potential for a NAS to become > > compromised. So I think you should say these attacks are > > "not considered although a real concern" not that they are > > "out of scope". > > [Joe] As EAP is deployed in most cases today the authenticator is not > identified, it is merely authorized as being part of the network. The > peer does not expect differentiated service based on the NAS it is > connected to. Since the service is the same it does not matter to the > peer if one authenticator impersonates another. When we start > discussing use case such as ABFAB where different services are being > provided did the identity of the authenticator really become an issue. > > Perhaps the following text is better > > "In many EAP deployments today attacks where one authenticator can > impersonate another not a real concern since different authenticators > provide the same service. In these situations an authenticator does > not gain significant advantage in impersonating another authenticator. > " I'd say "all authenticators provide the same service". I think that's what you meant to say. With that change, my concerns are allayed. > > And then the following sentence says that > > "Channel bindings brings these attacks into scope". Again, > > I think those attacks are always a potential issue. Channel > > bindings provide a good way to address them, whereas there > > were few ways to do so before. Maybe it would be better to > > say that. > > > > [Joe] I see your point here, how about: > > "The use of EAP in situations where different authenticators provide > different services makes the ability to authorize different > authenticators more important. The system as a whole needs to be > analyzed to > evaluate cases where one authenticator may impersonate another and > to evaluate the impact of this impersonation. Channel bindings > provides a way to address these issues. " Yes, good. > > In the next paragraph, you say that when cryptographic binding > > is used in a tunnel method, the MSK is disclosed to the NAS. > > I don't think that's right. The MSK that's disclosed to the > > NAS is the one generated by the outer method. The MSK that's > > used in cryptographic binding is the one that's generated by > > the inner method. I don't think there's a problem there. > > [Joe] OK, this test is referring to where there is separate between > the terminating server of the inner and outer methods. Maybe it would > be clearer if the text said the following: > > "Even when cryptographic binding does attempt to confirm that the inner > and outer server are the same, the Master Session Key (MSK) from the > inner method is typically used to protect the binding. However, if the > outer method tunnel terminates on the authenticator the inner MSK is > disclosed to the authenticator, which can attack cryptographic > binding." Who on earth would terminate the outer method on the authenticator? The authenticator should be trusted as little as possible. The party who terminates the outer tunnel method must be highly trusted. One of the main benefits of having an authentication server is to reduce the number of highly trusted parties by centralizing the most security-critical activities such as authentication. That's why we have pass-through authenticator mode. Maybe you're not talking about using EAP pass-through authenticator mode any more. In that case, there's no backend authentication server so this whole document does not apply. At least, I don't think it does. Could you point out to me where in this document it explains how to handle this situation? If this situation is not in scope for this document, I think you should say that and remove this text about MSK problems since they don't apply to this document. If not using pass-through authenticator mode is in scope for this document, please say that and explain how EAP channel bindings work in that environment. > > Later in that paragraph, you say that an attack where the NAS > > terminates an EAP tunnel method is not in scope for existing > > models for cryptographic binding. I think that's wrong also. > > EAP tunnel methods protect against just this sort of attack. > > The first step in these methods is for the EAP peer and the > > EAP server to build a TLS tunnel. This requires the EAP peer > > to authenticate the EAP server and decide whether it's trusted. > > If the NAS has credentials that will cause the EAP peer to > > trust it as an EAP server, a MITM attack is possible. Of course, > > that's true for any secure communications and it's a very bad > > situation. That's why the EAP peer must be very careful about > > who it trusts and how it authenticates them and the EAP server > > (and any CAs or other TTPs) must also be similarly careful. > > I don't see that any of this has much to do with channel bindings. > > Am I missing something here? If so, please explain it. And maybe > > you can clarify the text so that other folks get it also. > > [Joe] The issue is when you have different services the client may not > have enough information to determine what an authenticator is > authorized for based on its identity alone. In this case it would like > help from the server that terminates the inner method. However current > crypto binding is based on the MSK so the authenticator can generate > whatever channel binding quantities it wants because the authenticator > has all the necessary key material. In order for channel bindings to > determine if the authenticator is authorized or not, the method needs > protect the channel bindings with a key generated from the inner method > EMSK that the authenticator does not possess. Here is some text that > may help: > > "If the authenticator controls the cryptographic binding then it also > controls the channel binding parameters and results. If the channel > binding process is used to differentiate one authenticator from another > then the authenticator can claim to support services that it was not > authorized to. This attack was not in scope for existing threat models > for cryptographic binding because differentiated authenticators was not > a consideration. Thus, existing cryptographic binding does not > typically provide mutual authentication of the inner method server > required for channel binding." Again, you've moved beyond pass-through authentication mode. I don't think this document covers that. If it's meant to cover that, it's missing a lot of text (to describe how that works). > > Appendix A is pretty similar to section 1. Might you > > be able to merge them somehow? > > > > [Joe] I think the authors attempted to do this and then decided it was > better to keep them separate. OK. From jsalowey@cisco.com Tue Apr 24 15:55: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 20B0121F8570; Tue, 24 Apr 2012 15:55:49 -0700 (PDT) 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 WIoiEedU-0u9; Tue, 24 Apr 2012 15:55:47 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2D32D21F85D4; Tue, 24 Apr 2012 15:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=8343; q=dns/txt; s=iport; t=1335308147; x=1336517747; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=PxNf6icZ/D54Q3h1LrywGr5NHE0fQXF1JWel9+YLewE=; b=AT59U5oDkmhXZDcQE462BPLQdcBAkKZlrBDFYRzvzgabci0mf+omoWWS idMYKU4dbfLwMY4/TUVudeU/9Vv0FYxTwgTkJSfzsDxDZltRQVlKdkiZ2 5QFlEJHdq7/H6v85A90qBtGVTkqdJqyOvsAHFX652NARTwusETZaWWVDs Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIHAOgul0+rRDoI/2dsb2JhbAA6CoMdnGiRdYEHggkBAQEDARIBZgUHBAsOAwQBAQEuRQoIBhMih18DBgSaKKAniXl2hSBjBIhjjReFdIVJgxiBaYMJ X-IronPort-AV: E=Sophos;i="4.75,476,1330905600"; d="scan'208";a="42020782" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 24 Apr 2012 22:55:43 +0000 Received: from [10.33.248.250] ([10.33.248.250]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3OMtg3b018129; Tue, 24 Apr 2012 22:55:42 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Joe Salowey In-Reply-To: <1335291276.47915.YahooMailNeo@web161603.mail.bf1.yahoo.com> Date: Tue, 24 Apr 2012 15:55:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <36214B77-821E-47B9-8349-A89D2800E24C@cisco.com> <1335199956.12137.YahooMailNeo@web161604.mail.bf1.yahoo.com> <94CFA5A8-1D03-4BA2-993E-073B523538D7@cisco.com> <1335291276.47915.YahooMailNeo@web161603.mail.bf1.yahoo.com> To: Fred Templin X-Mailer: Apple Mail (2.1084) Cc: "draft-templin-aero.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-templin-aero-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: Tue, 24 Apr 2012 22:55:49 -0000 On Apr 24, 2012, at 11:14 AM, Fred Templin wrote: > Hello Joe, >=20 > Thank you for your comments. To your question on specifying a digital > signing mechanism, would the concern be addressed if I were to say > something like: "e.g., using IPsec AH, etc." ? >=20 [Joe] Not really. What I'm looking for is something that specifies the = mechanism and how its used. Something like=20 "Implementations MUST support as a means to authenticate the = origin of the AERO messages. AERO peers MUST support establishing an = using with as specified in . During establishment AERO hosts MUST be able identify = AERO intermediate routers through mechanism defined in . " The stuff in the <> should be replaced with something that makes sense. = I'm not sure that IPSEC AH or any of the other things in <> are really = appropriate in this case. The idea here is that there is some minimum = mechanism that implementations can use to secure these messages. = Securing the messages involves the transform for authenticating the = messages (perhaps IPSEC AH), mechanism for key management perhaps (IKV2 = with certificates) and a way to establish that you are taking to the = right router (perhaps be able to match a field in a certificate to a = particular name or domain). My hope is that there already is something = that would fit the bill and we could just reference that specification. = Some of the SEND variants may be useful in this scenario, but I didn't = get a chance to dig into this. =20 Joe > Fred > fltemplin@acm.org >=20 > ----- Original Message ----- > > From: Joe Salowey > > To: Fred Templin > > Cc: "secdir@ietf.org" ; The IESG ; = "draft-templin-aero.all@tools.ietf.org" = > > Sent: Tuesday, April 24, 2012 10:47 AM > > Subject: Re: secdir review of draft-templin-aero-10 > >=20 > >T hanks for the quick response, comments inline: > > On Apr 23, 2012, at 9:52 AM, Fred Templin wrote: > >=20 > >> (Resending with comments as inline text) > >>=20 > >> Hello Joe, > >>=20 > >> Thank you for these comments. Please see below for my proposed > >> resolutions: > >>=20 > >> Fred > >> fltemplin@acm.org > >>=20 > >> From: Joe Salowey > >> To: secdir@ietf.org; The IESG ;=20 > > draft-templin-aero.all@tools.ietf.org=20 > >> Sent: Sunday, April 22, 2012 3:00 PM > >> Subject: secdir review of draft-templin-aero-10 > >>=20 > >> 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. > >>=20 > >> I apologize for the delay in getting this review out. Hopefully it = is=20 > > still useful. =20 > >>=20 > >> This first set of comments is primarily for the authors. > >>=20 > >> 1. In section 4.4.4 on Data origin authentication the last = paragraph states=20 > > that only the 3rd of the above conditions is acceptable, do you = really mean the=20 > > 4th? > >>=20 > >> >>> Begin FLT response > >> You are correct; this should say the 4th and can be fixed in the = next=20 > > version. > >> >>> End FLT response > >>=20 > >=20 > > [Joe] OK > >=20 > >> 2. In section 4.4.4 there is reference to the packet including a = digital=20 > > signature to authenticate the origin. What is the signature = mechanism? Is this=20 > > SEND or something different? I did not see a reference to it. > >>=20 > >> >>> Begin FLT response > >> The digital signature mechanism is out of scope for this document. = The text > >> could be adjusted to say: =93=85, AERO nodes may be obliged to = require the > >> use of digital signatures applied through means outside the scope = of this > >> document.=94 > >> >>> End FLT response > >>=20 > >=20 > > [Joe] I was hoping that something would be specified for = interoperability, I=20 > > think there are many cases where you would have to resort to a = signing=20 > > mechanism, however it may be the case that AERO may be deployed = where spoofing=20 > > of messages is not a concern (perhaps this should be the = recommendation until a=20 > > signing mechanism is specified). The ADs can decide if this is an = issue or not. > > > >> 3. The security considerations do not say much about the = consequences of=20 > > trusting an inappropriate intermediate router, ingress node or = egress node.=20 > > Clearly DOS to the ingress node is a possibility. Data modification = and=20 > > disclosure can be a goal of an attacker who tries to control the = routing. Are=20 > > there other issues the reader should be aware of (perhaps other DOS = attacks such=20 > > as amplification attacks). Anything outside the considerations of = RFC4861)? > >>=20 > >> >>> Begin FLT response > >> Proposed resolution is to re-write the first paragraph of Section 6 = as=20 > > follows: > >> =20 > >> =93AERO link security considerations are the same as for standard = IPv6=20 > > Neighbor Discovery > >> (RFC4861) except that AERO improves on some aspects. In particular, = AERO is=20 > > dependent > >> on a trust basis between AERO edge nodes and intermediate routers, = where=20 > > the edge nodes > >> must only engage in the AERO mechanism when it is facilitated by a = trusted=20 > > intermediate > >> router.=94 > >> >>> End FLT response > >>=20 > >=20 > > [Joe] OK thanks. > >=20 > >> 4. The security consideration section indicates that spoofing = protection=20 > > can be provided by links that provide link layer security = mechanisms. Link=20 > > Layer security mechanisms may or may not help. I believe more = information is=20 > > needed here. L2 mechanisms may not provide adequate protection of = upper layer=20 > > address bindings. In some cases L2 mechanisms do not provide source = origin=20 > > authentication such as multicast traffic protected with the group = key in WiFi=20 > > and group security associations in 802.1AE (MACSEC). > >>=20 > >> >>> Begin FLT response > >> Proposed resolution is to re-write the second paragraph of Section = 6 as=20 > > follows: > >> =93AERO links must be protected against spoofing attacks in which = an attacker > >> on the link pretends to be a trusted neighbor. Links that provide=20= > > link-layer > >> securing mechanisms (e.g., WiFi networks) and links that provide = physical > >> security (e.g., enterprise network LANs) provide only a fist-line = of=20 > > defense. > >> In some instances, therefore, additional securing assurances = against=20 > > on-link > >> spoofing attacks are required. For example, if the source can = through some > >> means digitally sign its messages the destination can verify the = signatures=20 > > to > >> ensure data origin authentication. Exact mechanisms for digitally = signing=20 > > and > >> verifying signatures are outside the scope of this document.=94 > >> >>> End FLT response > >>=20 > > [Joe] Thanks. (same comment on the specification of the signing = mechanism as=20 > > above).=20 > >=20 > >> This set of comments is mostly for the area directors: > >>=20 > >> 1. I am mostly concerned about the lack of definition for the = digital=20 > > signature mechanism. Perhaps this is easily rectified by a = reference to an=20 > > existing specification. Its not clear to me what the specification = would be=20 > > (perhaps SEND??)? Is something needed in addition?=20 > >> 2. The risks of not securing the proposal are not defined in the = security=20 > > considerations section. I think this would be helpful, but may not = be strictly=20 > > necessary. There is some mention of Link-Layer security helping in = some aspects=20 > > of this, but its not clear on what characteristics the lower layer = security=20 > > needs to provide.=20 > >>=20 > >> Cheers, > >>=20 > >> Joe > >>=20 > > From jsalowey@cisco.com Tue Apr 24 22:34: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 99D0221F8671; Tue, 24 Apr 2012 22:34:52 -0700 (PDT) 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 ddo18hZ4qGWt; Tue, 24 Apr 2012 22:34:51 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE2221F846A; Tue, 24 Apr 2012 22:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=16259; q=dns/txt; s=iport; t=1335332091; x=1336541691; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=n4MKaqSVVOr+GjkUXQFUu7/SYQ/6KI3Sp23U+iaBrdA=; b=bhwTl6t9P0oQ88W1CN//RhEkVosev/m/CPJBV/YZcy5mmtJSdc/07Zsi UIPpzddiBVQaKkfhMKAifkL5d4vc5NBIX1ErzPjpWT+p4Gc69C6q2Rdub mbO1mURDS/izuFYWF55/yDMb1yJh5jNu4DhcRCMKoOLJPgNrjIFUrFh9b Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscGAN2Ml0+rRDoG/2dsb2JhbAA7CYMdrk+BB4IJAQEBAwESAScyCgMFCwsOChkCE1cGNYdoBJpaoCaKdYJuAoIvYwSIY4JjijSFdGyHdYFpgwmBFx8 X-IronPort-AV: E=Sophos;i="4.75,479,1330905600"; d="scan'208";a="42056151" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 25 Apr 2012 05:34:42 +0000 Received: from [10.33.248.250] ([10.33.248.250]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3P5YfDV024641; Wed, 25 Apr 2012 05:34:41 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: Date: Tue, 24 Apr 2012 22:34:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4BB606A5-B3E0-4132-96EC-3E8BCE0B927B@cisco.com> References: To: Stephen Hanna X-Mailer: Apple Mail (2.1084) Cc: Sam Hartman , "draft-ietf-emu-chbind@tools.ietf.org" , IETF-Discussion list , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-emu-chbind-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, 25 Apr 2012 05:34:52 -0000 On Apr 24, 2012, at 2:05 PM, Stephen Hanna wrote: > Joe, >=20 > I'm glad that my comments were useful to you and to the editors > of this draft. I will respond to your comments below inline. > I'm going to clip out as much as I can, including anything > that has already been agreed on. >=20 > Thanks, >=20 > Steve >=20 > ---------- >=20 > Joe Salowey wrote: >>=20 >> On Apr 13, 2012, at 11:26 AM, Stephen Hanna wrote: >>=20 >>> In the Introduction, the second paragraph says that the >>> problem "results when the same credentials are used to >>> access multiple services that differ in some interesting >>> property". Do you mean client or server credentials? >>> I think you mean EAP server credentials. Please be more >>> explicit to make this clearer, since many people will >>> assume that you mean client (EAP peer) credentials. If >>> I'm correct and you do mean EAP server credentials, >>> I suggest that you say so in the first sentence of >>> this paragraph and also in the last sentence. >>=20 >> [Joe] The case here is both client and server credentials. If >> different credentials are required for each type of service then the >> authenticator will not be able to lie about the type of service it is >> representing to the client because the client credentials are bound = to >> the service. >=20 > SH> I don't see what the problem is with using the same > client credentials with two different services if the > server credentials are different. The client will be able > to detect a lying NAS easily since the server credentials > won't match what it expects for that service. Could you > please explain this more? >=20 [Joe] In many cases the server credentials will be the same. They will = be the credentials of the AAA server. =20 >>> In the first paragraph of the Problem Statement, the second >>> sentence says "However, when operating in pass-through mode, >>> the EAP server can be far removed from the authenticator." >>> While this is true, I think the more relevant statement here >>> is that the EAP server can be far removed from the EAP peer. >>> This paragraph is all about problems that can arise when >>> parties between the EAP peer and the EAP server (including >>> the authenticator) are malicious or compromised. So the >>> important thing to point out at the start of the paragraph >>> is the large number of parties that may come between the >>> EAP server and the EAP peer. >>>=20 >>=20 >> [Joe] I think I see your point, but I'm not sure. Traditionally, we >> have often thought of the path between EAP peer and EAP authenticator >> as being vulnerable to having multiple parties able to insert >> themselves into the conversation. However it may be the case that = the >> authenticator the peer is talking to isn't the one it thinks it is = and >> the "real" authenticator may be somewhere in the path as well. The >> conversation between the EAP peer and EAP server will not be >> compromised, however the result of the conversation may not have its >> intended effect. >=20 > My point is that having a long distance between the EAP server > and the authenticator has little to do with the "lying NAS" > problem. The problem is that there are potentially untrustworthy > parties (the NAS and any proxies) between the EAP peer and the > EAP server and the EAP peer is trusting what it's told by them. > If the EAP server and the authenticator were two inches apart > with no intermediaries, that wouldn't help. The problem is the > potentially untrustworthy folks between the EAP server and > the EAP peer. You're trying to verify some of what they're > telling the EAP peer. So I'm not sure that sentence helps but > if it does, the problem is between the EAP peer and the EAP server. >=20 [Joe] I don't have an issue with stating that the problem is between the = peer and the server, but I'd like to hear the author's view on this.=20 >>=20 >> [Joe] THis is historical and reflects the discussion we had in the >> working as the document was being developed. >>=20 >>> I see >>> several downsides to including that text in this document. >>> First, you're making it harder for the reader to understand >>> what they actually need to do to implement this protocol. >>> You've probably decreased by half the number of people who >>> will actually read all of this document. Second, some people >>> will use that digression to support arguments like ("My >>> incompatible implementation is compliant with RFC XXXX >>> because I encoded the network information into a blob >>> and used that to generate EAP session keys"). IETF is an >>> engineering organization. We should make our specs as clear >>> and simple as possible and no simpler. This document includes >>> lots of interesting theory that's not needed for its purpose. >>> If you're interested in seeing this document widely implemented, >>> I suggest that you remove as much of that as possible and focus >>> the document on explaining the problem and defining a protocol >>> that solves it. Or you can leave it as is. I'm sure some people >>> will implement it. Just not as many. Friendly suggestion. Take >>> it or leave it. >>=20 >> [Joe] I can see your point, but I think some members of the working >> group would object if we removed some of this material. If its not >> clear perhaps we can so a better job of indicating what is normative >> and what is informative. >=20 > OK. If you think the WG really wants this confusing text, > leave it in. But maybe you should start section 4 by saying > "This section describes several possible design choices > for channel bindings. It is not normative." And then you'll > need to change, delete, or move the paragraph in section 4.2 > that includes a MUST and a SHOULD. I think that paragraph is > redundant with the first paragraph in section 6.1 and not > specific to sending channel bindings in the Secure Association > Protocol (which is the topic of section 4.2) so I'd suggest > that you just delete it. You won't lose anything. >=20 [Joe] I'm OK with this.=20 >>> In section 7.1, you explain that this document isn't useful >>> without an accompanying document defining what information >>> should be included in i1 for each lower layer. Are those >>> documents being prepared for all or at least some of the >>> lower layers? I couldn't find any in a quick search. I know >>> we can't wait for everything to be ready but it would be >>> nice to see at least one or two of those documents so that >>> we can have confidence that this protocol can support all >>> the things that those documents will need. >>=20 >> [Joe] That not how I interpret the text in section 7.1. This = document >> does specify a general attribute that can be used to specify the type >> of lower layer used to carry EAP. Section 7.1 states that = additional >> documents will be needed to specify attributes specific to a = particular >> lower layer. ABFAB is working on a document that contains this >> information for their lower layer, draft-ietf-abfab-gss-eap. >=20 > Without a document that defines what information should be > included in i1 for a given lower layer, the only thing this > protocol gives you is a way to confirm that the EAP server > is OK with the lower layer advertised by the authenticator. > Whoop-dee-do. That doesn't address any of the use cases > described in the Problem Statement. In all those cases, > the authenticator is advertising a lower layer that's > supported by the EAP server. >=20 > I'm not saying that EAP channel bindings have no value. > I'm just saying that they don't have much value without > a document that specifies the attributes relevant to > the lower layer that's in use. So let's publish this > spec and the GSS-EAP spec. But let's also work on a > spec that describes the attributes for 802.11. >=20 [Joe] I agree we should work on a spec for 802.11 and perhaps other 802 = networks as well. =20 >>> As I read section 8, I wonder whether include the User-Name >>> attribute in i2 could open the system up to attacks where >>> an authenticator or intermediate proxy could remove the >>> anonymity of a user who's using a pseudonym for the >>> username by changing the value of the User-Name attribute >>> to the username of the user suspected of being responsible >>> for this authentication. If the channel bindings checks >>> fail, the authenticator will know they were wrong but if >>> the channel bindings checks succeed, the authenticator >>> will have confirmation of the user's identity. >>=20 >> [Joe] Perhaps, on the one hand I would think the system would not >> behave this way, the server would be expecting a pseudonym or token = and >> fail if it got something else. On the other hand, I don' think the >> text for the user-name check or the test itself are that useful. We >> could either warn against the possible identity disclosure or remove >> the user-name check. >=20 > I'd be inclined to warn about the problem since there may still > be some utility in checking the value. Whichever you prefer. >=20 [Joe] I think adding the warning is fine. >=20 >>> At the top of page 23, you say that "In many EAP deployments >>> today attacks where one NAS can impersonate another are >>> out of scope." Do you mean that these attacks are generally >>> not considered but they are a potential problem? Or that >>> they are not a problem? I think they are always a possible >>> problem. Even when all the NASes are owned and managed by >>> the same organization that runs the AAA server and no proxies >>> are used, there's still the potential for a NAS to become >>> compromised. So I think you should say these attacks are >>> "not considered although a real concern" not that they are >>> "out of scope". >>=20 >> [Joe] As EAP is deployed in most cases today the authenticator is not >> identified, it is merely authorized as being part of the network. = The >> peer does not expect differentiated service based on the NAS it is >> connected to. Since the service is the same it does not matter to = the >> peer if one authenticator impersonates another. When we start >> discussing use case such as ABFAB where different services are being >> provided did the identity of the authenticator really become an = issue. >>=20 >> Perhaps the following text is better >>=20 >> "In many EAP deployments today attacks where one authenticator can >> impersonate another not a real concern since different authenticators >> provide the same service. In these situations an authenticator does >> not gain significant advantage in impersonating another = authenticator. >> " >=20 > I'd say "all authenticators provide the same service". I think > that's what you meant to say. With that change, my concerns are > allayed. >=20 [Joe] Yes, thanks. >=20 >>> In the next paragraph, you say that when cryptographic binding >>> is used in a tunnel method, the MSK is disclosed to the NAS. >>> I don't think that's right. The MSK that's disclosed to the >>> NAS is the one generated by the outer method. The MSK that's >>> used in cryptographic binding is the one that's generated by >>> the inner method. I don't think there's a problem there. >>=20 >> [Joe] OK, this test is referring to where there is separate between >> the terminating server of the inner and outer methods. Maybe it = would >> be clearer if the text said the following: >>=20 >> "Even when cryptographic binding does attempt to confirm that the = inner >> and outer server are the same, the Master Session Key (MSK) from the >> inner method is typically used to protect the binding. However, if = the >> outer method tunnel terminates on the authenticator the inner MSK is >> disclosed to the authenticator, which can attack cryptographic >> binding." >=20 > Who on earth would terminate the outer method on the authenticator? > The authenticator should be trusted as little as possible. The party > who terminates the outer tunnel method must be highly trusted. > One of the main benefits of having an authentication server is to > reduce the number of highly trusted parties by centralizing the > most security-critical activities such as authentication. That's > why we have pass-through authenticator mode. Maybe you're not > talking about using EAP pass-through authenticator mode any more. > In that case, there's no backend authentication server so this > whole document does not apply. At least, I don't think it does. > Could you point out to me where in this document it explains > how to handle this situation? If this situation is not in scope > for this document, I think you should say that and remove this > text about MSK problems since they don't apply to this document. > If not using pass-through authenticator mode is in scope for > this document, please say that and explain how EAP channel > bindings work in that environment. >=20 [Joe] So, I'm not a big fan of splitting the inner and outer methods, = but there have been quite a few advocates for various use cases. The = current issue was brought up in ABFAB so I think Sam would be better at = providing the motivation for that.=20 >>> Later in that paragraph, you say that an attack where the NAS >>> terminates an EAP tunnel method is not in scope for existing >>> models for cryptographic binding. I think that's wrong also. >>> EAP tunnel methods protect against just this sort of attack. >>> The first step in these methods is for the EAP peer and the >>> EAP server to build a TLS tunnel. This requires the EAP peer >>> to authenticate the EAP server and decide whether it's trusted. >>> If the NAS has credentials that will cause the EAP peer to >>> trust it as an EAP server, a MITM attack is possible. Of course, >>> that's true for any secure communications and it's a very bad >>> situation. That's why the EAP peer must be very careful about >>> who it trusts and how it authenticates them and the EAP server >>> (and any CAs or other TTPs) must also be similarly careful. >>> I don't see that any of this has much to do with channel bindings. >>> Am I missing something here? If so, please explain it. And maybe >>> you can clarify the text so that other folks get it also. >>=20 >> [Joe] The issue is when you have different services the client may = not >> have enough information to determine what an authenticator is >> authorized for based on its identity alone. In this case it would = like >> help from the server that terminates the inner method. However = current >> crypto binding is based on the MSK so the authenticator can generate >> whatever channel binding quantities it wants because the = authenticator >> has all the necessary key material. In order for channel bindings to >> determine if the authenticator is authorized or not, the method = needs >> protect the channel bindings with a key generated from the inner = method >> EMSK that the authenticator does not possess. Here is some text = that >> may help: >>=20 >> "If the authenticator controls the cryptographic binding then it also >> controls the channel binding parameters and results. If the channel >> binding process is used to differentiate one authenticator from = another >> then the authenticator can claim to support services that it was not >> authorized to. This attack was not in scope for existing threat = models >> for cryptographic binding because differentiated authenticators was = not >> a consideration. Thus, existing cryptographic binding does not >> typically provide mutual authentication of the inner method server >> required for channel binding." >=20 > Again, you've moved beyond pass-through authentication mode. I don't > think this document covers that. If it's meant to cover that, it's > missing a lot of text (to describe how that works). >=20 [Joe] True, that is why this was previously out of scope. I think there = are other places where a more detailed of the ABFAB use case would help. = =20 From bclaise@cisco.com Wed Apr 25 06:26:35 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 B163E21F85C7; Wed, 25 Apr 2012 06:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 5hYTzX8vleoo; Wed, 25 Apr 2012 06:26:35 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id AB1C321F85B4; Wed, 25 Apr 2012 06:26:34 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3PDQXpg017301; Wed, 25 Apr 2012 15:26:33 +0200 (CEST) Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3PDQWnf018949; Wed, 25 Apr 2012 15:26:32 +0200 (CEST) Message-ID: <4F97FB88.7020300@cisco.com> Date: Wed, 25 Apr 2012 15:26:32 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Leif Johansson References: <4F853D62.1090204@sunet.se> <20120411091551.GA26732@elstar.local> <4F854E70.4060900@sunet.se> <20120411094234.GA26959@elstar.local> <4F855825.1090409@sunet.se> In-Reply-To: <4F855825.1090409@sunet.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-netmod-smi-yang.all@tools.ietf.org, "iesg@ietf.org" , Leif Johansson , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-netmod-smi-yang-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: Wed, 25 Apr 2012 13:26:35 -0000 Hi Juergen, > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/11/2012 11:42 AM, Juergen Schoenwaelder wrote: >> On Wed, Apr 11, 2012 at 11:27:12AM +0200, Leif Johansson wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 04/11/2012 11:15 AM, Juergen Schoenwaelder wrote: >>>> On Wed, Apr 11, 2012 at 10:14:26AM +0200, Leif Johansson >>>> wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> >>>>> >>>>> 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. >>>>> >>>>> The document specifies a translation between SMIv2 (and by >>>>> reference to RFC 3584, SMIv1) and YANG. YANG is the >>>>> information model language used in NETCONF. >>>>> >>>>> This draft is outside my subject-matter expertise but the >>>>> core security issue seems to be around translation of the >>>>> SMIv2 MAX-ACCESS macro to YANG. Since YANG doesn't define >>>>> any corresponding element an extension to YANG is defined. >>>>> >>>>> However there doesn't seem to be any requirement to >>>>> implement that extension. The security considerations section >>>>> refers the reader to the security considerations sections for >>>>> YANG, NETCONF, SMI etc but claims that "The translation >>>>> itself has no security impact on the Internet.". >>>>> >>>>> I would have liked to see a clear normative statement to the >>>>> effect that if you relied on MAX-ACCESS in the SMIv2 version >>>>> of a MIB then you MUST implement the YANG extension for SMI >>>>> and that the NETCONF implementation used MUST respect the >>>>> resulting smiv2:max-access statements. >>>> Hi, >>>> >>>> the MAX-ACCESS in the SMIv2 really has nothing to do with >>>> access control. See section 7.3 of RFC 2578 for the details. >>>> Also note that the SMiv2 to YANG mapping is readonly, that is >>>> even if the SMIv2 MAX-ACCESS is "read-write" or "read-create", >>>> the corresponsing YANG leaf is read-only. >>>> >>>> Note that access control in the SNMP world is handled by VACM >>>> (RFC 3415) and in the NETCONF world by NACM (RFC 6536). >>>> >>>> /js >>>> >>> As I said this is somewhat outside my comfort-zone but I don't >>> understand how MAX-ACCESS isn't related to access restrictions >>> given the security considerations section of rfc 3584. >> The MAX-ACCESS documents whether an object from a data modeling >> perspective is in principle writable/creatable or always readonly. >> In other words, it documents that maximum possible access to an >> object from a data modeling perspective. There are objects (e.g., >> counters) that are inherently readonly and hence have a MAX-ACCESS >> readonly. Other objects may in principle be writable from a >> modeling perspective. There are two ways to constrain a MAX-ACCESS >> in the SNMP world: >> >> * First, implementation may implement writable objects as readonly >> objects. Sometimes there are specific conformance definitions >> that specifically allow for such implementations. Sometimes >> implementations do this on their own choice, ideally documented in >> so call AGENT-CAPABILITIES (a machine readable documentation of >> deviations from a conformance definition). >> >> * Second, an access control model (with a collection of access >> control rules) is used to determine at runtime whether the >> MAX-ACCESS should be restricted. >> >> The MIB security considerations boilerplate commonly used in MIB >> documents requires that MIB authors document which objects may be >> criticial to protect. This is essentially advise to people >> deploying MIB modules on how to construct their runtime access >> control rules. >> >> Coming back to the SMIv2 to YANG translation, it turned out that >> for various other technical reasons, the translation to YANG is >> readonly (or config false as we say in the YANG community). Hence, >> even if an SMIv2 object has a MAX-ACCESS of readwrite, the >> corresponding YANG leaf will be config false. Hence, the current >> text in the security considerations says: >> >> 13. Security Considerations >> >> This document defines a translation of SMIv2 MIB modules into YANG >> modules, enabling read-only access to data objects defined in >> SMIv2 MIB modules via NETCONF. The translation itself has no >> security impact on the Internet. >> >> Does this help? >> >> /js >> > It helps me right now but how do we help future readers? I jumped to > this conclusion just by tracing some of the security considerations > sections. Perhaps you should add a a condensed version of your excellent > explanation to the security considerations? Do you plan on adding such an explanation in the draft, or at least give pointers to the different RFCs? Regards, Benoit (trying to evaluate if/how we can close this issue) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk+FWCUACgkQ8Jx8FtbMZncLkgCfapCD+u5r5atcyG1v7b0fTNca > FVMAn0V2cLrHYjhqRMTMzjnsNII1DPzn > =2P16 > -----END PGP SIGNATURE----- > > From j.schoenwaelder@jacobs-university.de Wed Apr 25 06:33:37 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 59D9021F86A1; Wed, 25 Apr 2012 06:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.164 X-Spam-Level: X-Spam-Status: No, score=-103.164 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 5sqlpR--YkZJ; Wed, 25 Apr 2012 06:33:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AD64921F86A0; Wed, 25 Apr 2012 06:33:36 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00DD520E23; Wed, 25 Apr 2012 15:33:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jmH3z7uMBijR; Wed, 25 Apr 2012 15:33:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F0D920E1F; Wed, 25 Apr 2012 15:33:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 52D611EA52C5; Wed, 25 Apr 2012 15:33:37 +0200 (CEST) Date: Wed, 25 Apr 2012 15:33:37 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20120425133337.GA87285@elstar.local> Mail-Followup-To: Benoit Claise , Leif Johansson , draft-ietf-netmod-smi-yang.all@tools.ietf.org, "iesg@ietf.org" , Leif Johansson , "secdir@ietf.org" References: <4F853D62.1090204@sunet.se> <20120411091551.GA26732@elstar.local> <4F854E70.4060900@sunet.se> <20120411094234.GA26959@elstar.local> <4F855825.1090409@sunet.se> <4F97FB88.7020300@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F97FB88.7020300@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: draft-ietf-netmod-smi-yang.all@tools.ietf.org, "secdir@ietf.org" , Leif Johansson , "iesg@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-netmod-smi-yang-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 13:33:37 -0000 On Wed, Apr 25, 2012 at 03:26:32PM +0200, Benoit Claise wrote: > Do you plan on adding such an explanation in the draft, or at least > give pointers to the different RFCs? Benoit, I made some changes in the -05 version in the hope that this was sufficient. In particular, I am spelling out that the RFCs containing the SMIv2 data models contain a discussion of the sensitivity of the various objects and I added an explicite reference to the NETCONF access control model. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Wed Apr 25 06:46:51 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 6EAD621F86B2; Wed, 25 Apr 2012 06:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 sAfHf7PvHIbC; Wed, 25 Apr 2012 06:46:50 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 68C6521F86AD; Wed, 25 Apr 2012 06:46:50 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3PDkn18019721; Wed, 25 Apr 2012 15:46:49 +0200 (CEST) Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3PDkmpi010396; Wed, 25 Apr 2012 15:46:48 +0200 (CEST) Message-ID: <4F980048.6050100@cisco.com> Date: Wed, 25 Apr 2012 15:46:48 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Leif Johansson , draft-ietf-netmod-smi-yang.all@tools.ietf.org, "iesg@ietf.org" , Leif Johansson , "secdir@ietf.org" References: <4F853D62.1090204@sunet.se> <20120411091551.GA26732@elstar.local> <4F854E70.4060900@sunet.se> <20120411094234.GA26959@elstar.local> <4F855825.1090409@sunet.se> <4F97FB88.7020300@cisco.com> <20120425133337.GA87285@elstar.local> In-Reply-To: <20120425133337.GA87285@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [secdir] secdir review of draft-ietf-netmod-smi-yang-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: Wed, 25 Apr 2012 13:46:51 -0000 Thanks Juergen! Regards, Benoit > On Wed, Apr 25, 2012 at 03:26:32PM +0200, Benoit Claise wrote: > >> Do you plan on adding such an explanation in the draft, or at least >> give pointers to the different RFCs? > Benoit, > > I made some changes in the -05 version in the hope that this was > sufficient. In particular, I am spelling out that the RFCs containing > the SMIv2 data models contain a discussion of the sensitivity of the > various objects and I added an explicite reference to the NETCONF > access control model. > > /js > From shanna@juniper.net Wed Apr 25 07:20:53 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 9CA4621F85CE; Wed, 25 Apr 2012 07:20:53 -0700 (PDT) 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 cOaNe6GGnFmu; Wed, 25 Apr 2012 07:20:52 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 199F921F855F; Wed, 25 Apr 2012 07:20:51 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKT5gIKovjWSqQ+oT6bm+NBhQFKhtv5c2L@postini.com; Wed, 25 Apr 2012 07:20:51 PDT 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; Wed, 25 Apr 2012 07:19:18 -0700 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; Wed, 25 Apr 2012 07:19:17 -0700 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; Wed, 25 Apr 2012 10:19:17 -0400 From: Stephen Hanna To: Joe Salowey Date: Wed, 25 Apr 2012 10:19:16 -0400 Thread-Topic: [secdir] secdir review of draft-ietf-emu-chbind-14 Thread-Index: Ac0ipSXRiClaowWfTXGXyVxa8+AmcgAOvi8Q Message-ID: References: <4BB606A5-B3E0-4132-96EC-3E8BCE0B927B@cisco.com> In-Reply-To: <4BB606A5-B3E0-4132-96EC-3E8BCE0B927B@cisco.com> 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 Cc: Sam Hartman , "draft-ietf-emu-chbind@tools.ietf.org" , IETF-Discussion list , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-emu-chbind-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, 25 Apr 2012 14:20:53 -0000 Thanks, Joe. Looks like we've reached agreement on most things. There are a few items left where Sam's input is needed. I'll wait to see what he has to say. Thanks, Steve > -----Original Message----- > From: Joe Salowey [mailto:jsalowey@cisco.com] > Sent: Wednesday, April 25, 2012 1:34 AM > To: Stephen Hanna > Cc: draft-ietf-emu-chbind@tools.ietf.org; secdir@ietf.org; IETF- > Discussion list; Sam Hartman > Subject: Re: [secdir] secdir review of draft-ietf-emu-chbind-14 > Importance: High > > > On Apr 24, 2012, at 2:05 PM, Stephen Hanna wrote: > > > Joe, > > > > I'm glad that my comments were useful to you and to the editors > > of this draft. I will respond to your comments below inline. > > I'm going to clip out as much as I can, including anything > > that has already been agreed on. > > > > Thanks, > > > > Steve > > > > ---------- > > > > Joe Salowey wrote: > >> > >> On Apr 13, 2012, at 11:26 AM, Stephen Hanna wrote: > >> > >>> In the Introduction, the second paragraph says that the > >>> problem "results when the same credentials are used to > >>> access multiple services that differ in some interesting > >>> property". Do you mean client or server credentials? > >>> I think you mean EAP server credentials. Please be more > >>> explicit to make this clearer, since many people will > >>> assume that you mean client (EAP peer) credentials. If > >>> I'm correct and you do mean EAP server credentials, > >>> I suggest that you say so in the first sentence of > >>> this paragraph and also in the last sentence. > >> > >> [Joe] The case here is both client and server credentials. If > >> different credentials are required for each type of service then the > >> authenticator will not be able to lie about the type of service it > is > >> representing to the client because the client credentials are bound > to > >> the service. > > > > SH> I don't see what the problem is with using the same > > client credentials with two different services if the > > server credentials are different. The client will be able > > to detect a lying NAS easily since the server credentials > > won't match what it expects for that service. Could you > > please explain this more? > > > > [Joe] In many cases the server credentials will be the same. They will > be the credentials of the AAA server. > > >>> In the first paragraph of the Problem Statement, the second > >>> sentence says "However, when operating in pass-through mode, > >>> the EAP server can be far removed from the authenticator." > >>> While this is true, I think the more relevant statement here > >>> is that the EAP server can be far removed from the EAP peer. > >>> This paragraph is all about problems that can arise when > >>> parties between the EAP peer and the EAP server (including > >>> the authenticator) are malicious or compromised. So the > >>> important thing to point out at the start of the paragraph > >>> is the large number of parties that may come between the > >>> EAP server and the EAP peer. > >>> > >> > >> [Joe] I think I see your point, but I'm not sure. Traditionally, > we > >> have often thought of the path between EAP peer and EAP > authenticator > >> as being vulnerable to having multiple parties able to insert > >> themselves into the conversation. However it may be the case that > the > >> authenticator the peer is talking to isn't the one it thinks it is > and > >> the "real" authenticator may be somewhere in the path as well. The > >> conversation between the EAP peer and EAP server will not be > >> compromised, however the result of the conversation may not have its > >> intended effect. > > > > My point is that having a long distance between the EAP server > > and the authenticator has little to do with the "lying NAS" > > problem. The problem is that there are potentially untrustworthy > > parties (the NAS and any proxies) between the EAP peer and the > > EAP server and the EAP peer is trusting what it's told by them. > > If the EAP server and the authenticator were two inches apart > > with no intermediaries, that wouldn't help. The problem is the > > potentially untrustworthy folks between the EAP server and > > the EAP peer. You're trying to verify some of what they're > > telling the EAP peer. So I'm not sure that sentence helps but > > if it does, the problem is between the EAP peer and the EAP server. > > > > [Joe] I don't have an issue with stating that the problem is between > the peer and the server, but I'd like to hear the author's view on > this. > > >> > >> [Joe] THis is historical and reflects the discussion we had in the > >> working as the document was being developed. > >> > >>> I see > >>> several downsides to including that text in this document. > >>> First, you're making it harder for the reader to understand > >>> what they actually need to do to implement this protocol. > >>> You've probably decreased by half the number of people who > >>> will actually read all of this document. Second, some people > >>> will use that digression to support arguments like ("My > >>> incompatible implementation is compliant with RFC XXXX > >>> because I encoded the network information into a blob > >>> and used that to generate EAP session keys"). IETF is an > >>> engineering organization. We should make our specs as clear > >>> and simple as possible and no simpler. This document includes > >>> lots of interesting theory that's not needed for its purpose. > >>> If you're interested in seeing this document widely implemented, > >>> I suggest that you remove as much of that as possible and focus > >>> the document on explaining the problem and defining a protocol > >>> that solves it. Or you can leave it as is. I'm sure some people > >>> will implement it. Just not as many. Friendly suggestion. Take > >>> it or leave it. > >> > >> [Joe] I can see your point, but I think some members of the working > >> group would object if we removed some of this material. If its not > >> clear perhaps we can so a better job of indicating what is normative > >> and what is informative. > > > > OK. If you think the WG really wants this confusing text, > > leave it in. But maybe you should start section 4 by saying > > "This section describes several possible design choices > > for channel bindings. It is not normative." And then you'll > > need to change, delete, or move the paragraph in section 4.2 > > that includes a MUST and a SHOULD. I think that paragraph is > > redundant with the first paragraph in section 6.1 and not > > specific to sending channel bindings in the Secure Association > > Protocol (which is the topic of section 4.2) so I'd suggest > > that you just delete it. You won't lose anything. > > > [Joe] I'm OK with this. > > >>> In section 7.1, you explain that this document isn't useful > >>> without an accompanying document defining what information > >>> should be included in i1 for each lower layer. Are those > >>> documents being prepared for all or at least some of the > >>> lower layers? I couldn't find any in a quick search. I know > >>> we can't wait for everything to be ready but it would be > >>> nice to see at least one or two of those documents so that > >>> we can have confidence that this protocol can support all > >>> the things that those documents will need. > >> > >> [Joe] That not how I interpret the text in section 7.1. This > document > >> does specify a general attribute that can be used to specify the > type > >> of lower layer used to carry EAP. Section 7.1 states that > additional > >> documents will be needed to specify attributes specific to a > particular > >> lower layer. ABFAB is working on a document that contains this > >> information for their lower layer, draft-ietf-abfab-gss-eap. > > > > Without a document that defines what information should be > > included in i1 for a given lower layer, the only thing this > > protocol gives you is a way to confirm that the EAP server > > is OK with the lower layer advertised by the authenticator. > > Whoop-dee-do. That doesn't address any of the use cases > > described in the Problem Statement. In all those cases, > > the authenticator is advertising a lower layer that's > > supported by the EAP server. > > > > I'm not saying that EAP channel bindings have no value. > > I'm just saying that they don't have much value without > > a document that specifies the attributes relevant to > > the lower layer that's in use. So let's publish this > > spec and the GSS-EAP spec. But let's also work on a > > spec that describes the attributes for 802.11. > > > > [Joe] I agree we should work on a spec for 802.11 and perhaps other 802 > networks as well. > > > > >>> As I read section 8, I wonder whether include the User-Name > >>> attribute in i2 could open the system up to attacks where > >>> an authenticator or intermediate proxy could remove the > >>> anonymity of a user who's using a pseudonym for the > >>> username by changing the value of the User-Name attribute > >>> to the username of the user suspected of being responsible > >>> for this authentication. If the channel bindings checks > >>> fail, the authenticator will know they were wrong but if > >>> the channel bindings checks succeed, the authenticator > >>> will have confirmation of the user's identity. > >> > >> [Joe] Perhaps, on the one hand I would think the system would not > >> behave this way, the server would be expecting a pseudonym or token > and > >> fail if it got something else. On the other hand, I don' think the > >> text for the user-name check or the test itself are that useful. We > >> could either warn against the possible identity disclosure or remove > >> the user-name check. > > > > I'd be inclined to warn about the problem since there may still > > be some utility in checking the value. Whichever you prefer. > > > > [Joe] I think adding the warning is fine. > > > > >>> At the top of page 23, you say that "In many EAP deployments > >>> today attacks where one NAS can impersonate another are > >>> out of scope." Do you mean that these attacks are generally > >>> not considered but they are a potential problem? Or that > >>> they are not a problem? I think they are always a possible > >>> problem. Even when all the NASes are owned and managed by > >>> the same organization that runs the AAA server and no proxies > >>> are used, there's still the potential for a NAS to become > >>> compromised. So I think you should say these attacks are > >>> "not considered although a real concern" not that they are > >>> "out of scope". > >> > >> [Joe] As EAP is deployed in most cases today the authenticator is > not > >> identified, it is merely authorized as being part of the network. > The > >> peer does not expect differentiated service based on the NAS it is > >> connected to. Since the service is the same it does not matter to > the > >> peer if one authenticator impersonates another. When we start > >> discussing use case such as ABFAB where different services are being > >> provided did the identity of the authenticator really become an > issue. > >> > >> Perhaps the following text is better > >> > >> "In many EAP deployments today attacks where one authenticator can > >> impersonate another not a real concern since different > authenticators > >> provide the same service. In these situations an authenticator does > >> not gain significant advantage in impersonating another > authenticator. > >> " > > > > I'd say "all authenticators provide the same service". I think > > that's what you meant to say. With that change, my concerns are > > allayed. > > > [Joe] Yes, thanks. > > > > >>> In the next paragraph, you say that when cryptographic binding > >>> is used in a tunnel method, the MSK is disclosed to the NAS. > >>> I don't think that's right. The MSK that's disclosed to the > >>> NAS is the one generated by the outer method. The MSK that's > >>> used in cryptographic binding is the one that's generated by > >>> the inner method. I don't think there's a problem there. > >> > >> [Joe] OK, this test is referring to where there is separate between > >> the terminating server of the inner and outer methods. Maybe it > would > >> be clearer if the text said the following: > >> > >> "Even when cryptographic binding does attempt to confirm that the > inner > >> and outer server are the same, the Master Session Key (MSK) from the > >> inner method is typically used to protect the binding. However, if > the > >> outer method tunnel terminates on the authenticator the inner MSK is > >> disclosed to the authenticator, which can attack cryptographic > >> binding." > > > > Who on earth would terminate the outer method on the authenticator? > > The authenticator should be trusted as little as possible. The party > > who terminates the outer tunnel method must be highly trusted. > > One of the main benefits of having an authentication server is to > > reduce the number of highly trusted parties by centralizing the > > most security-critical activities such as authentication. That's > > why we have pass-through authenticator mode. Maybe you're not > > talking about using EAP pass-through authenticator mode any more. > > In that case, there's no backend authentication server so this > > whole document does not apply. At least, I don't think it does. > > Could you point out to me where in this document it explains > > how to handle this situation? If this situation is not in scope > > for this document, I think you should say that and remove this > > text about MSK problems since they don't apply to this document. > > If not using pass-through authenticator mode is in scope for > > this document, please say that and explain how EAP channel > > bindings work in that environment. > > > > [Joe] So, I'm not a big fan of splitting the inner and outer methods, > but there have been quite a few advocates for various use cases. The > current issue was brought up in ABFAB so I think Sam would be better at > providing the motivation for that. > > >>> Later in that paragraph, you say that an attack where the NAS > >>> terminates an EAP tunnel method is not in scope for existing > >>> models for cryptographic binding. I think that's wrong also. > >>> EAP tunnel methods protect against just this sort of attack. > >>> The first step in these methods is for the EAP peer and the > >>> EAP server to build a TLS tunnel. This requires the EAP peer > >>> to authenticate the EAP server and decide whether it's trusted. > >>> If the NAS has credentials that will cause the EAP peer to > >>> trust it as an EAP server, a MITM attack is possible. Of course, > >>> that's true for any secure communications and it's a very bad > >>> situation. That's why the EAP peer must be very careful about > >>> who it trusts and how it authenticates them and the EAP server > >>> (and any CAs or other TTPs) must also be similarly careful. > >>> I don't see that any of this has much to do with channel bindings. > >>> Am I missing something here? If so, please explain it. And maybe > >>> you can clarify the text so that other folks get it also. > >> > >> [Joe] The issue is when you have different services the client may > not > >> have enough information to determine what an authenticator is > >> authorized for based on its identity alone. In this case it would > like > >> help from the server that terminates the inner method. However > current > >> crypto binding is based on the MSK so the authenticator can generate > >> whatever channel binding quantities it wants because the > authenticator > >> has all the necessary key material. In order for channel bindings > to > >> determine if the authenticator is authorized or not, the method > needs > >> protect the channel bindings with a key generated from the inner > method > >> EMSK that the authenticator does not possess. Here is some text > that > >> may help: > >> > >> "If the authenticator controls the cryptographic binding then it > also > >> controls the channel binding parameters and results. If the channel > >> binding process is used to differentiate one authenticator from > another > >> then the authenticator can claim to support services that it was not > >> authorized to. This attack was not in scope for existing threat > models > >> for cryptographic binding because differentiated authenticators was > not > >> a consideration. Thus, existing cryptographic binding does not > >> typically provide mutual authentication of the inner method server > >> required for channel binding." > > > > Again, you've moved beyond pass-through authentication mode. I don't > > think this document covers that. If it's meant to cover that, it's > > missing a lot of text (to describe how that works). > > > [Joe] True, that is why this was previously out of scope. I think > there are other places where a more detailed of the ABFAB use case > would help. From turners@ieca.com Wed Apr 25 12:12: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 8050C21F8940 for ; Wed, 25 Apr 2012 12:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.97 X-Spam-Level: X-Spam-Status: No, score=-100.97 tagged_above=-999 required=5 tests=[AWL=-1.105, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_75=0.6, 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 vT+cjXgHFyF0 for ; Wed, 25 Apr 2012 12:12:16 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [67.18.34.22]) by ietfa.amsl.com (Postfix) with ESMTP id 75B7821F8910 for ; Wed, 25 Apr 2012 12:12:16 -0700 (PDT) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id 0565144D7B273; Wed, 25 Apr 2012 14:12:16 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id EE7C444D7B249 for ; Wed, 25 Apr 2012 14:12:15 -0500 (CDT) Received: from [96.231.123.106] (port=39810 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SN7dO-00070I-Ks; Wed, 25 Apr 2012 14:12:15 -0500 Message-ID: <4F984C8D.7020505@ieca.com> Date: Wed, 25 Apr 2012 15:12:13 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Fred Templin References: <36214B77-821E-47B9-8349-A89D2800E24C@cisco.com> <1335199956.12137.YahooMailNeo@web161604.mail.bf1.yahoo.com> <94CFA5A8-1D03-4BA2-993E-073B523538D7@cisco.com> <1335291276.47915.YahooMailNeo@web161603.mail.bf1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-123-106.washdc.east.verizon.net (thunderfish.local) [96.231.123.106]:39810 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "draft-templin-aero.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-templin-aero-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: Wed, 25 Apr 2012 19:12:17 -0000 On 4/24/12 6:55 PM, Joe Salowey wrote: > > On Apr 24, 2012, at 11:14 AM, Fred Templin wrote: > >> Hello Joe, >> >> Thank you for your comments. To your question on specifying a digital >> signing mechanism, would the concern be addressed if I were to say >> something like: "e.g., using IPsec AH, etc." ? >> > [Joe] Not really. What I'm looking for is something that specifies the mechanism and how its used. Something like > > "Implementations MUST support as a means to authenticate the origin of the AERO messages. AERO peers MUST support establishing an using with as specified in. During establishment AERO hosts MUST be able identify AERO intermediate routers through mechanism defined in. " > > The stuff in the<> should be replaced with something that makes sense. I'm not sure that IPSEC AH or any of the other things in<> are really appropriate in this case. The idea here is that there is some minimum mechanism that implementations can use to secure these messages. Securing the messages involves the transform for authenticating the messages (perhaps IPSEC AH), mechanism for key management perhaps (IKV2 with certificates) and a way to establish that you are taking to the right router (perhaps be able to match a field in a certificate to a particular name or domain). My hope is that there already is something that would fit the bill and we could just reference that specification. Some of the SEND variants may be useful in this scenario, but I didn't get a chance to dig into this. Fred, Note that every so often somebody tries to deprecate AH because very few folks use it. spt > Joe > > >> Fred >> fltemplin@acm.org >> >> ----- Original Message ----- >>> From: Joe Salowey >>> To: Fred Templin >>> Cc: "secdir@ietf.org"; The IESG; "draft-templin-aero.all@tools.ietf.org" >>> Sent: Tuesday, April 24, 2012 10:47 AM >>> Subject: Re: secdir review of draft-templin-aero-10 >>> >>> T hanks for the quick response, comments inline: >>> On Apr 23, 2012, at 9:52 AM, Fred Templin wrote: >>> >>>> (Resending with comments as inline text) >>>> >>>> Hello Joe, >>>> >>>> Thank you for these comments. Please see below for my proposed >>>> resolutions: >>>> >>>> Fred >>>> fltemplin@acm.org >>>> >>>> From: Joe Salowey >>>> To: secdir@ietf.org; The IESG; >>> draft-templin-aero.all@tools.ietf.org >>>> Sent: Sunday, April 22, 2012 3:00 PM >>>> Subject: secdir review of draft-templin-aero-10 >>>> >>>> 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. >>>> >>>> I apologize for the delay in getting this review out. Hopefully it is >>> still useful. >>>> >>>> This first set of comments is primarily for the authors. >>>> >>>> 1. In section 4.4.4 on Data origin authentication the last paragraph states >>> that only the 3rd of the above conditions is acceptable, do you really mean the >>> 4th? >>>> >>>>>>> Begin FLT response >>>> You are correct; this should say the 4th and can be fixed in the next >>> version. >>>>>>> End FLT response >>>> >>> >>> [Joe] OK >>> >>>> 2. In section 4.4.4 there is reference to the packet including a digital >>> signature to authenticate the origin. What is the signature mechanism? Is this >>> SEND or something different? I did not see a reference to it. >>>> >>>>>>> Begin FLT response >>>> The digital signature mechanism is out of scope for this document. The text >>>> could be adjusted to say: “…, AERO nodes may be obliged to require the >>>> use of digital signatures applied through means outside the scope of this >>>> document.” >>>>>>> End FLT response >>>> >>> >>> [Joe] I was hoping that something would be specified for interoperability, I >>> think there are many cases where you would have to resort to a signing >>> mechanism, however it may be the case that AERO may be deployed where spoofing >>> of messages is not a concern (perhaps this should be the recommendation until a >>> signing mechanism is specified). The ADs can decide if this is an issue or not. >>> >>>> 3. The security considerations do not say much about the consequences of >>> trusting an inappropriate intermediate router, ingress node or egress node. >>> Clearly DOS to the ingress node is a possibility. Data modification and >>> disclosure can be a goal of an attacker who tries to control the routing. Are >>> there other issues the reader should be aware of (perhaps other DOS attacks such >>> as amplification attacks). Anything outside the considerations of RFC4861)? >>>> >>>>>>> Begin FLT response >>>> Proposed resolution is to re-write the first paragraph of Section 6 as >>> follows: >>>> >>>> “AERO link security considerations are the same as for standard IPv6 >>> Neighbor Discovery >>>> (RFC4861) except that AERO improves on some aspects. In particular, AERO is >>> dependent >>>> on a trust basis between AERO edge nodes and intermediate routers, where >>> the edge nodes >>>> must only engage in the AERO mechanism when it is facilitated by a trusted >>> intermediate >>>> router.” >>>>>>> End FLT response >>>> >>> >>> [Joe] OK thanks. >>> >>>> 4. The security consideration section indicates that spoofing protection >>> can be provided by links that provide link layer security mechanisms. Link >>> Layer security mechanisms may or may not help. I believe more information is >>> needed here. L2 mechanisms may not provide adequate protection of upper layer >>> address bindings. In some cases L2 mechanisms do not provide source origin >>> authentication such as multicast traffic protected with the group key in WiFi >>> and group security associations in 802.1AE (MACSEC). >>>> >>>>>>> Begin FLT response >>>> Proposed resolution is to re-write the second paragraph of Section 6 as >>> follows: >>>> “AERO links must be protected against spoofing attacks in which an attacker >>>> on the link pretends to be a trusted neighbor. Links that provide >>> link-layer >>>> securing mechanisms (e.g., WiFi networks) and links that provide physical >>>> security (e.g., enterprise network LANs) provide only a fist-line of >>> defense. >>>> In some instances, therefore, additional securing assurances against >>> on-link >>>> spoofing attacks are required. For example, if the source can through some >>>> means digitally sign its messages the destination can verify the signatures >>> to >>>> ensure data origin authentication. Exact mechanisms for digitally signing >>> and >>>> verifying signatures are outside the scope of this document.” >>>>>>> End FLT response >>>> >>> [Joe] Thanks. (same comment on the specification of the signing mechanism as >>> above). >>> >>>> This set of comments is mostly for the area directors: >>>> >>>> 1. I am mostly concerned about the lack of definition for the digital >>> signature mechanism. Perhaps this is easily rectified by a reference to an >>> existing specification. Its not clear to me what the specification would be >>> (perhaps SEND??)? Is something needed in addition? >>>> 2. The risks of not securing the proposal are not defined in the security >>> considerations section. I think this would be helpful, but may not be strictly >>> necessary. There is some mention of Link-Layer security helping in some aspects >>> of this, but its not clear on what characteristics the lower layer security >>> needs to provide. >>>> >>>> Cheers, >>>> >>>> Joe >>>> >>> > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From mundy@sparta.com Wed Apr 25 13:32:01 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 622AF21F8836; Wed, 25 Apr 2012 13:32:01 -0700 (PDT) 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 WO9BsYj5zSRG; Wed, 25 Apr 2012 13:32:00 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id CD27C21F8828; Wed, 25 Apr 2012 13:32:00 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q3PKW0ge030471; Wed, 25 Apr 2012 15:32:00 -0500 Received: from tanis.huntsville.ads.sparta.com ([157.185.63.118]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q3PKVn2B014573; Wed, 25 Apr 2012 15:31:52 -0500 Received: from [10.88.50.168] (157.185.61.22) by tanis.huntsville.ads.sparta.com (157.185.63.118) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Apr 2012 15:31:49 -0500 From: Russ Mundy Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Apr 2012 16:31:45 -0400 Message-ID: <1D737EE0-34DB-4B62-AC1C-7E521D667AE9@sparta.com> To: , MIME-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-fecframe-raptor-all@tools.ietf.org, Russ Mundy Subject: [secdir] secdir review of draft-ietf-fecframe-raptor-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: Wed, 25 Apr 2012 20:32:01 -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. Since this I-D provides specifications for various coding schemes for = the Forward Error Correction (FEC) defined in published RFCs, the = Security Considerations section makes appropriate reference to the = general framework RFC [RFC6363] for security considerations. I agree = that this I-D does not introduce additional vulnerabilities beyond those = defined in [RFC6363]. Russ Mundy From weiler+secdir@watson.org Thu Apr 26 09:05:27 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 A557421E80B4 for ; Thu, 26 Apr 2012 09:05:27 -0700 (PDT) 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=[AWL=0.000, 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 DVsz87AYYR25 for ; Thu, 26 Apr 2012 09:05:27 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 176CE21E8111 for ; Thu, 26 Apr 2012 09:05:26 -0700 (PDT) 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 q3QG5PpH046179 for ; Thu, 26 Apr 2012 12:05:25 -0400 (EDT) (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 q3QG5PJ8046173 for ; Thu, 26 Apr 2012 12:05:25 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 26 Apr 2012 12:05:25 -0400 (EDT) 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, 26 Apr 2012 12:05:25 -0400 (EDT) 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, 26 Apr 2012 16:05:27 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Sandy Murphy is next in the rotation. For telechat 2012-05-10 Reviewer LC end Draft Jeffrey Hutzelman T 2012-03-21 draft-betts-itu-oam-ach-code-point-04 Stephen Kent T 2012-05-07 draft-ietf-appsawg-mime-default-charset-03 Warren Kumari T 2012-05-02 draft-ietf-appsawg-about-uri-scheme-04 Alexey Melnikov T - draft-ietf-avtext-rams-scenarios-04 Tina TSOU TR2012-03-23 draft-ietf-mpls-tp-oam-analysis-09 Last calls and special requests: Reviewer LC end Draft Alan DeKok 2012-04-17 draft-claise-export-application-info-in-ipfix-05 Jeffrey Hutzelman 2012-04-16 draft-ietf-manet-nhdp-mib-12 Matt Lepinski 2012-05-02 draft-ietf-mboned-64-multicast-address-format-01 Catherine Meadows 2012-04-25 draft-ietf-dane-protocol-19 Kathleen Moriarty 2012-05-07 draft-ietf-ledbat-congestion-09 Russ Mundy 2012-05-09 draft-ietf-netext-access-network-option-10 Tim Polk 2012-03-21 draft-ietf-pwe3-redundancy-bit-06 Carl Wallace - draft-ietf-roll-minrank-hysteresis-of-09 Sam Weiler 2012-03-23 draft-sakane-dhc-dhcpv6-kdc-option-14 Nico Williams - draft-ietf-httpbis-p5-range-19 Tom Yu - draft-ietf-httpbis-p6-cache-19 Glen Zorn - draft-ietf-httpbis-p7-auth-19 From catherine.meadows@nrl.navy.mil Thu Apr 26 13:08:57 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 0623F21F87AA; Thu, 26 Apr 2012 13:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 OBflyWElrlSS; Thu, 26 Apr 2012 13:08:54 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by ietfa.amsl.com (Postfix) with ESMTP id B44D021F87A5; Thu, 26 Apr 2012 13:08:52 -0700 (PDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q3QK8pJ4027801; Thu, 26 Apr 2012 16:08:51 -0400 (EDT) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q3QK8m23002989; Thu, 26 Apr 2012 16:08:49 -0400 (EDT) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2012042616084817191 ; Thu, 26 Apr 2012 16:08:48 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary=Apple-Mail-13-681443327 Date: Thu, 26 Apr 2012 16:08:48 -0400 Message-Id: <5846D07A-1A16-4F27-A0C6-D206115DE1F3@nrl.navy.mil> To: draft-ietf-dane-protocol.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] SecDir Review of draft-ietf-dane-protocol-19 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, 26 Apr 2012 20:08:57 -0000 --Apple-Mail-13-681443327 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 gives the specification of a method for DNS-based = authentication of named entities (that is public key certificates) for TLS. The draft is written in response to a perception of the risk = involved in the current use of multiple Certificate Authorities (CAs) to issue certificates. Because CAs are large, they make inviting = targets, and because different CAs may be sign the same certificate, compromise of even one CA could allow it to issue a replacement = certificate with a bogus key that would replace the legitimate = certificate signed by the honest CAs. This has led to some incidents involving compromise of major web sites involving millions of users. Another approach is to make use of the DNS infrastructure instead of = public CAs: keys are associated with domain names, and can only be = signed with a key associated with the parent of the domain name. The keys = would be managed by the same entities that manage the domain name. This has the advantage that an untrustworthy signer can only compromise = keys in its own subdomains, so the advantage of to an attacker of compromising a single CA is lessened. =20 This document describes a TLSA Resource Record that is used to = associate a certificate with the domain name where the record is found = and specifies its use in TLS. This requires changes to the client software = so that clients are able to interpret the records, but no change to the = server software. The security considerations section is thorough and well-thought out. = It consists of three parts. The first part describes security risks not = necessarily (to my knowledge) related to the choice of DNS domains rather than CAs, and describes possible = mitigations. The second gives a comparison of the security issues involved in relying on DNS domains rather than CAs; the = authors make it clear that this is not an open-and-shut case either way, and that much is still unknown. The third describes, and suggests = mitigations against, some security risks that are specific to DNS, = having to do with attacks based on deliberate mis-association of TLSA records and DNS names. I only have a couple of minor questions. First, the authors contrast = the number of certificates signed by the CAs and by the DNS domains. = However, it would appear that as get closer to the root of the domain name tree, number of = certificates would get large, and that some domains, such as .com, would be more likely to have certificates that are attractive to attackers = than others. However, I don't know how large CAs get by comparison; if = there are some figures available, that would help. Secondly, it appears that all the = risks described in the first part of the security considerations apply = equally as well to the current CA-based system as well, except that the risks attributed to = rogue DNS administrators would instead be attributed to rogue CA's. If that is so, it would be good = to have a sentence saying so. On the other hand, if some of the risks = apply only to the new system and not the current one, it would be good to know about these = too. =20 Finally, a nit: what are the A/AAAA records referred to in the first = part of the security considerations section? I could not find a = definition in the document. Cathy Meadows Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail-13-681443327 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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 gives the = specification of a method for DNS-based authentication of named entities = (that is public key certificates) for
TLS.  The draft is = written in response to a perception of the risk involved in the current = use of multiple Certificate Authorities (CAs)
to issue = certificates.  Because CAs are large, they make inviting targets, = and because different CAs may be sign the same = certificate,
compromise of even one CA could allow it to issue = a replacement certificate with a bogus key that would replace the = legitimate certificate
signed by the honest CAs.  This = has led to some incidents involving
compromise of major web = sites involving millions of users.

Another = approach is  to make use of the DNS infrastructure instead of = public CAs: keys are associated with domain names, and can only be = signed
with a key associated with the parent of the domain = name.  The keys would be managed by the same entities that manage = the domain name.
This has the advantage that an untrustworthy = signer can only compromise keys in its own subdomains, so the advantage = of to an attacker
of compromising a single CA is lessened. =  

This document describes a TLSA Resource = Record  that is used to associate a certificate with the domain = name where the record is found and
specifies its use in TLS. =  This requires changes to the client software so that clients are = able to interpret the records, but no change to the server = software.

The security considerations section = is thorough and well-thought out.  It consists of three parts. =  The first part describes security risks not necessarily (to my = knowledge) related
to the choice of DNS domains rather = than CAs, and describes possible mitigations.  The second gives a = comparison of the
security issues involved in relying on DNS = domains rather than CAs; the authors make it clear that this is not an = open-and-shut case either
way, and that much is still unknown. =  The third describes, and suggests mitigations against, some = security risks that are specific to DNS, having to do with attacks based = on deliberate mis-association
of TLSA records and DNS = names.

 I only  have a couple of = minor questions.  First,  the authors contrast the number of = certificates signed by the  CAs and by the DNS domains. =  However, it would
appear that as get closer to the root = of the domain name tree, number of certificates would get large, and = that some domains, such as .com, would
be more likely to have = certificates that are attractive to attackers than others. =  However, I don't know how large CAs get by comparison; if there = are some
figures available, that would help.  Secondly, = it appears that all the risks described in the first part of the = security considerations apply equally as well to the
current = CA-based system as well, except that the risks attributed to rogue DNS = administrators would
instead be attributed to rogue CA's. =   If that is so, it would be good to have a sentence saying so. =  On the other hand, if some of the risks apply only to the = new
system and not the current one, it would be good to know = about these too.  

Finally, a nit: what = are the A/AAAA records referred to in the first part of the security = considerations section?  I could not find a definition in the = document.

Cathy = Meadows


Catherine Meadows
Naval = Research Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: 202-767-3490
fax: = 202-404-7942
email: catherine.meadows@nrl.navy.= mil

= --Apple-Mail-13-681443327-- From fltemplin@acm.org Tue Apr 24 16:16: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 0990B21F84A7 for ; Tue, 24 Apr 2012 16:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, 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 mSRaFC9RkMVE for ; Tue, 24 Apr 2012 16:16:22 -0700 (PDT) Received: from nm30.bullet.mail.bf1.yahoo.com (nm30.bullet.mail.bf1.yahoo.com [98.139.212.189]) by ietfa.amsl.com (Postfix) with SMTP id 2E69A21F84A2 for ; Tue, 24 Apr 2012 16:16:22 -0700 (PDT) Received: from [98.139.212.145] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 24 Apr 2012 23:16:21 -0000 Received: from [98.139.212.251] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 24 Apr 2012 23:16:21 -0000 Received: from [127.0.0.1] by omp1060.mail.bf1.yahoo.com with NNFMP; 24 Apr 2012 23:16:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 563802.84343.bm@omp1060.mail.bf1.yahoo.com Received: (qmail 1700 invoked by uid 60001); 24 Apr 2012 23:16:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1335309381; bh=+H0AjVaKRI3KKCm7u7eSr1uM4Y9BB3+JoPUofQVRFBA=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Q5aR0YHo7WY9qHdR3BLJhYuhHAFp+QUqBJhK/9Jt4kbV9DxM/PVlISC/hIrjJHV0ZBI0ycbF5/vOlNIbEZznWX6EIxXLu82QxsQTeNWZ0ysKhlJa9Zb7roFTdnztqG5YkCVE9o5PSOqEPmp1HQnr3T0QVfbysssrgONhtligUu8= X-YMail-OSG: omqnlzUVM1lPFGu0vnsBlY.s_0.Ut2gjygQeK02AEeDt295 o_NowiUA6IIeOLV4zniO7Pj77j70SWO.Mnv5Hu5AnO7ktX824IhR5ld8VOkG ztgEI4IjENquScONZ3tP_A81VI_Y22MWXj2aOpDhjmcNtMoCG1rKTJhIEiCb M4huV5sIUtXIo9mSnRr9_YUgt947519UGYequtVpqoEsWCnS8zdPci_JKQXJ rqC75ClSo3qBfnnh_7hUIs_nYHy_rr8PwElYwB0_KCa4KNZoLxGNtPeQAWUY NPf5lESloykq8U__5_MDA_ex_buX85I_aT24mm4YsPhJAHWMIVW3Xocqp8SN SdW.OlCiwv0c0HA2AbytPvNAOCaaa1pHmop72B_dg8eCjixg7FFh36u4fiCe knhrFufJRjjht3NGQSefr6azHZP1uCoX5L.E1tVpihHDkt8WYMtYNn54nksb ut5PiQpdcaVWJwPfEuWyZN0Y3dGm1CcSh4U3Wq02pRlpB1Hoi Received: from [130.76.32.212] by web161606.mail.bf1.yahoo.com via HTTP; Tue, 24 Apr 2012 16:16:21 PDT X-RocketYMMF: fltemplin X-Mailer: YahooMailWebService/0.8.117.340979 References: <36214B77-821E-47B9-8349-A89D2800E24C@cisco.com> <1335199956.12137.YahooMailNeo@web161604.mail.bf1.yahoo.com> <94CFA5A8-1D03-4BA2-993E-073B523538D7@cisco.com> <1335291276.47915.YahooMailNeo@web161603.mail.bf1.yahoo.com> Message-ID: <1335309381.87321.YahooMailNeo@web161606.mail.bf1.yahoo.com> Date: Tue, 24 Apr 2012 16:16:21 -0700 (PDT) From: "Fred L. Templin" To: Joe Salowey In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1989420431-639094091-1335309381=:87321" X-Mailman-Approved-At: Sun, 29 Apr 2012 06:46:22 -0700 Cc: "draft-templin-aero.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-templin-aero-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Fred L. Templin" List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 23:16:24 -0000 --1989420431-639094091-1335309381=:87321 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0AHi Joe,=0A=0A>________________________________=0A> From: Joe Salowey = =0A>To: Fred Templin =0A>Cc: "sec= dir@ietf.org" ; The IESG ; "draft-templin-a= ero.all@tools.ietf.org" =0A>Sent: T= uesday, April 24, 2012 3:55 PM=0A>Subject: Re: secdir review of draft-templ= in-aero-10=0A> =0A>=0A>On Apr 24, 2012, at 11:14 AM, Fred Templin wrote:=0A= >=0A>> Hello Joe,=0A>> =0A>> Thank you for your comments. To your question = on specifying a digital=0A>> signing mechanism, would the concern be addres= sed if I were to say=0A>> something like: "e.g., using IPsec AH, etc." ?=0A= >> =0A>[Joe] Not really.=C2=A0 What I'm looking for is something that speci= fies the mechanism and how its used.=C2=A0 Something like =0A>=0A>"Implemen= tations MUST support as a means to authenticate the origin of th= e AERO messages.=C2=A0 AERO peers MUST support establishing an u= sing with as specified in .=C2= =A0=C2=A0=C2=A0During establishment AERO hosts MUST be able identify A= ERO intermediate routers through mechanism defined in .=C2=A0 "=0A=0AYour text looks good, but I really don't want to exclusi= vely wrap this=0Aaround IPsec AH - ultimately, I would like to have somethi= ng much=0Alighter-weight, but its design is still pending. As this is going= for=0Aexperimental, part of the experiment should be to investigate altern= atives=0Aand bring forth the best option or options in a follow-on standard= s-track=0Aeffort. And it is also not at all the case that all AERO use case= s would=0Arequire a digital signing mechanism - I have several in mind that= do not.=0A=0A=0A>=0A>The stuff in the <> should be replaced with something= that makes sense.=C2=A0 I'm not sure that IPSEC AH or any of the other thi= ngs in <> are really appropriate in this case.=C2=A0 The idea here is that = there is some minimum mechanism that implementations can use to secure thes= e messages. Securing the messages involves the transform for authenticating= the messages (perhaps IPSEC AH), mechanism for key management perhaps (IKV= 2 with certificates) and a way to establish that you are taking to the righ= t router (perhaps be able to match a field in a certificate to a particular= name or domain).=C2=A0=C2=A0=C2=A0My hope is that there already is somethi= ng that would fit the bill and we could just reference that specification.= =C2=A0 Some of the SEND variants may be useful in this scenario,=C2=A0 but = I didn't get a chance to dig into this.=0A=0AI would be happy to hear about= alternatives that would satisfy the need,=0Abut I don't think it would be = based on SEND since signatures would be=0Arequired on all packets and not j= ust ND messages. Or, perhaps you have=0Aheard of SEND variants that extend = to cover data packets as well as ND?=0A=0A=0AThanks - Fred=0Afltemplin@acm.= org=0A=0A>=0A>Joe=0A>=0A>=0A>> Fred=0A>> fltemplin@acm.org=0A>> =0A>> -----= Original Message -----=0A>> > From: Joe Salowey =0A>> = > To: Fred Templin =0A>> > Cc: "secdir@ietf.org" ; The IESG ; "draft-templin-aero.all@tools.ietf.= org" =0A>> > Sent: Tuesday, April 24= , 2012 10:47 AM=0A>> > Subject: Re: secdir review of draft-templin-aero-10= =0A>> > =0A>> >T hanks for the quick response, comments inline:=0A>> > On A= pr 23, 2012, at 9:52 AM, Fred Templin wrote:=0A>> > =0A>> >> (Resending wit= h comments as inline text)=0A>> >> =0A>> >> Hello Joe,=0A>> >> =0A>> >> Tha= nk you for these comments. Please see below for my proposed=0A>> >> resolut= ions:=0A>> >> =0A>> >> Fred=0A>> >> fltemplin@acm.org=0A>> >> =0A>> >> From= : Joe Salowey =0A>> >> To: secdir@ietf.org; The IESG ; =0A>> > draft-templin-aero.all@tools.ietf.org =0A>> >> Sent:= Sunday, April 22, 2012 3:00 PM=0A>> >> Subject: secdir review of draft-tem= plin-aero-10=0A>> >> =0A>> >> I have reviewed this document as part of the = security directorate's =0A>> >> ongoing effort to review all IETF documents= being processed by the =0A>> >> IESG.=C2=A0 These comments were written pr= imarily for the benefit of the =0A>> >> security area directors.=C2=A0 Docu= ment editors and WG chairs should treat =0A>> >> these comments just like a= ny other last call comments.=0A>> >> =0A>> >> I apologize for the delay in = getting this review out.=C2=A0 Hopefully it is =0A>> > still useful.=C2=A0 = =0A>> >> =0A>> >> This first set of comments is primarily for the authors.= =0A>> >> =0A>> >> 1. In section 4.4.4 on Data origin authentication the las= t paragraph states =0A>> > that only the 3rd of the above conditions is acc= eptable, do you really mean the =0A>> > 4th?=0A>> >> =0A>> >> >>> Begin FLT= response=0A>> >> You are correct; this should say the 4th and can be fixed= in the next =0A>> > version.=0A>> >> >>> End FLT response=0A>> >> =0A>> > = =0A>> > [Joe] OK=0A>> > =0A>> >> 2. In section 4.4.4 there is reference to = the packet including a digital =0A>> > signature to authenticate the origin= .=C2=A0 What is the signature mechanism?=C2=A0 Is this =0A>> > SEND or some= thing different? I did not see a reference to it.=0A>> >> =0A>> >> >>> Begi= n FLT response=0A>> >> The digital signature mechanism is out of scope for = this document. The text=0A>> >> could be adjusted to say: =E2=80=9C=E2=80= =A6, AERO nodes may be obliged to require the=0A>> >> use of digital signat= ures applied through means outside the scope of this=0A>> >> document.=E2= =80=9D=0A>> >> >>> End FLT response=0A>> >> =0A>> > =0A>> > [Joe] I was hop= ing that something would be specified for interoperability,=C2=A0 I =0A>> >= think there are many cases where you would have to resort to a signing =0A= >> > mechanism, however it may be the case that AERO may be deployed where = spoofing =0A>> > of messages is not a concern (perhaps this should be the r= ecommendation until a =0A>> > signing mechanism is specified).=C2=A0 The AD= s can decide if this is an issue or not.=0A>> >=0A>> >> 3. The security con= siderations do not say much about the consequences of =0A>> > trusting an i= nappropriate intermediate router, ingress node or egress node. =0A>> > Clea= rly DOS to the ingress node is a possibility.=C2=A0 Data modification and = =0A>> > disclosure can be a goal of an attacker who tries to control the ro= uting.=C2=A0 Are =0A>> > there other issues the reader should be aware of (= perhaps other DOS attacks such =0A>> > as amplification attacks).=C2=A0 Any= thing outside the considerations of RFC4861)?=0A>> >> =0A>> >> >>> Begin FL= T response=0A>> >> Proposed resolution is to re-write the first paragraph o= f Section 6 as =0A>> > follows:=0A>> >>=C2=A0 =0A>> >> =E2=80=9CAERO link s= ecurity considerations are the same as for standard IPv6 =0A>> > Neighbor D= iscovery=0A>> >> (RFC4861) except that AERO improves on some aspects. In pa= rticular, AERO is =0A>> > dependent=0A>> >> on a trust basis between AERO e= dge nodes and intermediate routers, where =0A>> > the edge nodes=0A>> >> mu= st only engage in the AERO mechanism when it is facilitated by a trusted = =0A>> > intermediate=0A>> >> router.=E2=80=9D=0A>> >> >>> End FLT response= =0A>> >> =0A>> > =0A>> > [Joe] OK thanks.=0A>> > =0A>> >> 4. The security c= onsideration section indicates that spoofing protection =0A>> > can be prov= ided by links that provide link layer security mechanisms.=C2=A0 =C2=A0 Lin= k =0A>> > Layer security mechanisms may or may not help.=C2=A0 I believe mo= re information is =0A>> > needed here.=C2=A0 L2 mechanisms may not provide = adequate protection of upper layer =0A>> > address bindings.=C2=A0 In some = cases L2 mechanisms do not provide source origin =0A>> > authentication suc= h as multicast=C2=A0 traffic protected with the group=C2=A0 key in WiFi =0A= >> > and group security associations in 802.1AE (MACSEC).=0A>> >> =0A>> >> = >>> Begin FLT response=0A>> >> Proposed resolution is to re-write the secon= d paragraph of Section 6 as =0A>> > follows:=0A>> >> =E2=80=9CAERO links mu= st be protected against spoofing attacks in which an attacker=0A>> >> on th= e link pretends to be a trusted neighbor.=C2=A0 Links that provide =0A>> > = link-layer=0A>> >> securing mechanisms (e.g., WiFi networks) and links that= provide physical=0A>> >> security (e.g., enterprise network LANs) provide = only a fist-line of =0A>> > defense.=0A>> >> In some instances, therefore, = additional securing assurances against =0A>> > on-link=0A>> >> spoofing att= acks are required. For example, if the source can through some=0A>> >> mean= s digitally sign its messages the destination can verify the signatures =0A= >> > to=0A>> >> ensure data origin authentication. Exact mechanisms for dig= itally signing =0A>> > and=0A>> >> verifying signatures are outside the sco= pe of this document.=E2=80=9D=0A>> >> >>> End FLT response=0A>> >> =0A>> > = [Joe] Thanks. (same comment on the specification of the signing mechanism a= s =0A>> > above). =0A>> > =0A>> >> This set of comments is mostly for the a= rea directors:=0A>> >> =0A>> >> 1. I am mostly concerned about the lack of = definition for the digital =0A>> > signature mechanism.=C2=A0 Perhaps this = is easily rectified by a reference to an =0A>> > existing specification. It= s not clear to me what the specification would be =0A>> > (perhaps SEND??)?= =C2=A0 Is something needed in addition? =0A>> >> 2.=C2=A0 The risks of not = securing the proposal are not defined in the security =0A>> > consideration= s section. I think this would be helpful, but may not be strictly =0A>> > n= ecessary.=C2=A0 There is some mention of Link-Layer security helping in som= e aspects =0A>> > of this, but its not clear on what characteristics the lo= wer layer security =0A>> > needs to provide. =0A>> >> =0A>> >> Cheers,=0A>>= >> =0A>> >> Joe=0A>> >> =0A>> >=0A>=0A>=0A>=0A> --1989420431-639094091-1335309381=:87321 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Joe,

>________________________________
> Fro= m: Joe Salowey <jsalowey@cisco.com>
>To: Fred Templin <fltem= plin@yahoo.com>
>Cc: "secdir@ietf.org" <secdir@ietf.org>; T= he IESG <iesg@ietf.org>; "draft-templin-aero.all@tools.ietf.org" <= draft-templin-aero.all@tools.ietf.org>
>Sent: Tuesday, April 24, = 2012 3:55 PM
>Subject: Re: secdir review of draft-templin-aero-10
= >
>
>On Apr 24, 2012, at 11:14 AM, Fred Templin wrote:
&= gt;
>> Hello Joe,
>>
>> Thank you for your comm= ents. To your question on specifying a digital
>> signing mechanis= m, would the concern be addressed if I were to say
>> something li= ke: "e.g., using IPsec AH, etc." ?
>>
>[Joe] Not really.  What I'm looking for is something that specifies the mechani= sm and how its used.  Something like
>
>"Implementations = MUST support <IPSEC AH> as a means to authenticate the origin of the = AERO messages.  AERO peers MUST support establishing an <IPSEC SA&g= t; using <IKEv2> with <certificates> as specified in <extern= al reference>.   During <SA> establishment AERO hos= ts MUST be able identify AERO intermediate routers through mechanism define= d in <RFCxxxx or section y.yy>.  "

Your= text looks good, but I really don't want to exclusively wrap this
around IPsec AH - ultimately, I would like to have something much
lighter-weight, but its design is still pending. As this is going for
experimental, part of the experiment should be to investigate alter= natives
and bring forth the best option or options in a follow-on standards-track
effort. And it is also not at all the = case that all AERO use cases would
require a digital signing mech= anism - I have several in mind that do not.

&g= t;
>The stuff in the <> should be replaced with something that = makes sense.  I'm not sure that IPSEC AH or any of the other things in= <> are really appropriate in this case.  The idea here is that = there is some minimum mechanism that implementations can use to secure thes= e messages. Securing the messages involves the transform for authenticating= the messages (perhaps IPSEC AH), mechanism for key management perhaps (IKV= 2 with certificates) and a way to establish that you are taking to the righ= t router (perhaps be able to match a field in a certificate to a particular= name or domain).   My hope is that there already is somethi= ng that would fit the bill and we could just reference that specification.  Some of the SEND variants may be useful in this scena= rio,  but I didn't get a chance to dig into this.

=
I would be happy to hear about alternatives that would satisfy the nee= d,
but I don't think it would be based on SEND since signatures w= ould be
required on all packets and not just ND messages. Or, per= haps you have
heard of SEND variants that extend to cover data pa= ckets as well as ND?

Thanks - Fred
f= ltemplin@acm.org

>
>Joe
>
>>> Fred
>> fltemplin@acm.org
>>
>> ----= - Original Message -----
>> > From: Joe Salowey <jsalowey@ci= sco.com>
>> > To: Fred Templin <fltemplin@yahoo.com>>> > Cc: "secdir@ietf.org" <secdir@ietf.org>; The IESG <= ;iesg@ietf.org>; "draft-templin-aero.all@tools.ietf.org" <draft-templin-aero.all@tools.ietf.org>
>> > Sent: Tuesd= ay, April 24, 2012 10:47 AM
>> > Subject: Re: secdir review of = draft-templin-aero-10
>> >
>> >T hanks for the qui= ck response, comments inline:
>> > On Apr 23, 2012, at 9:52 AM,= Fred Templin wrote:
>> >
>> >> (Resending with= comments as inline text)
>> >>
>> >> Hello = Joe,
>> >>
>> >> Thank you for these comment= s. Please see below for my proposed
>> >> resolutions:
&g= t;> >>
>> >> Fred
>> >> fltemplin@a= cm.org
>> >>
>> >> From: Joe Salowey <jsa= lowey@cisco.com>
>> >> To: secdir@ietf.org; The IESG <= iesg@ietf.org>;
>> > draft-templin-aero.all@tools.ietf.org =
>> >> Sent: Sunday, April 22, 2012 3:00 PM
>> >> Subject: secdir review of draft-templin-aero-10>> >>
>> >> I have reviewed this document as p= art of the security directorate's
>> >> ongoing effort to r= eview 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 chair= s should treat
>> >> these comments just like any other las= t call comments.
>> >>
>> >> I apologize for= the delay in getting this review out.  Hopefully it is
>> &= gt; still useful. 
>> >>
>> >> This fi= rst set of comments is primarily for the authors.
>> >>
= >> >> 1. In section 4.4.4 on Data origin authentication the las= t paragraph states
>> > that only the 3rd of the above conditions is acceptable, do you really mean the
>> > 4th?>> >>
>> >> >>> Begin FLT response>> >> You are correct; this should say the 4th and can be fixe= d in the next
>> > version.
>> >> >>> = End FLT response
>> >>
>> >
>> > [= Joe] OK
>> >
>> >> 2. In section 4.4.4 there is= reference to the packet including a digital
>> > signature to= authenticate the origin.  What is the signature mechanism?  Is t= his
>> > SEND or something different? I did not see a referenc= e to it.
>> >>
>> >> >>> Begin FLT = response
>> >> The digital signature mechanism is out of sco= pe for this document. The text
>> >> could be adjusted to sa= y: =E2=80=9C=E2=80=A6, AERO nodes may be obliged to require the
>> >> use of digital signatures applied through means outside the scope= of this
>> >> document.=E2=80=9D
>> >> >&= gt;> End FLT response
>> >>
>> >
>>= ; > [Joe] I was hoping that something would be specified for interoperab= ility,  I
>> > think there are many cases where you would= have to resort to a signing
>> > mechanism, however it may be= the case that AERO may be deployed where spoofing
>> > of mes= sages is not a concern (perhaps this should be the recommendation until a <= br>>> > signing mechanism is specified).  The ADs can decide = if this is an issue or not.
>> >
>> >> 3. The se= curity considerations do not say much about the consequences of
>>= ; > trusting an inappropriate intermediate router, ingress node or egres= s node.
>> > Clearly DOS to the ingress node is a possibility.  Data modification and
>> > disclosure can = be a goal of an attacker who tries to control the routing.  Are
&g= t;> > there other issues the reader should be aware of (perhaps other= DOS attacks such
>> > as amplification attacks).  Anythi= ng outside the considerations of RFC4861)?
>> >>
>>= ; >> >>> Begin FLT response
>> >> Proposed re= solution is to re-write the first paragraph of Section 6 as
>> &g= t; follows:
>> >> 
>> >> =E2=80=9CAERO = link security considerations are the same as for standard IPv6
>>= > Neighbor Discovery
>> >> (RFC4861) except that AERO im= proves on some aspects. In particular, AERO is
>> > dependent<= br>>> >> on a trust basis between AERO edge nodes and intermedi= ate routers, where
>> > the edge nodes
>> >> must only engage in the AERO mechanism when it is facilitated by a trusted=
>> > intermediate
>> >> router.=E2=80=9D
&g= t;> >> >>> End FLT response
>> >>
>= > >
>> > [Joe] OK thanks.
>> >
>> = >> 4. The security consideration section indicates that spoofing prot= ection
>> > can be provided by links that provide link layer s= ecurity mechanisms.    Link
>> > Layer security mech= anisms may or may not help.  I believe more information is
>>= ; > needed here.  L2 mechanisms may not provide adequate protection= of upper layer
>> > address bindings.  In some cases L2 = mechanisms do not provide source origin
>> > authentication su= ch as multicast  traffic protected with the group  key in WiFi >> > and group security associations in 802.1AE (MACSEC).
>> >>
>> >> >>> Begin FL= T response
>> >> Proposed resolution is to re-write the seco= nd paragraph of Section 6 as
>> > follows:
>> >>= ; =E2=80=9CAERO links must be protected against spoofing attacks in which a= n attacker
>> >> on the link pretends to be a trusted neighb= or.  Links that provide
>> > link-layer
>> >&= gt; securing mechanisms (e.g., WiFi networks) and links that provide physic= al
>> >> security (e.g., enterprise network LANs) provide on= ly a fist-line of
>> > defense.
>> >> In some i= nstances, therefore, additional securing assurances against
>> &g= t; on-link
>> >> spoofing attacks are required. For example,= if the source can through some
>> >> means digitally sign i= ts messages the destination can verify the signatures
>> > to
>> >> ensure data origin authentication. Exact mechanism= s for digitally signing
>> > and
>> >> verifyin= g signatures are outside the scope of this document.=E2=80=9D
>> &= gt;> >>> End FLT response
>> >>
>> >= ; [Joe] Thanks. (same comment on the specification of the signing mechanism= as
>> > above).
>> >
>> >> This = set of comments is mostly for the area directors:
>> >>
= >> >> 1. I am mostly concerned about the lack of definition for= the digital
>> > signature mechanism.  Perhaps this is e= asily rectified by a reference to an
>> > existing specificati= on. Its not clear to me what the specification would be
>> > (= perhaps SEND??)?  Is something needed in addition?
>> >&g= t; 2.  The risks of not securing the proposal are not defined in the security
>> > considerations section. I think this would be h= elpful, but may not be strictly
>> > necessary.  There is= some mention of Link-Layer security helping in some aspects
>> &= gt; of this, but its not clear on what characteristics the lower layer secu= rity
>> > needs to provide.
>> >>
>>= >> Cheers,
>> >>
>> >> Joe
>>= ; >>
>> >
>
>
>
>
 --1989420431-639094091-1335309381=:87321-- From fltemplin@acm.org Wed Apr 25 18:51: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 AD52421E80C5 for ; Wed, 25 Apr 2012 18:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.616 X-Spam-Level: X-Spam-Status: No, score=-100.616 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_75=0.6, 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 1-E6iIGCMybZ for ; Wed, 25 Apr 2012 18:51:58 -0700 (PDT) Received: from nm21-vm0.bullet.mail.bf1.yahoo.com (nm21-vm0.bullet.mail.bf1.yahoo.com [98.139.213.137]) by ietfa.amsl.com (Postfix) with SMTP id B992721E80CA for ; Wed, 25 Apr 2012 18:51:57 -0700 (PDT) Received: from [98.139.212.153] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 26 Apr 2012 01:51:57 -0000 Received: from [98.139.212.246] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 26 Apr 2012 01:51:57 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 26 Apr 2012 01:51:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 45586.59904.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 20626 invoked by uid 60001); 26 Apr 2012 01:51:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1335405117; bh=hrFR1Lk+95T8DbfCxFYIzkwuG1o6tU5PHYpX+F+gAAk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=DX4aT6PqrOuCxxD79IAOAkLBCM/Eqb/s38F0Pl5jFHLF8CbFmZ2gJa7nrM3xhiYxyqg4dlYMLfRBvnWWm5RJB/UWiFV9oWrLk6hfgo+/LWzkuT0SahMaoI2TjdTrvtcFfe844jxnBBHw7i2RipCuBLk0NkxfYKGMxkF6CQcRNVU= X-YMail-OSG: zZ6KoZEVM1mVvYqca50Q4CNJdzunc0n9j5Q2lfW4E48X8hE W_vZZid2nwE1lpnN91x04LMpdQ2U_A7NHKWJVL6GUi8twTwe_2VW0BlUjgFp WFAl7z8OvNJiJP_4WutB1QUiUmFWGxcscfWIHFSJ1TnCn1MOE23h0nTnsh.s 4YHtXPtdIUAP7oNAqfF0VBe4dcS_kkiznvH7qQx6QRbhlFXbfQDAZ.zV9qrr TprnybkYkaEA8u8lScHfCDeugRp9yHojeMdV9oFbnX3kcsYNIzOd_s9bZb8n AJuES5B.lqZRVA3EmfJCxCyMHbnFRUk1Aa3FVCPSdBIlqNSuqMOb3YYsUBNB UQl7S.6y5WizfYtCEgAaSJdqvMVwGwzxjAWrMCNBYdzSPKUJlZWOuVsfMLT4 LaXiMihqtrTatoDEDxPO4PWBOKNCC3WP25T4eRCCtdBMTkBbIlEelnIOMQDg 4UkGCDlRYwoE9HpfLQ98YxHkPUndbW3ub9cZpA1uvJDVho1jK6Zg- Received: from [64.134.241.75] by web161601.mail.bf1.yahoo.com via HTTP; Wed, 25 Apr 2012 18:51:56 PDT X-RocketYMMF: fltemplin X-Mailer: YahooMailWebService/0.8.117.340979 References: <36214B77-821E-47B9-8349-A89D2800E24C@cisco.com> <1335199956.12137.YahooMailNeo@web161604.mail.bf1.yahoo.com> <94CFA5A8-1D03-4BA2-993E-073B523538D7@cisco.com> <1335291276.47915.YahooMailNeo@web161603.mail.bf1.yahoo.com> <4F984C8D.7020505@ieca.com> Message-ID: <1335405116.20323.YahooMailNeo@web161601.mail.bf1.yahoo.com> Date: Wed, 25 Apr 2012 18:51:56 -0700 (PDT) From: "Fred L. Templin" To: Sean Turner In-Reply-To: <4F984C8D.7020505@ieca.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-83809723-874235264-1335405116=:20323" X-Mailman-Approved-At: Sun, 29 Apr 2012 06:46:22 -0700 Cc: "draft-templin-aero.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-templin-aero-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Fred L. Templin" List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 01:51:59 -0000 ---83809723-874235264-1335405116=:20323 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0AHi Sean,=0A=0AThanks for your point about occasional attempts to depr= ecate IPsec AH. What=0AI have in mind for AERO is something sort of like IP= sec AH but much lighter=0Aweight. I have the design worked out in my head a= nd could use some input=0Afrom others, but is this the correct forum to kic= k ideas around?=0A=0AFred=0Afltemplin@acm.org=0A=0A=0A>____________________= ____________=0A> From: Sean Turner =0A>To: Fred Templin <= fltemplin@yahoo.com> =0A>Cc: Joe Salowey ; "draft-templ= in-aero.all@tools.ietf.org" ; The IE= SG ; "secdir@ietf.org" =0A>Sent: Wednesday= , April 25, 2012 12:12 PM=0A>Subject: Re: [secdir] secdir review of draft-t= emplin-aero-10=0A> =0A>On 4/24/12 6:55 PM, Joe Salowey wrote:=0A>>=0A>> On = Apr 24, 2012, at 11:14 AM, Fred Templin wrote:=0A>>=0A>>> Hello Joe,=0A>>>= =0A>>> Thank you for your comments. To your question on specifying a digita= l=0A>>> signing mechanism, would the concern be addressed if I were to say= =0A>>> something like: "e.g., using IPsec AH, etc." ?=0A>>>=0A>> [Joe] Not = really.=C2=A0 What I'm looking for is something that specifies the mechanis= m and how its used.=C2=A0 Something like=0A>>=0A>> "Implementations MUST su= pport=C2=A0 as a means to authenticate the origin of the AERO mes= sages.=C2=A0 AERO peers MUST support establishing an=C2=A0 using<= IKEv2>=C2=A0 with=C2=A0 as specified in.= =C2=A0=C2=A0=C2=A0During=C2=A0 establishment AERO hosts MUST be able id= entify AERO intermediate routers through mechanism defined in.=C2=A0 "=0A>>=0A>> The stuff in the<>=C2=A0 should be replaced = with something that makes sense.=C2=A0 I'm not sure that IPSEC AH or any of= the other things in<>=C2=A0 are really appropriate in this case.=C2=A0 The= idea here is that there is some minimum mechanism that implementations can= use to secure these messages. Securing the messages involves the transform= for authenticating the messages (perhaps IPSEC AH), mechanism for key mana= gement perhaps (IKV2 with certificates) and a way to establish that you are= taking to the right router (perhaps be able to match a field in a certific= ate to a particular name or domain).=C2=A0=C2=A0=C2=A0My hope is that there= already is something that would fit the bill and we could just reference t= hat specification.=C2=A0 Some of the SEND variants may be useful in this sc= enario,=C2=A0 but I didn't get a chance to dig into this.=0A>=0A>Fred,=0A>= =0A>Note that every so often somebody tries to deprecate AH because very fe= w =0A>folks use it.=0A>=0A>spt=0A>=0A>> Joe=0A>>=0A>>=0A>>> Fred=0A>>> flte= mplin@acm.org=0A>>>=0A>>> ----- Original Message -----=0A>>>> From: Joe Sal= owey=0A>>>> To: Fred Templin=0A>>>= > Cc: "secdir@ietf.org"; The IESG; "draft-t= emplin-aero.all@tools.ietf.org"=0A>>= >> Sent: Tuesday, April 24, 2012 10:47 AM=0A>>>> Subject: Re: secdir review= of draft-templin-aero-10=0A>>>>=0A>>>> T hanks for the quick response, com= ments inline:=0A>>>> On Apr 23, 2012, at 9:52 AM, Fred Templin wrote:=0A>>>= >=0A>>>>> (Resending with comments as inline text)=0A>>>>>=0A>>>>> Hello Jo= e,=0A>>>>>=0A>>>>> Thank you for these comments. Please see below for my pr= oposed=0A>>>>> resolutions:=0A>>>>>=0A>>>>> Fred=0A>>>>> fltemplin@acm.org= =0A>>>>>=0A>>>>> From: Joe Salowey=0A>>>>> To: secdir@i= etf.org; The IESG;=0A>>>> draft-templin-aero.all@tools.ietf.= org=0A>>>>> Sent: Sunday, April 22, 2012 3:00 PM=0A>>>>> Subject: secdir re= view of draft-templin-aero-10=0A>>>>>=0A>>>>> I have reviewed this document= as part of the security directorate's=0A>>>>> ongoing effort to review all= IETF documents being processed by the=0A>>>>> IESG.=C2=A0 These comments w= ere written primarily for the benefit of the=0A>>>>> security area director= s.=C2=A0 Document editors and WG chairs should treat=0A>>>>> these comments= just like any other last call comments.=0A>>>>>=0A>>>>> I apologize for th= e delay in getting this review out.=C2=A0 Hopefully it is=0A>>>> still usef= ul.=0A>>>>>=0A>>>>> This first set of comments is primarily for the authors= .=0A>>>>>=0A>>>>> 1. In section 4.4.4 on Data origin authentication the las= t paragraph states=0A>>>> that only the 3rd of the above conditions is acce= ptable, do you really mean the=0A>>>> 4th?=0A>>>>>=0A>>>>>>>> Begin FLT res= ponse=0A>>>>> You are correct; this should say the 4th and can be fixed in = the next=0A>>>> version.=0A>>>>>>>> End FLT response=0A>>>>>=0A>>>>=0A>>>> = [Joe] OK=0A>>>>=0A>>>>> 2. In section 4.4.4 there is reference to the packe= t including a digital=0A>>>> signature to authenticate the origin.=C2=A0 Wh= at is the signature mechanism?=C2=A0 Is this=0A>>>> SEND or something diffe= rent? I did not see a reference to it.=0A>>>>>=0A>>>>>>>> Begin FLT respons= e=0A>>>>> The digital signature mechanism is out of scope for this document= . The text=0A>>>>> could be adjusted to say: =E2=80=9C=E2=80=A6, AERO nodes= may be obliged to require the=0A>>>>> use of digital signatures applied th= rough means outside the scope of this=0A>>>>> document.=E2=80=9D=0A>>>>>>>>= End FLT response=0A>>>>>=0A>>>>=0A>>>> [Joe] I was hoping that something w= ould be specified for interoperability,=C2=A0 I=0A>>>> think there are many= cases where you would have to resort to a signing=0A>>>> mechanism, howeve= r it may be the case that AERO may be deployed where spoofing=0A>>>> of mes= sages is not a concern (perhaps this should be the recommendation until a= =0A>>>> signing mechanism is specified).=C2=A0 The ADs can decide if this i= s an issue or not.=0A>>>>=0A>>>>> 3. The security considerations do not say= much about the consequences of=0A>>>> trusting an inappropriate intermedia= te router, ingress node or egress node.=0A>>>> Clearly DOS to the ingress n= ode is a possibility.=C2=A0 Data modification and=0A>>>> disclosure can be = a goal of an attacker who tries to control the routing.=C2=A0 Are=0A>>>> th= ere other issues the reader should be aware of (perhaps other DOS attacks s= uch=0A>>>> as amplification attacks).=C2=A0 Anything outside the considerat= ions of RFC4861)?=0A>>>>>=0A>>>>>>>> Begin FLT response=0A>>>>> Proposed re= solution is to re-write the first paragraph of Section 6 as=0A>>>> follows:= =0A>>>>>=0A>>>>> =E2=80=9CAERO link security considerations are the same as= for standard IPv6=0A>>>> Neighbor Discovery=0A>>>>> (RFC4861) except that = AERO improves on some aspects. In particular, AERO is=0A>>>> dependent=0A>>= >>> on a trust basis between AERO edge nodes and intermediate routers, wher= e=0A>>>> the edge nodes=0A>>>>> must only engage in the AERO mechanism when= it is facilitated by a trusted=0A>>>> intermediate=0A>>>>> router.=E2=80= =9D=0A>>>>>>>> End FLT response=0A>>>>>=0A>>>>=0A>>>> [Joe] OK thanks.=0A>>= >>=0A>>>>> 4. The security consideration section indicates that spoofing pr= otection=0A>>>> can be provided by links that provide link layer security m= echanisms.=C2=A0 =C2=A0 Link=0A>>>> Layer security mechanisms may or may no= t help.=C2=A0 I believe more information is=0A>>>> needed here.=C2=A0 L2 me= chanisms may not provide adequate protection of upper layer=0A>>>> address = bindings.=C2=A0 In some cases L2 mechanisms do not provide source origin=0A= >>>> authentication such as multicast=C2=A0 traffic protected with the grou= p=C2=A0 key in WiFi=0A>>>> and group security associations in 802.1AE (MACS= EC).=0A>>>>>=0A>>>>>>>> Begin FLT response=0A>>>>> Proposed resolution is t= o re-write the second paragraph of Section 6 as=0A>>>> follows:=0A>>>>> =E2= =80=9CAERO links must be protected against spoofing attacks in which an att= acker=0A>>>>> on the link pretends to be a trusted neighbor.=C2=A0 Links th= at provide=0A>>>> link-layer=0A>>>>> securing mechanisms (e.g., WiFi networ= ks) and links that provide physical=0A>>>>> security (e.g., enterprise netw= ork LANs) provide only a fist-line of=0A>>>> defense.=0A>>>>> In some insta= nces, therefore, additional securing assurances against=0A>>>> on-link=0A>>= >>> spoofing attacks are required. For example, if the source can through s= ome=0A>>>>> means digitally sign its messages the destination can verify th= e signatures=0A>>>> to=0A>>>>> ensure data origin authentication. Exact mec= hanisms for digitally signing=0A>>>> and=0A>>>>> verifying signatures are o= utside the scope of this document.=E2=80=9D=0A>>>>>>>> End FLT response=0A>= >>>>=0A>>>> [Joe] Thanks. (same comment on the specification of the signing= mechanism as=0A>>>> above).=0A>>>>=0A>>>>> This set of comments is mostly = for the area directors:=0A>>>>>=0A>>>>> 1. I am mostly concerned about the = lack of definition for the digital=0A>>>> signature mechanism.=C2=A0 Perhap= s this is easily rectified by a reference to an=0A>>>> existing specificati= on. Its not clear to me what the specification would be=0A>>>> (perhaps SEN= D??)?=C2=A0 Is something needed in addition?=0A>>>>> 2.=C2=A0 The risks of = not securing the proposal are not defined in the security=0A>>>> considerat= ions section. I think this would be helpful, but may not be strictly=0A>>>>= necessary.=C2=A0 There is some mention of Link-Layer security helping in s= ome aspects=0A>>>> of this, but its not clear on what characteristics the l= ower layer security=0A>>>> needs to provide.=0A>>>>>=0A>>>>> Cheers,=0A>>>>= >=0A>>>>> Joe=0A>>>>>=0A>>>>=0A>>=0A>> ____________________________________= ___________=0A>> secdir mailing list=0A>> secdir@ietf.org=0A>> https://www.= ietf.org/mailman/listinfo/secdir=0A>> wiki: http://tools.ietf.org/area/sec/= trac/wiki/SecDirReview=0A>>=0A>=0A>=0A> ---83809723-874235264-1335405116=:20323 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Sean,

Thanks for your point about occasional attempts= to deprecate IPsec AH. What
I have in mind for AERO is something= sort of like IPsec AH but much lighter
weight. I have the design= worked out in my head and could use some input
from others, but = is this the correct forum to kick ideas around?

Fr= ed
fltemplin@acm.org

>___________= _____________________
> From: Sean Turner <turners@ieca.com>>To: Fred Templin <fltemplin@yahoo.com>
>Cc: Joe Salowey &= lt;jsalowey@cisco.com>; "draft-templin-aero.all@tools.ietf.org" <draf= t-templin-aero.all@tools.ietf.org>; The IESG <iesg@ietf.org>; "sec= dir@ietf.org" <secdir@ietf.org>
>Sent: Wednesday, April 25, 2012 12:12 PM
>Subject: Re: [secdir] secdir review of draft-temp= lin-aero-10
>
>On 4/24/12 6:55 PM, Joe Salowey wrote:
>&= gt;
>> On Apr 24, 2012, at 11:14 AM, Fred Templin wrote:
>&g= t;
>>> Hello Joe,
>>>
>>> Thank you for= your comments. To your question on specifying a digital
>>> si= gning mechanism, would the concern be addressed if I were to say
>>= ;> something like: "e.g., using IPsec AH, etc." ?
>>>
>= ;> [Joe] Not really.  What I'm looking for is something that specif= ies the mechanism and how its used.  Something like
>>
>= ;> "Implementations MUST support<IPSEC AH>  as a means to aut= henticate the origin of the AERO messages.  AERO peers MUST support es= tablishing an<IPSEC SA>  using<IKEv2>  with<certif= icates>  as specified in<external reference>.   During<SA>  establishment AERO = hosts MUST be able identify AERO intermediate routers through mechanism def= ined in<RFCxxxx or section y.yy>.  "
>>
>> The= stuff in the<>  should be replaced with something that makes se= nse.  I'm not sure that IPSEC AH or any of the other things in<>=   are really appropriate in this case.  The idea here is that the= re is some minimum mechanism that implementations can use to secure these m= essages. Securing the messages involves the transform for authenticating th= e messages (perhaps IPSEC AH), mechanism for key management perhaps (IKV2 w= ith certificates) and a way to establish that you are taking to the right r= outer (perhaps be able to match a field in a certificate to a particular na= me or domain).   My hope is that there already is something = that would fit the bill and we could just reference that specification.  Some of the SEND variants may be useful in this scena= rio,  but I didn't get a chance to dig into this.
>
>Fred,=
>
>Note that every so often somebody tries to deprecate AH bec= ause very few
>folks use it.
>
>spt
>
>> = Joe
>>
>>
>>> Fred
>>> fltemplin@= acm.org
>>>
>>> ----- Original Message -----
>= ;>>> From: Joe Salowey<jsalowey@cisco.com>
>>>&g= t; To: Fred Templin<fltemplin@yahoo.com>
>>>> Cc: "sec= dir@ietf.org"<secdir@ietf.org>; The IESG<iesg@ietf.org>; "draft= -templin-aero.all@tools.ietf.org"<draft-templin-aero.all@tools.ietf.org&= gt;
>>>> Sent: Tuesday, April 24, 2012 10:47 AM
>>&= gt;> Subject: Re: secdir review of draft-templin-aero-10
>>>= >
>>>> T hanks for the quick response, comments inline:
>>>> On Apr 23, 2012, at 9:52 AM, Fred Templin wrot= e:
>>>>
>>>>> (Resending with comments as = inline text)
>>>>>
>>>>> Hello Joe,
= >>>>>
>>>>> Thank you for these comments. = Please see below for my proposed
>>>>> resolutions:
&g= t;>>>>
>>>>> Fred
>>>>> flt= emplin@acm.org
>>>>>
>>>>> From: Joe Sa= lowey<jsalowey@cisco.com>
>>>>> To: secdir@ietf.org= ; The IESG<iesg@ietf.org>;
>>>> draft-templin-aero.all= @tools.ietf.org
>>>>> Sent: Sunday, April 22, 2012 3:00 P= M
>>>>> Subject: secdir review of draft-templin-aero-10>>>>>
>>>>> I have reviewed this documen= t 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.  Docum= ent editors and WG chairs should treat
>>>>> these commen= ts just like any other last call comments.
>>>>>
>&= gt;>>> I apologize for the delay in getting this review out. = Hopefully it is
>>>> still useful.
>>>>><= br>>>>>> This first set of comments is primarily for the aut= hors.
>>>>>
>>>>> 1. In section 4.4.4 o= n Data origin authentication the last paragraph states
>>>> = that only the 3rd of the above conditions is acceptable, do you really mean= the
>>>> 4th?
>>>>>
>>>>&g= t;>>> Begin FLT response
>>>>> You are correct; this should say the 4th and can be fixed in the next
>>&= gt;> version.
>>>>>>>> End FLT response
&g= t;>>>>
>>>>
>>>> [Joe] OK
>= >>>
>>>>> 2. In section 4.4.4 there is reference= to the packet including a digital
>>>> signature to authent= icate the origin.  What is the signature mechanism?  Is this
&= gt;>>> SEND or something different? I did not see a reference to i= t.
>>>>>
>>>>>>>> Begin FLT re= sponse
>>>>> The digital signature mechanism is out of sc= ope for this document. The text
>>>>> could be adjusted t= o say: =E2=80=9C=E2=80=A6, AERO nodes may be obliged to require the
>= >>>> use of digital signatures applied through means outside th= e scope of this
>>>>> document.=E2=80=9D
>>>>>>>> End FLT response>>>>>
>>>>
>>>> [Joe] I was h= oping that something would be specified for interoperability,  I
&g= t;>>> think there are many cases where you would have to resort to= a signing
>>>> mechanism, however it may be the case that A= ERO may be deployed where spoofing
>>>> of messages is not a= concern (perhaps this should be the recommendation until a
>>>= > signing mechanism is specified).  The ADs can decide if this is a= n issue or not.
>>>>
>>>>> 3. The security= considerations do not say much about the consequences of
>>>&g= t; trusting an inappropriate intermediate router, ingress node or egress no= de.
>>>> Clearly DOS to the ingress node is a possibility.&n= bsp; Data modification and
>>>> disclosure can be a goal of an attacker who tries to control the routing.  Are
>>>>= ; there other issues the reader should be aware of (perhaps other DOS attac= ks such
>>>> as amplification attacks).  Anything outsi= de the considerations of RFC4861)?
>>>>>
>>>&= gt;>>>> Begin FLT response
>>>>> Proposed res= olution is to re-write the first paragraph of Section 6 as
>>>&= gt; follows:
>>>>>
>>>>> =E2=80=9CAERO = link security considerations are the same as for standard IPv6
>>&= gt;> Neighbor Discovery
>>>>> (RFC4861) except that AE= RO improves on some aspects. In particular, AERO is
>>>> dep= endent
>>>>> on a trust basis between AERO edge nodes and= intermediate routers, where
>>>> the edge nodes
>>= >>> must only engage in the AERO mechanism when it is facilitated by a trusted
>>>> intermediate
>>>>> rout= er.=E2=80=9D
>>>>>>>> End FLT response
>&g= t;>>>
>>>>
>>>> [Joe] OK thanks.
= >>>>
>>>>> 4. The security consideration sect= ion indicates that spoofing protection
>>>> can be provided = by links that provide link layer security mechanisms.    Link
= >>>> Layer security mechanisms may or may not help.  I bel= ieve more information is
>>>> needed here.  L2 mechanis= ms may not provide adequate protection of upper layer
>>>> a= ddress bindings.  In some cases L2 mechanisms do not provide source or= igin
>>>> authentication such as multicast  traffic pro= tected with the group  key in WiFi
>>>> and group secur= ity associations in 802.1AE (MACSEC).
>>>>>
>>>>>>>> Begi= n FLT response
>>>>> Proposed resolution is to re-write t= he second paragraph of Section 6 as
>>>> follows:
>>= ;>>> =E2=80=9CAERO links must be protected against spoofing attack= s in which an attacker
>>>>> on the link pretends to be a= trusted neighbor.  Links that provide
>>>> link-layer<= br>>>>>> securing mechanisms (e.g., WiFi networks) and links= that provide physical
>>>>> security (e.g., enterprise n= etwork LANs) provide only a fist-line of
>>>> defense.
&g= t;>>>> In some instances, therefore, additional securing assura= nces against
>>>> on-link
>>>>> spoofing a= ttacks are required. For example, if the source can through some
>>= ;>>> means digitally sign its messages the destination can verify the signatures
>>>> to
>>>>> ensure data = origin authentication. Exact mechanisms for digitally signing
>>&g= t;> and
>>>>> verifying signatures are outside the sco= pe of this document.=E2=80=9D
>>>>>>>> End FLT r= esponse
>>>>>
>>>> [Joe] Thanks. (same com= ment on the specification of the signing mechanism as
>>>> a= bove).
>>>>
>>>>> This set of comments is = mostly for the area directors:
>>>>>
>>>>&= gt; 1. I am mostly concerned about the lack of definition for the digital>>>> signature mechanism.  Perhaps this is easily rectif= ied by a reference to an
>>>> existing specification. Its no= t clear to me what the specification would be
>>>> (perhaps = SEND??)?  Is something needed in addition?
>>>>> 2.  The risks of not securing the proposal are not defined in the sec= urity
>>>> considerations section. I think this would be hel= pful, but may not be strictly
>>>> necessary.  There is= some mention of Link-Layer security helping in some aspects
>>>= ;> of this, but its not clear on what characteristics the lower layer se= curity
>>>> needs to provide.
>>>>>
>= ;>>>> Cheers,
>>>>>
>>>>> J= oe
>>>>>
>>>>
>>
>> ____= ___________________________________________
>> secdir mailing list=
>> secdir@ietf.org
>> https://www.ietf.org/mailman/listi= nfo/secdir
>> wiki: http://tool= s.ietf.org/area/sec/trac/wiki/SecDirReview
>>
>
><= br>>
---83809723-874235264-1335405116=:20323-- From alexey.melnikov@isode.com Mon Apr 30 03:56:01 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 72BE721F8496; Mon, 30 Apr 2012 03:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 rZ--6khN2u9M; Mon, 30 Apr 2012 03:56:00 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5D521F848A; Mon, 30 Apr 2012 03:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335783359; d=isode.com; s=selector; i=@isode.com; bh=vaoKXVGbgYhnsbNYWEZpJ8HM9eiAgZVDsvegGm7Anz4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=RW0dAOtrybxx6glRUCNxoGnFMQKvdIFN6m0FCU6eMJ+fhA12DKR1on13NLwR7s0wi1C6Fr UYLNGnMaPMhkerr2rVDArv7f6afQbkMc5sUldrSvS9vD5vqEubqER2Mr0YDgCES+9k2pbV I7jfc4usj7lmsIo7sFwbel7nczneeJQ=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 30 Apr 2012 11:55:59 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F9E6FDF.3080209@isode.com> Date: Mon, 30 Apr 2012 11:56:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: draft-ietf-avtext-rams-scenarios.all@tools.ietf.org, secdir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org Subject: [secdir] SecDir Review of draft-ietf-avtext-rams-scenarios-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: Mon, 30 Apr 2012 10:56:01 -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 Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a method based on RTP and RTP Control Protocol (RTCP) that enables an RTP receiver to rapidly acquire and start consuming the RTP multicast data. Upon a request from the RTP receiver, an auxiliary unicast RTP retransmission session is set up between a retransmission server and the RTP receiver, over which the reference information about the new multicast stream the RTP receiver is about to join is transmitted at an accelerated rate. This document provides example scenarios and discusses how the RAMS solution could be used when there are two or more multicast streams to be acquired from the same or different multicast RTP sessions. The document says that it has no security considerations. While I would agree that it doesn't add new security considerations to the one defined in RFC 6285, I am a bit puzzled why it doesn't say exactly that. RFC 6285 has very extensive Security Considerations. From barryleiba@gmail.com Mon Apr 30 06:05:11 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 9E92E21F8637; Mon, 30 Apr 2012 06:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.964 X-Spam-Level: X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 FEP0xqcaFbsi; Mon, 30 Apr 2012 06:05:11 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 188C421F861F; Mon, 30 Apr 2012 06:05:11 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so967673obb.31 for ; Mon, 30 Apr 2012 06:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=I+PtQ+pHrvh4QRHhyt+sk8f/tpdIkD85nTcinP7vjO0=; b=fRwFL+dXOn44jF53YysrAcM+agAuMZl+K5nsH+EbXZ79KxWUSNX5BD6QfIhoRTPapU QdqayiR2UpigssvwCJ2C6zCkgmz2w/iX2yzqdPAcqZgVe4ZE1GY4mnWG813QCz0W2rre mqilAa4Kh3kJtz2ef4sKluYpanrDT9/6tAtOjO0wtiD1OgcEUI7KIq8zo8s6UZhXEiE2 s5KxzBWT63cd4SgLL2IbHjh3OvNpkyVoBBIBq8DtRv9rJ4pVMwq4RWgOSR09FFBBRSHg 6OOVXW/BE+iQH7cf1R8pCSLDG+47YPwLJJ4IOmF9wUL2cpXJU5NFiQQwSnhcACTO6RKg Vofw== MIME-Version: 1.0 Received: by 10.182.11.40 with SMTP id n8mr27456231obb.32.1335791110746; Mon, 30 Apr 2012 06:05:10 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.10.68 with HTTP; Mon, 30 Apr 2012 06:05:10 -0700 (PDT) In-Reply-To: <4F9E6FDF.3080209@isode.com> References: <4F9E6FDF.3080209@isode.com> Date: Mon, 30 Apr 2012 09:05:10 -0400 X-Google-Sender-Auth: siJtvRZVbSQkR40SGVNnv_yvTOk Message-ID: From: Barry Leiba To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-avtext-rams-scenarios.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir Review of draft-ietf-avtext-rams-scenarios-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: Mon, 30 Apr 2012 13:05:11 -0000 > The document says that it has no security considerations. While I would > agree that it doesn't add new security considerations to the one defined in > RFC 6285, I am a bit puzzled why it doesn't say exactly that. RFC 6285 has > very extensive Security Considerations. The author has already agreed to incorporate my IESG Evaluation comment, thus: > Security Considerations: > Might it not be better to say something like this?: > "Because this document describes deployment scenarios for RAMS, all security > considerations are specified in the RAMS specifiction [RFC6285]." Barry