From joel.halpern@ericsson.com Thu Jan 31 14:14:59 2013 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 6DAA121F8645; Thu, 31 Jan 2013 14:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoZnBe82blfy; Thu, 31 Jan 2013 14:14:58 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8129621F862A; Thu, 31 Jan 2013 14:14:58 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-04-510aece1cace Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 68.BD.31450.1ECEA015; Thu, 31 Jan 2013 23:14:57 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.004; Thu, 31 Jan 2013 17:14:57 -0500 From: Joel Halpern To: Derek Atkins , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: sec-dir review of draft-ietf-forces-lfb-lib-10.txt Thread-Index: AQHN//7qKZA2lEKlI0S4AYyNngOpn5hj/0Gg Date: Thu, 31 Jan 2013 22:14:56 +0000 Message-ID: <6BCE198E4EAEFC4CAB45D75826EFB0760869A2@eusaamb101.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyuXRPlO7DN1yBBhc+m1u0nbnHarFy0g52 i96Vr5gs9r9/zGgx489EZos/1+4xWXxY+JDFYvqkHnYHDo9d01cweyxZ8pPJY/nXBywezS+e s3h8ufyZzWPdrGWsAWxRXDYpqTmZZalF+nYJXBmHLhsV3BSoaPr4hrWBcRZvFyMnh4SAicT2 R/1MELaYxIV769m6GLk4hASOMEr0NhxihHCWM0o87m1hA6liE9CTWPv+MViHiECWxP2X98GK mAVmM0msn/uIESQhLGAv8eHkUkaIIgeJQ7f+s0PYRhLnj3eAxVkEVCWa32wEs3kFvCUe3/sO NJQDaJuexJsVgSBhTgF9iZXNP8BaGYGu+35qDdheZgFxiVtP5kNdLSCxZM95ZghbVOLl43+s ELayxPc5j1gg6nUkFuz+xAZha0ssW/iaGWKtoMTJmU9YJjCKzUIydhaSlllIWmYhaVnAyLKK kaO0OLUsN93IYBMjMBKPSbDp7mDc89LyEKM0B4uSOG+Q64UAIYH0xJLU7NTUgtSi+KLSnNTi Q4xMHJxSDYwlTm++KS3/OOvS7irhBScWu01bruc2X2RWc932IwErv4uG29ZMOvHy4XWrVPEd 0+Vk3+VUex86J/RKez3blTUGsZJB9k1+euYrk14rcS52t/hmWxb59eL+16+uO6Z33Lv5sv2+ lZ5K0nIDf4XiWqZPMv2RupqWic/XCNaYh0SGHgpwd494sVGJpTgj0VCLuag4EQBHFuGxkgIA AA== X-Mailman-Approved-At: Fri, 01 Feb 2013 04:09:04 -0800 Cc: "wmwang@zjsu.edu.cn" , "ogawa.kentaro@lab.ntt.co.jp" , "chuanhuang_li@zjsu.edu.cn" , "forces-chairs@tools.ietf.org" , "ehalep@ece.upatras.gr" Subject: Re: [secdir] sec-dir review of draft-ietf-forces-lfb-lib-10.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, 31 Jan 2013 22:14:59 -0000 Would a pointer to 5810 (the ForCES Protocol RFC, which defines how these t= hings are manipulated) help? The LFBs here are not different from any other LFBs which affect device beh= avior. Yes, manipulating them can cause problems. That's why the protocol= has security mechanisms. (I probably should have caught that and made sure there was such a referenc= e.) Do we need more than that? Yours, Joel -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com]=20 > Sent: Thursday, January 31, 2013 5:04 PM > To: iesg@ietf.org; secdir@ietf.org > Cc: forces-chairs@tools.ietf.org; wmwang@zjsu.edu.cn;=20 > ehalep@ece.upatras.gr; ogawa.kentaro@lab.ntt.co.jp;=20 > chuanhuang_li@zjsu.edu.cn; Joel Halpern > Subject: sec-dir review of draft-ietf-forces-lfb-lib-10.txt >=20 > Hi, >=20 > I have reviewed this document as part of the security=20 > directorate's ongoing effort to review all IETF documents=20 > being processed by the IESG. These comments were written=20 > primarily for the benefit of the security area directors. =20 > Document editors and WG chairs should treat these comments=20 > just like any other last call comments. >=20 > This document defines basic classes of Logical Function=20 > Blocks (LFBs) > used in the Forwarding and Control Element Separation=20 > (ForCES). The > basic LFB classes are defined according to ForCES FE model=20 > and ForCES > protocol specifications, and are scoped to meet requirements of > typical router functions and considered as the basic LFB=20 > library for > ForCES. The library includes the descriptions of the LFBs and the > XML definitions. >=20 > The Security Considerations section offloads itself to RFC3746. >=20 > It is unclear to me if any of the new functions defined in=20 > the LFB need any additional authentication or authorization,=20 > and if so I do not see how that would be added. >=20 > -derek >=20 > --=20 > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > = From derek@ihtfp.com Fri Feb 1 07:26:42 2013 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 A108321E8041; Fri, 1 Feb 2013 07:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkOxhs786y2w; Fri, 1 Feb 2013 07:26:41 -0800 (PST) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id 7008C21E803D; Fri, 1 Feb 2013 07:26:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 625252602B1; Fri, 1 Feb 2013 10:26:38 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 15126-06; Fri, 1 Feb 2013 10:26:30 -0500 (EST) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (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 BDC8A260211; Fri, 1 Feb 2013 10:26:30 -0500 (EST) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id r11FQMbo019399; Fri, 1 Feb 2013 10:26:22 -0500 From: Derek Atkins To: Joel Halpern References: <6BCE198E4EAEFC4CAB45D75826EFB0760869A2@eusaamb101.ericsson.se> Date: Fri, 01 Feb 2013 10:26:21 -0500 In-Reply-To: <6BCE198E4EAEFC4CAB45D75826EFB0760869A2@eusaamb101.ericsson.se> (Joel Halpern's message of "Thu, 31 Jan 2013 22:14:56 +0000") 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: "secdir@ietf.org" , "ogawa.kentaro@lab.ntt.co.jp" , "chuanhuang_li@zjsu.edu.cn" , "ehalep@ece.upatras.gr" , "forces-chairs@tools.ietf.org" , "iesg@ietf.org" , "wmwang@zjsu.edu.cn" Subject: Re: [secdir] sec-dir review of draft-ietf-forces-lfb-lib-10.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: Fri, 01 Feb 2013 15:26:43 -0000 Yes, I think that would improve it. I don't think you need more. Thanks! -derek Joel Halpern writes: > Would a pointer to 5810 (the ForCES Protocol RFC, which defines how these things are manipulated) help? > The LFBs here are not different from any other LFBs which affect device behavior. Yes, manipulating them can cause problems. That's why the protocol has security mechanisms. > (I probably should have caught that and made sure there was such a reference.) > Do we need more than that? > > Yours, > Joel > > -----Original Message----- >> From: Derek Atkins [mailto:derek@ihtfp.com] >> Sent: Thursday, January 31, 2013 5:04 PM >> To: iesg@ietf.org; secdir@ietf.org >> Cc: forces-chairs@tools.ietf.org; wmwang@zjsu.edu.cn; >> ehalep@ece.upatras.gr; ogawa.kentaro@lab.ntt.co.jp; >> chuanhuang_li@zjsu.edu.cn; Joel Halpern >> Subject: sec-dir review of draft-ietf-forces-lfb-lib-10.txt >> >> Hi, >> >> I have reviewed this document as part of the security >> directorate's ongoing effort to review all IETF documents >> being processed by the IESG. These comments were written >> primarily for the benefit of the security area directors. >> Document editors and WG chairs should treat these comments >> just like any other last call comments. >> >> This document defines basic classes of Logical Function >> Blocks (LFBs) >> used in the Forwarding and Control Element Separation >> (ForCES). The >> basic LFB classes are defined according to ForCES FE model >> and ForCES >> protocol specifications, and are scoped to meet requirements of >> typical router functions and considered as the basic LFB >> library for >> ForCES. The library includes the descriptions of the LFBs and the >> XML definitions. >> >> The Security Considerations section offloads itself to RFC3746. >> >> It is unclear to me if any of the new functions defined in >> the LFB need any additional authentication or authorization, >> and if so I do not see how that would be added. >> >> -derek >> >> -- >> Derek Atkins 617-623-3745 >> derek@ihtfp.com www.ihtfp.com >> Computer and Internet Security Consultant >> > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From clonvick@cisco.com Sat Feb 2 03:43:14 2013 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 6BD5121F900E; Sat, 2 Feb 2013 03:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFFM+XNKwZ9v; Sat, 2 Feb 2013 03:43:13 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A6A0F21F8D8F; Sat, 2 Feb 2013 03:43:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1541; q=dns/txt; s=iport; t=1359805393; x=1361014993; h=date:from:to:subject:message-id:mime-version; bh=Y5DASA6fHxusEieINR9SrRW3+A/O0+mbxDhJojshTA0=; b=NjtOsZ1+M0/rdBY7sIH0cYXKQSuWG4b6N8XAoo6irgSOlvz6cVdWEKIZ VyVOURYtPKNS7R5V8ixBf6p96ASAV+Cg6QBweupVgazsoq1Tig2d8S7nq +jahsBEbZrlBljrh7/aM1JKFsfLkkVTk7yIXXvPZuqtoGPTjwpsvPnBIT 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIr6DFGrRDoI/2dsb2JhbABFvzgWc4JeAoF+iCLCJ5FSA4hmngqDHQ X-IronPort-AV: E=Sophos;i="4.84,590,1355097600"; d="scan'208";a="70244735" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 02 Feb 2013 11:43:07 +0000 Received: from sjc-xdm-114 (sjc-xdm-114.cisco.com [171.71.188.119]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r12Bh65d012385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Feb 2013 11:43:06 GMT Date: Sat, 2 Feb 2013 03:43:06 -0800 (PST) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-ietf-geopriv-dhcp-lbyr-uri-option.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [secdir] secdir review of draft-ietf-geopriv-dhcp-lbyr-uri-option-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 11:43:14 -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 is actually a re-review of this document. It appears that James addressed most of my editorial comments from that review and I'm happy with the results. James has separated out the components of the option described in -15 (the one I had previously reviewed) into two options in this document. Overall, I see where he's going with this and again I have no overall problems. Some editorial things: - I would like to see some discussion of the potential misuse of the Valid-For option in the Security Considerations section. This could be a simple pointer to section 2.5 but I do feel that should be explicitly called out in the Security Considerations. - I would like to see some discussion of the expected bounds of the Valid-For option value. There is no guidance on what could or should be provided by the client, nor on what should be expected by the server. This just makes me a bit nervous. :-) - I couldn't find any reason why the components needed to be separated into two different options. I'm sure that there is a good reason for it so having an explanation would help. If it's in there, then I just missed it. Best regards, Chris From tuexen@fh-muenster.de Sat Feb 2 09:29:23 2013 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 2407921F84E6; Sat, 2 Feb 2013 09:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQRXbYMjUKmj; Sat, 2 Feb 2013 09:29:21 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id F32DA21F8605; Sat, 2 Feb 2013 09:29:19 -0800 (PST) Received: from [192.168.1.101] (p508FA191.dip.t-dialin.net [80.143.161.145]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 501211C0C0692; Sat, 2 Feb 2013 18:29:17 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <20746.18802.364266.587982@fireball.kivinen.iki.fi> Date: Sat, 2 Feb 2013 18:29:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0A880226-D910-403B-8D17-1AB928612E36@fh-muenster.de> References: <20718.54159.713629.567812@fireball.kivinen.iki.fi> <8D58A3AD-A276-4AA6-B454-E3D07AB7C90A@fh-muenster.de> <20743.57390.456600.844778@fireball.kivinen.iki.fi> <2D128C1C-ADE8-43CB-990C-56CB7E0C327C@fh-muenster.de> <20746.18802.364266.587982@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1283) Cc: draft-ietf-tsvwg-sctp-udp-encaps.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-tsvwg-sctp-udp-encaps-07.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: Sat, 02 Feb 2013 17:29:23 -0000 On Jan 31, 2013, at 11:37 AM, Tero Kivinen wrote: > Michael Tuexen writes: >>> It might be good to say that in the document, i.e. that it is out of >>> scope of this document.=20 >>=20 >> What about adding >> Please note that this document does not provide all techniques = necessary >> for building a complete NAT-capable application using SCTP. This = document >> focuses on the functionality required within the SCTP stack and = making >> this available via an API. >> to the Abstract? >=20 > I think it would be better to add more explicit notice what is left > outside of the scope.=20 So what about adding in addition to the above: It does not cover mechanism to determine whether UDP encapsulation is required to reach the peer and, if UDP encapsulation is used, which = remote UDP port number can be used. >=20 >>>>> Also what if host A and B already have one SCTP connection, and = now >>>>> host B wants to create another, do host B reuse the same UDP >>>>> destination port number for host A that was used for the already >>>>> existing SCTP connection between them? The section 4.1 says that = UDP >>>>> port numbers are stored per destination address per SCTP = association, >>>>> so that would indicate no. >>>>=20 >>>> As stated in the document, each stack uses a single port number >>>> as the destination address of all incoming packets. >>>=20 >>> The document also says: >>>=20 >>> Using a single UDP encapsulation port number per host is not >>> possible if the SCTP stack is implemented as part of an >>> application. >>>=20 >>> which indicates that using multiple UDP port numbers is also an >>> option. Or is implementing SCTP stack as appliction out of scope = too? >>> Section 3.1 seems to indicate that it is not out of scope. >>=20 >> No, you can implement SCTP in the kernel (which means that the stack >> is unique on the host) or in the application (which means there >> can me multiple, one stack per association for example). >=20 > That was my understanding, and thats why it was bit odd to see text > that says that you have one UDP port only, and it is not possible to > do that if SCTP stack is in the application. The above text was changed while addressing other IESG comments to Using a single UDP encapsulation port number per host is not possible if the SCTP stack is implemented as part of each application, and there are multiple applications. Does that make things clearer? >=20 > This seems to give bit mixed signals what is supported and what is > not.=20 >=20 >>> =46rom the section 3.1 and 4.1 it is not really clear what needs to = be >>> supported. If I have understood correctly that if SCTP is = implemented >>> in kernel then we use one UDP port for the whole host, but if SCTP = is >>> implemented by the application then each application might have >>> different UDP port, i.e. there will be multiple UDP SCTP = encapsulation >>> ports in the host. >> Correct. >>>=20 >>> I.e. if host A is connected to two different applications on host B. >>> Host B is such host that it does not support SCTP on kernel, the = SCTP >>> is implemented on the application itself, and that means each >>> application has separate UDP encapsulation port. Now what you said >>> before I assume that it is outside the scope of this document for = host >>> A know how to connect to host B, i.e. how to get the UDP port = numbers >>> where to connect, and also whether to use the UDP encapsulation at >>> all? >> Correct. Finding the remote UDP number for the initial packets is >> out of scope. >=20 > Which is again one thing that should be explictly mentioned. It makes > hard to understand what this document is for, as you would expect this > kind of things to be solved here, or at least pointed to a pointer > telling where they are solved, but this document is silent about the > issue. OK, I think you are expecting a complete NAT traversal solution provide in the document whereas the document only addresses how to encapsulate SCTP in UDP packets and how to control this via the socket API. I hope I made the scope clearer by adding the above sentence to the abstract. >>> Is there any work ongoing on this? I.e. how is this going to be = solved >>> in practice? Or is it assumed that the SCTP applications which do = not >>> have direct access to IP-layer, which need to use UDP encapsulation >>> because of that, are always only initiators, i.e. nobody ever = connects >>> to them, they always initiate the connection to the known services? >> As said above, a complete solution is out of scope of this document. >=20 > That is fine, but it should mention what is out of scope.=20 Hopefully addressed by the suggested change. >=20 >>>>> In some cases also the IP-address might change, >>>>> i.e. if the NAT box is rebooted or its connection table is = cleared, >>>>> and the NAT box have multiple IP-addresses, it is completly = possible >>>>> that the NAT mapping changes so that IP-address and UDP port = number >>>>> both change. I am not familiar enough with SCTP to know whether = this >>>>> causes problem with SCTP, i.e. whether it is default SCTP rules to = use >>>>> the last seen IP-address when sending reply or what. >>>>=20 >>>> The method described in the document does NOT cover changing the >>>> address. If you want to handle that, you need to use the address >>>> reconfiguration extension (RFC 5061). >>>=20 >>> Then you need to say that in the draft. Note, that hosts A and B do >>=20 >> It is mentioned in the last paragraph of section 4.7 >=20 > I would be very suprised if someone can really combine RFC5061 and > this document to get interoperable implementation with just that one > reference, in the cases where the NAT box is rebooted and the outer > IP-addresses change because of that. Hmmm. This document only covers the UDP encapsulation part. It is not intended to extend RFC 5061. >=20 >>> not have any way of knowing when the IP-address changes, or whether = it >>> is going to change. For normal TCP (and most likely also SCTP) this >>=20 >> Well, that depends. >=20 > No, it really does not. We are not talking about local IP address > changes, we are talking the NAT box rebooting and loosing state, and > allocating new IP address for the UDP encapsulated SCTP packets. The > local host does not know anything about that.=20 OK. Let us consider this case. >=20 >> If the address change is local on the host, SCTP kernel = implementations (at >> least FreeBSD and Linux) will get notified when addresses are added = or >> removed. For example, on FreeBSD you can add an address using >> ifconfig and the address changes will happen on all association which = use >> a wildcard bound SCTP socket, it is allowed system-wide via the >> net.inet.sctp.auto_asconf sysctl and the application didn't disabled >> it via the SCTP_AUTO_ASCONF socket option. >=20 > We are not talking about local changes. >=20 >> On the other hand, if the address change is not local, the peer will >> respond to a packet with an ABORT chunk having the T-bit set. This >> could be interpreted as an indication of an address change.=20 >=20 > Ok, so this is already handled in the SCTP internally, i.e. remote > node notices that other end changed IP-address and indicates that to > the other end. Mentioning this in the draft would most likely help for > implementors to understand what they need to do in this cases. See the suggestion below. >=20 > NAT boxes loosing state is something that should be explained in the > draft, as that is quite common situation and if this is supposed to > work on environments where there are NATs, then what happens when NAT > box looses state should be explained. >=20 >>> IP-address change will usually result the connection to be reset, as >>> the NAT box does not have the mapping for the connection anymore, = but >>> for UDP that does not happen. The NAT box will just create new >>> mapping. >> Which is fine. >>>=20 >>> I.e. the situation is as follows. Host A is behind NAT, and talks to >>> host B using UDP encapsulated SCTP. Now the NAT box is rebooted, and >>> it looses state. When Host A sends next UDP encapsulated SCTP packet >>> to Host B that UDP packet might get new source IP address by the NAT >>> box. What should happen at that point? >> As described above, host B will respond with an ABORT chunk and host = A >> can use this as an indication that it has to update its address. >> So it can send a ASCONF chunk adding the wildcard address and = removing >> the wildcard address which will result in the possibility to continue >> the association. >=20 > Adding section explaining the thing above would most likely help to > understand that this issue needs to be handled in the implementations. > This for example makes it quite clear that using udp encapsulation > through NAT without supporting RFC 5061 is just not going to work.=20 But that is not true. If you are using single-homed SCTP association and you don't want to survive a reboot of NAT boxes, you don't need RFC 5061. This setup is similar to TCP. Using an ABORT as an indication of a NAT having rebooted and the appropriate behavior is currently not specified and only needs to be specified if you want to make SCTP/UDP resistant against NAT reboots. Personally, I didn't see this within the scope of this ID, but if the IESG thinks that this should be the case, we can add this. >=20 >>> Should the SCTP implementation notice that IP-address of the >>> association has changed, and send some kind of reset or what? Or = does >>> the SCTP implementation just drop all packets because they do not >>> match association and then connection is dropped after timeout? >>>=20 >>> How do you plan to use RFC 5061 to solve that situation? I do not = know >>> enough of RFC 5061 to say how it can be used to solve this kind of >>> situation, where the peer A whose IP-address was changed does not = even >>> know that his IP-address was changed. >> I hope the above makes it clearer. We can add at the end of section = 4.7 >> text like: >>=20 >> If an SCTP end-point receives an ABORT with the T-bit set, it MAY >> use this as an indication that the addresses seen by the peer might >> have changed. >=20 > I would like think it would be better to add new section explaining > how this is supposed to interact with NAT boxes loosing state. I.e. > the text what you explained above to me. Until now I had only assumed > that if I would be implementing that, I do not need to care about > RFC5061 unless I want to support IP-addresses changing. After your > explination it is clear that all implementations who want to work > through NATs do need to support it. OK, if the IESG want this, it can be added. This would require: * Add specific exception for the reception of ABORTs with the T-bit set. Handle this as an indication that a NAT-box has rebooted. * Add an example showing the ASCONF message exchange which is used if the end-point thinks that a NAT-box lost its state. >=20 >>> Of course as the NAT mappings are usually remote IP + remote port + >>> protocol + NAT IP + NAT port, this means that changes for host C to >>> get exactly same 5-tuple are small... On the other hand host C can >>> most likely know remote IP and remote port as they are well known >>> based on the service. The NAT IP is most likely going to be same all >>> the time, so only thing host C needs to be doing is to cause NAT to >>> loose state (i.e. cause it to either reboot, or run out of = mappings), >>> and then start filling up the NAT mappings until it gets the NAT = port >>> host A used earlier. >>>=20 >>> One way to cause NAT to loose state, is to start flooding NAT with = new >>> UDP packets each destinationed to remote host + port and having >>> UDP different source port. NAT will allocate new NAT port for each = of >>> them until it runs out of port numbers, in which case it starts >>> reusing port numbers. Now depending on the NAT implementation, flood >>> guarding, SCTP heartbeat intervals etc NAT might reuse the host A's >>> port in which case host C managed to get the session. >>=20 >> Yes, that is possible. What can the attacker do? The attacker can't >> insert any DATA or SACK chunks, since it would have to guess the >> V-tag. However, the attacker can ABORT the association with sending >> an ABORT with the V-tag set. But this is not better or worse than >> attacking the NAT box. So most likely the attacker can receive an >> RWND of user data. If sent unprotected, I would assume that his is >> acceptable. Using DTLS/SCTP would protect against it. >=20 > It can do exactly same things it can do in the other case where the IP > address got reused. It will receive all packets that were supposed to > be received by original host A, so it can see all traffic going to > host A. As there is no cryptographic checksums there, it can add data > to the packets it receive and might send them to host A depending on > the network layout. At least as far as I know. Sure, if the attacker can forward the packets to the end-point from which it took over the address, the attacker is a true = man-in-the-middle. >=20 >>> Which ways those HEARTBEAT messages are sent? For NAT mappings to = stay >>> alive, the messages quite often needs to be coming from inside of = the >>> NAT, i.e. from the host which is behind the NAT, and if both ends = are >>> behind NAT, they need to be coming from both ends. Do HEARTBEATs = cover >>> that possibility. Also some NAT boxes are known to require as small >>> keepalive intervals as 20 seconds... How often do you send = HEARTBEATS? >> Both sides send HEARTBEATs, the standard time between them is 30 = seconds >> plus RTO plus/minus 50%. However, the application can change the 30 = seconds >> to other values using the standard socket API. >=20 > Ok, so that is ok.=20 >=20 >>> So is having both ends behind NAT out of scope? This should then be >>> mentioned in section 3.2. Note, that similar problems also arise = when >>> you need to connect to host which is behind NAT, i.e. even if it is >>> only one host behind NAT, but if the connection is coming from the >>> outside, you have similar problems than what you have when both ends >>> are behind NAT. >>=20 >> I think the point is that finding the remote port number for initial >> packets is out of scope of the this document. >=20 > The dynamic port fixup is UNSAF operation, already described in the > draft. >=20 > The use if RFC5061 with wildcard addresses is similar operation. Both > of those are solutions which get around the fact that peers do not > know the actual addresses, i.e. are trying to "determine or fix the > addresses by which it is known to another endpoint". >=20 > UNSAF operations are not only the cases where you try to find out the > initial address, it covers also all cases where the protocol tries to > fix things caused by NATs. =46rom RFC3424: >=20 > o proposed workarounds include the use of "ping"-like address > discovery requests sent from the UNSAF client (initiator) to the > UNSAF server (listener), to which the listener responds with the > transport address of the initiator - in the address realm of the > listener. However, with connection-less transports, e.g. UDP, > IPsec ESP, etc., an UNSAF process must take care to react to > changes in NAT bindings for a given application flow, since it = may > change unpredictably. >=20 > just covers this loosing NAT bindings and the: >=20 > o limiting the scope to outbound requests for service (or service > initiation) in order to prevent unacceptable security exposures. >=20 > Is just what this document does, i.e. limits the scope so that only > outbound ocnnections are allowed or similar constraints, but does not > mention what those constraints are. I don't think we are limiting the scope to outbound associations. >=20 > What you are trying to say is that UNSAF considerations do not apply > as you have scoped them out, but that is exactly one UNSAF > consideration. In real world case those problems do need to be solved, > and this document is not really that useful if it cannot be used in > real world... I'm not sure what you are requesting here... An attacker can only change the UDP port number if he provides an SCTP packet which can be mapped to the association. This requires that the V-tag is correct. This way this mechanism is protected against blind attackers the same way as the base protocol is. So in summary I see two issues: (1) Add text how to make SCTP/UDP resistant against state loss of NAT = boxes (2) Potential insufficient protection against attackers trying to change the remote UDP encapsulation port. Is this correct? For addressing (1), text can be added if wanted by the IESG. I'm not completely understanding issue (2). So it would be helpful if you could describe the potential attack a bit more. Best regards Michael=20 > --=20 > kivinen@iki.fi >=20 From kivinen@iki.fi Mon Feb 4 05:24:56 2013 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 5363521F859D; Mon, 4 Feb 2013 05:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrHZQZsx9Mic; Mon, 4 Feb 2013 05:24:55 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9B93021F8599; Mon, 4 Feb 2013 05:24:54 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r14DOgUo013533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2013 15:24:42 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r14DOfYq011625; Mon, 4 Feb 2013 15:24:41 +0200 (EET) 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: <20751.46745.772166.652412@fireball.kivinen.iki.fi> Date: Mon, 4 Feb 2013 15:24:41 +0200 From: Tero Kivinen To: Michael Tuexen In-Reply-To: <0A880226-D910-403B-8D17-1AB928612E36@fh-muenster.de> References: <20718.54159.713629.567812@fireball.kivinen.iki.fi> <8D58A3AD-A276-4AA6-B454-E3D07AB7C90A@fh-muenster.de> <20743.57390.456600.844778@fireball.kivinen.iki.fi> <2D128C1C-ADE8-43CB-990C-56CB7E0C327C@fh-muenster.de> <20746.18802.364266.587982@fireball.kivinen.iki.fi> <0A880226-D910-403B-8D17-1AB928612E36@fh-muenster.de> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 46 min X-Total-Time: 47 min Cc: draft-ietf-tsvwg-sctp-udp-encaps.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-tsvwg-sctp-udp-encaps-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 13:24:56 -0000 Michael Tuexen writes: > > Michael Tuexen writes: > >>> It might be good to say that in the document, i.e. that it is out of > >>> scope of this document. > >> > >> What about adding > >> Please note that this document does not provide all techniques necessary > >> for building a complete NAT-capable application using SCTP. This document > >> focuses on the functionality required within the SCTP stack and making > >> this available via an API. > >> to the Abstract? > > > > I think it would be better to add more explicit notice what is left > > outside of the scope. > > So what about adding in addition to the above: > > It does not cover mechanism to determine whether UDP encapsulation is > required to reach the peer and, if UDP encapsulation is used, which remote > UDP port number can be used. That is better. But see below. > > That was my understanding, and thats why it was bit odd to see text > > that says that you have one UDP port only, and it is not possible to > > do that if SCTP stack is in the application. > > The above text was changed while addressing other IESG comments to > > Using a single UDP encapsulation port number per host is not possible > if the SCTP stack is implemented as part of each application, > and there are multiple applications. > > Does that make things clearer? It makes it bit clearer, but there is still the same problem. It is really hard to try to understand what should be done when the document just says "it is not possible". What is implementor trying to implement this document doing when he is trying to implement SCTP as part of application. He does not have any idea whether there are going to be multiple applications each supporting SCTP. How is he trying to solve this issue. This document seems to be only covering some small technical bits, but the overall architecture picture is completely left out, which makes it very hard to make interoperable implementations. If one implementor reads the text above and selects solution A and another implementor selects solution B to the same problem they are not going to interoperate. It almost seems like this is missing the scenarios and uses cases document. In the UDP Encapsulation of IPsec ESP Packets (RFC3948) we had RFC 3715 which covered the use cases and RFC3947 (how the negotiation is done) for example said: This document defines a protocol that will work even if both ends are behind NAT, but the process of how to locate the other end is out of the scope of this document. In one scenario, the responder is behind a static host NAT (only one responder per IP, as there is no way to use any destination ports other than 500/4500). That is, it is known by the configuration. I.e it said it is out of scope of the document to explain how it works specifically, but gives one example which can be implemented and supported. > > Which is again one thing that should be explictly mentioned. It makes > > hard to understand what this document is for, as you would expect this > > kind of things to be solved here, or at least pointed to a pointer > > telling where they are solved, but this document is silent about the > > issue. > > OK, I think you are expecting a complete NAT traversal solution provide > in the document whereas the document only addresses how to encapsulate > SCTP in UDP packets and how to control this via the socket API. Mostly yes. Or at least I would expect to see pointers to other documents explaining the architecture and solutions for the complete NAT traversal solution. If you do not know what kind of architecture you are aiming for and what kind of use cases you have, it is very hard to get the technical details right. It seems that you most likely do have an architecture in your mind, and the current document is designed to solve the issues coming from that architecture, but it would make things much better if the architecture is written down before the technical bits are published as RFC. > I hope I made the scope clearer by adding the above sentence to the > abstract. Scope might be clearer, but that does not solve the issue what I have with the document, i.e. it is very hard to evaluate the proposal when I do not know the architecture. > But that is not true. If you are using single-homed SCTP association > and you don't want to survive a reboot of NAT boxes, you don't need > RFC 5061. This setup is similar to TCP. > Using an ABORT as an indication of a NAT having rebooted and the > appropriate behavior is currently not specified and only needs to > be specified if you want to make SCTP/UDP resistant against NAT > reboots. Personally, I didn't see this within the scope of this > ID, but if the IESG thinks that this should be the case, we > can add this. Whether that is added here or as separate protocol is not really an issue, the problem is that for the implementor implementing or the reader of this document does not have any idea how many this kind of details have been omitted from this document. It would be fine to say that this document only scopes the case where the SCTP initiator is behind NAT and the responder always uses the one fixed port (which might be known either from the configuration or some protocol designed later) when connecting. Then it would be clear what kind of situations are covered. Now it seems to be that this document might allow all kind of things but nothing is specified here so it makes it very hard for implementor to know what things needs to be implemented. For protocol design point it might be nice to design protocol as open as possible, and leave all details open as that allows all kind of uses for the protocol. As an implementor implementing such specification is really hard. The implementor needs to implement all corner cases which were left out from the specification, and the implementor needs to decide how to act when X happens even when that was not specified in the specifications. Now multiple implementors will most likely do different things when X happens, and then the implementations are not interoperable. > > I would like think it would be better to add new section explaining > > how this is supposed to interact with NAT boxes loosing state. I.e. > > the text what you explained above to me. Until now I had only assumed > > that if I would be implementing that, I do not need to care about > > RFC5061 unless I want to support IP-addresses changing. After your > > explination it is clear that all implementations who want to work > > through NATs do need to support it. > > OK, if the IESG want this, it can be added. > This would require: > * Add specific exception for the reception of ABORTs with the T-bit > set. Handle this as an indication that a NAT-box has rebooted. > * Add an example showing the ASCONF message exchange which is used if > the end-point thinks that a NAT-box lost its state. I think adding that would make document more usable, and would allow making interoperable implementations already based on this document, without the need of another document explaining how this is used in real world (or interop event where implementors decide and agree on the cases, and then those decisions are left as folklore in the industry, and there is no written description about it). > > Is just what this document does, i.e. limits the scope so that only > > outbound ocnnections are allowed or similar constraints, but does not > > mention what those constraints are. > > I don't think we are limiting the scope to outbound associations. As I said as I do not know what is the scope of the document, it is really hard to say what is needed... > > What you are trying to say is that UNSAF considerations do not apply > > as you have scoped them out, but that is exactly one UNSAF > > consideration. In real world case those problems do need to be solved, > > and this document is not really that useful if it cannot be used in > > real world... > > I'm not sure what you are requesting here... UNSAF considerations is separate issue to the other issues we have there. > An attacker can only change the UDP port number if he provides an > SCTP packet which can be mapped to the association. This requires > that the V-tag is correct. This way this mechanism is protected > against blind attackers the same way as the base protocol is. > > So in summary I see two issues: > (1) Add text how to make SCTP/UDP resistant against state loss of NAT boxes > (2) Potential insufficient protection against attackers trying to > change the remote UDP encapsulation port. > Is this correct? > > For addressing (1), text can be added if wanted by the IESG. I am not sure the (1) is the only thing that needs to be added. It is the only one I could immediately think of based on my limited guesswork what the scope of the document is. If the scope would be clear there might be other similar issues, but without knowing what is the actual scope of the document I cannot be sure. For exmaple you mentioned that the scope is not limited to only outbound associations. That indicates there needs to be some way for the servers to punch holes to the NAT so the initial incoming connection packets comes to the host. Those hole punching mechanisms are now part of the security properties of the solution, i.e. if there is no authentication or anything, i.e. anybody behind the NAT box can punch or modify those holes as they like, then that would allow trivial way to redirect traffic to attacker. > I'm not completely understanding issue (2). So it would be helpful > if you could describe the potential attack a bit more. It is really hard to describe the attacks when you do not know the architecture of the system (and I do not have enough understanding of the SCTP). I can try to invent couple different attacks, but all of those would be depended how the bits which are left out of this document is done. But before going to those it would be much better to know what is the scope of this document. -- kivinen@iki.fi From tuexen@fh-muenster.de Mon Feb 4 06:31:14 2013 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 7144D21F861F; Mon, 4 Feb 2013 06:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9rXYFgWsAUR; Mon, 4 Feb 2013 06:31:13 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id AB3A321F860A; Mon, 4 Feb 2013 06:31:12 -0800 (PST) Received: from [192.168.1.101] (p508FA234.dip.t-dialin.net [80.143.162.52]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id D1B401C0C069E; Mon, 4 Feb 2013 15:31:10 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <20751.46745.772166.652412@fireball.kivinen.iki.fi> Date: Mon, 4 Feb 2013 15:31:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20718.54159.713629.567812@fireball.kivinen.iki.fi> <8D58A3AD-A276-4AA6-B454-E3D07AB7C90A@fh-muenster.de> <20743.57390.456600.844778@fireball.kivinen.iki.fi> <2D128C1C-ADE8-43CB-990C-56CB7E0C327C@fh-muenster.de> <20746.18802.364266.587982@fireball.kivinen.iki.fi> <0A880226-D910-403B-8D17-1AB928612E36@fh-muenster.de> <20751.46745.772166.652412@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1283) Cc: draft-ietf-tsvwg-sctp-udp-encaps.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-tsvwg-sctp-udp-encaps-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 14:31:14 -0000 On Feb 4, 2013, at 2:24 PM, Tero Kivinen wrote: > Michael Tuexen writes: >>> Michael Tuexen writes: >>>>> It might be good to say that in the document, i.e. that it is out = of >>>>> scope of this document.=20 >>>>=20 >>>> What about adding >>>> Please note that this document does not provide all techniques = necessary >>>> for building a complete NAT-capable application using SCTP. This = document >>>> focuses on the functionality required within the SCTP stack and = making >>>> this available via an API. >>>> to the Abstract? >>>=20 >>> I think it would be better to add more explicit notice what is left >>> outside of the scope.=20 >>=20 >> So what about adding in addition to the above: >>=20 >> It does not cover mechanism to determine whether UDP encapsulation is >> required to reach the peer and, if UDP encapsulation is used, which = remote >> UDP port number can be used. >=20 > That is better. But see below. >=20 >>> That was my understanding, and thats why it was bit odd to see text >>> that says that you have one UDP port only, and it is not possible to >>> do that if SCTP stack is in the application. >>=20 >> The above text was changed while addressing other IESG comments to >>=20 >> Using a single UDP encapsulation port number per host is not possible >> if the SCTP stack is implemented as part of each application, >> and there are multiple applications. >>=20 >> Does that make things clearer? >=20 > It makes it bit clearer, but there is still the same problem. It is > really hard to try to understand what should be done when the document > just says "it is not possible". What is implementor trying to > implement this document doing when he is trying to implement SCTP as > part of application. He does not have any idea whether there are going > to be multiple applications each supporting SCTP. How is he trying to > solve this issue. He simply can't assume that he is able to bind a particular UDP port. >=20 > This document seems to be only covering some small technical bits, but > the overall architecture picture is completely left out, which makes > it very hard to make interoperable implementations. If one implementor > reads the text above and selects solution A and another implementor > selects solution B to the same problem they are not going to > interoperate. =46rom my understanding this depends on the scope. The scope of the document is limited to the SCTP stack. This has been implemented in a kernel stack (FreeBSD) and is also available in a userland stack based on the FreeBSD kernel stack. However, it does not cover how to use the API provided and therefore how to build a complete application. >=20 > It almost seems like this is missing the scenarios and uses cases > document. In the UDP Encapsulation of IPsec ESP Packets (RFC3948) we > had RFC 3715 which covered the use cases and RFC3947 (how the > negotiation is done) for example said: >=20 > This document defines a protocol that will work even if both ends = are > behind NAT, but the process of how to locate the other end is out of > the scope of this document. In one scenario, the responder is = behind > a static host NAT (only one responder per IP, as there is no way to > use any destination ports other than 500/4500). That is, it is = known > by the configuration. >=20 > I.e it said it is out of scope of the document to explain how it > works specifically, but gives one example which can be implemented and > supported.=20 >=20 >>> Which is again one thing that should be explictly mentioned. It = makes >>> hard to understand what this document is for, as you would expect = this >>> kind of things to be solved here, or at least pointed to a pointer >>> telling where they are solved, but this document is silent about the >>> issue. >>=20 >> OK, I think you are expecting a complete NAT traversal solution = provide >> in the document whereas the document only addresses how to = encapsulate >> SCTP in UDP packets and how to control this via the socket API. >=20 > Mostly yes. Or at least I would expect to see pointers to other > documents explaining the architecture and solutions for the complete > NAT traversal solution. >=20 > If you do not know what kind of architecture you are aiming for and > what kind of use cases you have, it is very hard to get the technical > details right. It seems that you most likely do have an architecture > in your mind, and the current document is designed to solve the issues > coming from that architecture, but it would make things much better if > the architecture is written down before the technical bits are > published as RFC.=20 I think that the document describes the SCTP related procedures and an API to allow applications to do any kind of negotiation or even none (just assuming 9899 at the server side). >=20 >> I hope I made the scope clearer by adding the above sentence to the >> abstract. >=20 > Scope might be clearer, but that does not solve the issue what I have > with the document, i.e. it is very hard to evaluate the proposal when > I do not know the architecture.=20 If the IESG thinks it makes more sense to develop a technique for encapsulating SCTP in UDP within a particular application, which also covers the negotiation of the encapsulation, that is fine. That would give a complete, application specific solution. >=20 >> But that is not true. If you are using single-homed SCTP association >> and you don't want to survive a reboot of NAT boxes, you don't need >> RFC 5061. This setup is similar to TCP. >> Using an ABORT as an indication of a NAT having rebooted and the >> appropriate behavior is currently not specified and only needs to >> be specified if you want to make SCTP/UDP resistant against NAT >> reboots. Personally, I didn't see this within the scope of this >> ID, but if the IESG thinks that this should be the case, we >> can add this. >=20 > Whether that is added here or as separate protocol is not really an > issue, the problem is that for the implementor implementing or the > reader of this document does not have any idea how many this kind of > details have been omitted from this document. >=20 > It would be fine to say that this document only scopes the case where > the SCTP initiator is behind NAT and the responder always uses the one > fixed port (which might be known either from the configuration or some > protocol designed later) when connecting. >=20 > Then it would be clear what kind of situations are covered. Now it > seems to be that this document might allow all kind of things but > nothing is specified here so it makes it very hard for implementor to > know what things needs to be implemented. Hmm. So you would prefer to limit the scope to the above (which is fine with me), but that would not change the provided mechanism in any way and this mechanism can be used in a wider scope. >=20 > For protocol design point it might be nice to design protocol as open > as possible, and leave all details open as that allows all kind of > uses for the protocol. As an implementor implementing such > specification is really hard. The implementor needs to implement all > corner cases which were left out from the specification, and the > implementor needs to decide how to act when X happens even when that > was not specified in the specifications. Now multiple implementors = will > most likely do different things when X happens, and then the > implementations are not interoperable.=20 Hmm. We have implemented this extension and we think that the document clearly describes what you do *in* in the SCTP stack. At least I didn't find it hard to implement it (neither does Randall, I guess). >=20 >>> I would like think it would be better to add new section explaining >>> how this is supposed to interact with NAT boxes loosing state. I.e. >>> the text what you explained above to me. Until now I had only = assumed >>> that if I would be implementing that, I do not need to care about >>> RFC5061 unless I want to support IP-addresses changing. After your >>> explination it is clear that all implementations who want to work >>> through NATs do need to support it. >>=20 >> OK, if the IESG want this, it can be added. >> This would require: >> * Add specific exception for the reception of ABORTs with the T-bit >> set. Handle this as an indication that a NAT-box has rebooted. >> * Add an example showing the ASCONF message exchange which is used if >> the end-point thinks that a NAT-box lost its state. >=20 > I think adding that would make document more usable, and would allow > making interoperable implementations already based on this document, > without the need of another document explaining how this is used in > real world (or interop event where implementors decide and agree on > the cases, and then those decisions are left as folklore in the > industry, and there is no written description about it).=20 OK. We can add that. However this only makes sense if the document can proceed. If the IESG also requires to add the application level NAT traversal stuff, then this becomes much more complex. I'm not sure think that TSVWG has the expertise for that task. >>> Is just what this document does, i.e. limits the scope so that only >>> outbound ocnnections are allowed or similar constraints, but does = not >>> mention what those constraints are. >>=20 >> I don't think we are limiting the scope to outbound associations. >=20 > As I said as I do not know what is the scope of the document, it is > really hard to say what is needed...=20 >=20 >>> What you are trying to say is that UNSAF considerations do not apply >>> as you have scoped them out, but that is exactly one UNSAF >>> consideration. In real world case those problems do need to be = solved, >>> and this document is not really that useful if it cannot be used in >>> real world... >>=20 >> I'm not sure what you are requesting here... >=20 > UNSAF considerations is separate issue to the other issues we have > there.=20 >=20 >> An attacker can only change the UDP port number if he provides an >> SCTP packet which can be mapped to the association. This requires >> that the V-tag is correct. This way this mechanism is protected >> against blind attackers the same way as the base protocol is. >>=20 >> So in summary I see two issues: >> (1) Add text how to make SCTP/UDP resistant against state loss of NAT = boxes >> (2) Potential insufficient protection against attackers trying to >> change the remote UDP encapsulation port. >> Is this correct? >>=20 >> For addressing (1), text can be added if wanted by the IESG. >=20 > I am not sure the (1) is the only thing that needs to be added. It is > the only one I could immediately think of based on my limited > guesswork what the scope of the document is. If the scope would be > clear there might be other similar issues, but without knowing what is > the actual scope of the document I cannot be sure. >=20 > For exmaple you mentioned that the scope is not limited to only > outbound associations. That indicates there needs to be some way for > the servers to punch holes to the NAT so the initial incoming > connection packets comes to the host. Those hole punching mechanisms > are now part of the security properties of the solution, i.e. if there > is no authentication or anything, i.e. anybody behind the NAT box can > punch or modify those holes as they like, then that would allow > trivial way to redirect traffic to attacker.=20 >=20 >> I'm not completely understanding issue (2). So it would be helpful >> if you could describe the potential attack a bit more. >=20 > It is really hard to describe the attacks when you do not know the > architecture of the system (and I do not have enough understanding of > the SCTP). >=20 > I can try to invent couple different attacks, but all of those would > be depended how the bits which are left out of this document is done. > But before going to those it would be much better to know what is the > scope of this document. hmm. I guess part of the problem is that I try to make clear that the scope is limited to the SCTP stack whereas most reviewers think that the scope has to include how an application will do the negotiation for NAT traversal (possibly including STUN/ICE/TURN or alternate = solutions). This document would then be part of such a document. Best regards Michael > --=20 > kivinen@iki.fi >=20 From klaas@wierenga.net Mon Feb 4 07:10:26 2013 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 E21E321F88B6; Mon, 4 Feb 2013 07:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKQvxNxHm1MG; Mon, 4 Feb 2013 07:10:26 -0800 (PST) Received: from out27-ams.mf.surf.net (out27-ams.mf.surf.net [145.0.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2C02921F869C; Mon, 4 Feb 2013 07:10:25 -0800 (PST) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r14FAOnl017704; Mon, 4 Feb 2013 16:10:24 +0100 Received: from 64-103-25-233.cisco.com ([64.103.25.233] helo=dhcp-10-61-105-5.cisco.com) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U2Ng5-000H8M-Cz; Mon, 04 Feb 2013 16:09:49 +0100 From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <78553359-298A-4E98-AE55-78D7AD4B420B@wierenga.net> Date: Mon, 4 Feb 2013 16:10:22 +0100 To: draft-ietf-xrblock-rtcp-xr-summary-stat.all@tools.ietf.org, "secdir@ietf.org" , The IESG Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Antivirus: no malware found X-Bayes-Prob: 0.0229 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0uIUfaokh - c9c07018cc70 - 20130204 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) X-Mailman-Approved-At: Mon, 04 Feb 2013 07:11:59 -0800 Subject: [secdir] secdir review of draft-ietf-xrblock-rtcp-xr-summary-stat-07 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, 04 Feb 2013 15:10:27 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the = security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. The draft defines three RTCP XR block types for reporting loss, = duplication and discard summary statistics independent from the RTP = application that is used, augmenting the ones in RFC3611. The draft is well written and clear, and I have only minor = comments/questions: * 1.1 Summary Statistics Metrics Since these are summary (as opposed to raw) statistics metrics, does = that mean that the concerns wrt to confidentiality are somewhat = alleviated? And if so, shouldn't that go in the security considerations?=20= * 2.1 Standards language Picture Type=20 It is not clear from the text what Picture Type means. Are you saying = that the 2 choices for Picture Type are respectively Key Frame and = Derived Frame? If so, please make that more clear. Picture Type also = seems a bit of a misnomer, but I guess Frame Type has unwanted = connotations as well * 7 Security Considerations See my remark on 1.1 Cheers, Klaas= From weiler@watson.org Mon Feb 4 11:08:20 2013 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 B364F21F86E3; Mon, 4 Feb 2013 11:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTGH+Hv+6IiZ; Mon, 4 Feb 2013 11:08:20 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC1421F86D6; Mon, 4 Feb 2013 11:08:19 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.5/8.14.5) with ESMTP id r14J8JaK079199; Mon, 4 Feb 2013 14:08:19 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.5/8.14.5/Submit) with ESMTP id r14J8ICg079194; Mon, 4 Feb 2013 14:08:18 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 4 Feb 2013 14:08:18 -0500 (EST) From: Samuel Weiler To: secdir@ietf.org, iesg@ietf.org, ietf@ietf.org, draft-ietf-mmusic-sdp-cs-17.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 04 Feb 2013 14:08:19 -0500 (EST) Subject: [secdir] secdir review of draft-ietf-mmusic-sdp-cs-17 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, 04 Feb 2013 19:08: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 document allows SIP endpoints to negotiate the use of a circuit-switched (e.g. PSTN) channel. It presents a mechanism for correlating an incoming circuit-switched connection with a given SDP/SIP session by sending a nonce or a static string. Summary: I would like to see a stronger authentication mechanism defined to replace the static string or "plaintext password" nonce. I am content with the analysis of security weaknesses: an attacker could trick someone into initiating a potentially expensive PSTN call, and the correlation mechanism is weak. I am not content with the use of a mere nonce or static string for correlation. That is the equivalent of sending plaintext passwords, and I suspect we have better mechanisms available that could allow for mutual endpoint authentication, making it statistically unlikely for a man-in-the-middle to participate successfully in the correlation exchange. The document makes a case for using short strings/nonces (e.g. a caller-ID string or 10 DTFM digits). I suspect both that those lengths could be extended without great pain and that some stronger authentication mechanisms could work with such short strings, especially given the ability to send longer keying material in the packet-switched SDP session. Non-security observation: I'm worried that the architecture of the current correlation mechanism will have some unintended consequences. >From section 5.2.3: The endpoints should be able to correlate the circuit-switched bearer with the session negotiated with SDP in order to avoid ringing for an incoming circuit-switched bearer that is related to the session controlled with SDP (and SIP). As I understand it, some of the defined variants of the correlation scheme require answering the call (e.g. the DTMF scheme) before knowing whether or not the channel corresponds to a SIP session. If it does not, then what? The call is already answered, which gives a surprising user experience. Feel free to tell me I'm off base with this one. -- Sam From bill.wu@huawei.com Mon Feb 4 17:57:13 2013 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 6027E21F855D; Mon, 4 Feb 2013 17:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.691 X-Spam-Level: X-Spam-Status: No, score=-4.691 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUMlxZB-bogR; Mon, 4 Feb 2013 17:57:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4CD21F8959; Mon, 4 Feb 2013 17:57:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOD92351; Tue, 05 Feb 2013 01:57:07 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 5 Feb 2013 01:56:09 +0000 Received: from SZXEML451-HUB.china.huawei.com (10.82.67.194) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 5 Feb 2013 01:57:04 +0000 Received: from w53375 (10.138.41.149) by szxeml451-hub.china.huawei.com (10.82.67.194) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 5 Feb 2013 09:56:57 +0800 Message-ID: <0F71498102964DBDB760AA72B68E8F01@china.huawei.com> From: Qin Wu To: Klaas Wierenga , , , The IESG References: <78553359-298A-4E98-AE55-78D7AD4B420B@wierenga.net> Date: Tue, 5 Feb 2013 09:56:55 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [secdir] secdir review of draft-ietf-xrblock-rtcp-xr-summary-stat-07 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, 05 Feb 2013 01:57:13 -0000 SGksS2xhc3M6DQpUaGFuayBmb3IgeW91ciB2YWx1YWJsZSByZXZpZXcsIHlvdXIgY29tbWVudHMg d2lsbCBiZSBhZGRyZXNzZWQgaW4gdGhlIHVwZGF0ZS4NClBsZWFzZSBzZWUgbXkgcmVwbHkgYmVs b3cuDQoNClJlZ2FyZHMhDQotUWluDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJv bTogIktsYWFzIFdpZXJlbmdhIiA8a2xhYXNAd2llcmVuZ2EubmV0Pg0KVG86IDxkcmFmdC1pZXRm LXhyYmxvY2stcnRjcC14ci1zdW1tYXJ5LXN0YXQuYWxsQHRvb2xzLmlldGYub3JnPjsgPHNlY2Rp ckBpZXRmLm9yZz47ICJUaGUgSUVTRyIgPGllc2dAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIEZl YnJ1YXJ5IDA0LCAyMDEzIDExOjEwIFBNDQpTdWJqZWN0OiBzZWNkaXIgcmV2aWV3IG9mIGRyYWZ0 LWlldGYteHJibG9jay1ydGNwLXhyLXN1bW1hcnktc3RhdC0wNw0KDQoNCkkgaGF2ZSByZXZpZXdl ZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MgIG9u Z29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2Vk IGJ5IHRoZSANCklFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZv ciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuICBEb2N1bWVudCBl ZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IA0KdGhlc2UgY29tbWVudHMganVzdCBs aWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNClRoZSBkcmFmdCBkZWZpbmVzIHRo cmVlIFJUQ1AgWFIgYmxvY2sgdHlwZXMgZm9yIHJlcG9ydGluZyBsb3NzLCBkdXBsaWNhdGlvbiBh bmQgZGlzY2FyZCBzdW1tYXJ5IHN0YXRpc3RpY3MgaW5kZXBlbmRlbnQgZnJvbSB0aGUgUlRQIGFw cGxpY2F0aW9uIHRoYXQgaXMgdXNlZCwgYXVnbWVudGluZyB0aGUgb25lcyBpbiBSRkMzNjExLg0K DQpUaGUgZHJhZnQgaXMgd2VsbCB3cml0dGVuIGFuZCBjbGVhciwgYW5kIEkgaGF2ZSBvbmx5IG1p bm9yIGNvbW1lbnRzL3F1ZXN0aW9uczoNCg0KKiAxLjEgU3VtbWFyeSBTdGF0aXN0aWNzIE1ldHJp Y3MNCg0KU2luY2UgdGhlc2UgYXJlIHN1bW1hcnkgKGFzIG9wcG9zZWQgdG8gcmF3KSBzdGF0aXN0 aWNzIG1ldHJpY3MsIGRvZXMgdGhhdCBtZWFuIHRoYXQgdGhlIGNvbmNlcm5zIHdydCB0byBjb25m aWRlbnRpYWxpdHkgYXJlIHNvbWV3aGF0IGFsbGV2aWF0ZWQ/IEFuZCBpZiBzbywgc2hvdWxkbid0 IHRoYXQgZ28gaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zPyANCg0KW1Fpbl06IEkgcHJl ZmVyIHRvIGtlZXAgYXMgaXQgZG9lcyBzaW5jZSBib3RoIHN1bW1hcnkgYW5kIHJhdyBmYWNlIHRo ZSBzYW1lIGxldmVsIGNvbmZpZGVudGlhbCByaXNrIHdpdGhvdXQgdXNpbmcgU1JUUCBwcm90ZWN0 aW9uLiBUaGUgY29uY2VybiB3cnQgdG8gY29uZmlkaWVudGlhbGl0eSB3aWxsIGJlIGFkZHJlc3Nl ZCBieSBzZWN1cml0eSBzZWN0aW9uIG9mIFJGQzM2MTEsaS5lLiwgdXNpbmcgU1JUUC4gDQoNCiog Mi4xIFN0YW5kYXJkcyBsYW5ndWFnZQ0KDQpQaWN0dXJlIFR5cGUgDQoNCkl0IGlzIG5vdCBjbGVh ciBmcm9tIHRoZSB0ZXh0IHdoYXQgUGljdHVyZSBUeXBlIG1lYW5zLiBBcmUgeW91IHNheWluZyB0 aGF0IHRoZSAyIGNob2ljZXMgZm9yIFBpY3R1cmUgVHlwZSBhcmUgcmVzcGVjdGl2ZWx5IEtleSBG cmFtZSBhbmQgRGVyaXZlZCBGcmFtZT8gSWYgc28sIHBsZWFzZSBtYWtlIHRoYXQgbW9yZSBjbGVh ci4gUGljdHVyZSBUeXBlIGFsc28gc2VlbXMgYSBiaXQgb2YgYSBtaXNub21lciwgYnV0IEkgZ3Vl c3MgRnJhbWUgVHlwZSBoYXMgdW53YW50ZWQgY29ubm90YXRpb25zIGFzIHdlbGwNCg0KW1Fpbl06 IEdvb2QgcG9pbnQsIEkgcHJvcG9zZSB0byBjaGFuZ2UgUGljdHVyZSBUeXBlIGludG8gRnJhbWUg VHlwZSBhbHRob3VnaCB0aGV5IGFyZSB0aGUgc2FtZSB0aGluZywgaW4gYWRkaXRpb24sIEkgcHJv cG9zZSB0byBjaGFuZ2UgdGhlIGRlZmluaXRpb24gb2YgUGljdHVyZSBUeXBlIGFzIGZvbGxvd3M6 DQpPTEQgVEVYVDoNCiINCg0KICAgUGljdHVyZSBUeXBlDQoNCiAgICAgIFBpY3R1cmUgVHlwZXMg dXNlZCBpbiB0aGUgZGlmZmVyZW50IHZpZGVvIGFsZ29yaXRobXMgYXJlIGNvbXBvc2VkDQogICAg ICBvZiB0aGUgS2V5IGZyYW1lIGFuZCBEZXJpdmVkIGZyYW1lcy4gIFRoZSBLZXkgZnJhbWUgaXMN CiAgICAgIGluZGVwZW5kZW50bHkgY29kZWQgd2l0aG91dCBwcmVkaWN0aW9uIGZyb20gb3RoZXIg cGljdHVyZXMgYW5kDQogICAgICB1c2VkIGFzIGEgcmVmZXJlbmNlIGZyYW1lIGZvciBwcmVkaWN0 aW5nIG90aGVyIHBpY3R1cmVzLiAgRGVyaXZlZA0KICAgICAgZnJhbWVzIGFyZSBwcmVkaWNhdGl2 ZWx5IGNvZGVkIGFuZCBkZXJpdmVkIGZyb20gYSBLZXkgZnJhbWUgdXNpbmcNCiAgICAgIGEgcHJl ZGljdGlvbiBhbGdvcml0aG0uDQoNCg0KIg0KTkVXIFRFWFQ6DQoiDQogRnJhbWUgVHlwZQ0KIEEg dmlkZW8gZnJhbWUgaXMgY29tcHJlc3NlZCB1c2luZyBkaWZmZXJlbnQgYWxnb3JpdGhtcy4gDQoN CiBGcmFtZSB0eXBlIGlzIHVzZWQgdG8gaWRlbnRpZnkgZGlmZmVyZW50IGFsZ29yaXRobXMgZm9y IHZpZGVvIGZyYW1lcy4gDQoNCiBUd28gZnJhbWUgVHlwZXMgdXNlZCBpbiB0aGUgZGlmZmVyZW50 IHZpZGVvIGFsZ29yaXRobXMgYXJlIHRoZSBLZXkgDQoNCiBmcmFtZSBhbmQgRGVyaXZlZCBmcmFt ZXMuICBUaGUgS2V5IGZyYW1lIGlzIGluZGVwZW5kZW50bHkgY29kZWQgd2l0aG91dA0KDQogcHJl ZGljdGlvbiBmcm9tIG90aGVyIHBpY3R1cmVzIGFuZCB1c2VkIGFzIGEgcmVmZXJlbmNlIGZyYW1l IGZvciANCg0KIHByZWRpY3Rpbmcgb3RoZXIgcGljdHVyZXMuICBEZXJpdmVkIGZyYW1lcyBhcmUg cHJlZGljYXRpdmVseSBjb2RlZCANCg0KIGFuZCBkZXJpdmVkIGZyb20gYSBLZXkgZnJhbWUgdXNp bmcgYSBwcmVkaWN0aW9uIGFsZ29yaXRobS4NCg0KIg0KDQoqIDcgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMNCg0KU2VlIG15IHJlbWFyayBvbiAxLjENCg0KQ2hlZXJzLA0KDQpLbGFhcz0= From kivinen@iki.fi Tue Feb 5 02:48:55 2013 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 AA20921F88BF; Tue, 5 Feb 2013 02:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jE+WoyWfLw5n; Tue, 5 Feb 2013 02:48:54 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3DA21F88B4; Tue, 5 Feb 2013 02:48:53 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r15AlXMN007529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Feb 2013 12:47:33 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r15AlW1V018132; Tue, 5 Feb 2013 12:47:32 +0200 (EET) 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: <20752.58179.975895.810541@fireball.kivinen.iki.fi> Date: Tue, 5 Feb 2013 12:47:31 +0200 From: Tero Kivinen To: Michael Tuexen In-Reply-To: References: <20718.54159.713629.567812@fireball.kivinen.iki.fi> <8D58A3AD-A276-4AA6-B454-E3D07AB7C90A@fh-muenster.de> <20743.57390.456600.844778@fireball.kivinen.iki.fi> <2D128C1C-ADE8-43CB-990C-56CB7E0C327C@fh-muenster.de> <20746.18802.364266.587982@fireball.kivinen.iki.fi> <0A880226-D910-403B-8D17-1AB928612E36@fh-muenster.de> <20751.46745.772166.652412@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 15 min Cc: draft-ietf-tsvwg-sctp-udp-encaps.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-tsvwg-sctp-udp-encaps-07.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, 05 Feb 2013 10:48:55 -0000 Michael Tuexen writes: > From my understanding this depends on the scope. The scope of the > document is limited to the SCTP stack. This has been implemented > in a kernel stack (FreeBSD) and is also available in a userland > stack based on the FreeBSD kernel stack. > However, it does not cover how to use the API provided and therefore > how to build a complete application. The problem is that I am trying to see if there are any security considerations using this, and I can see a LOTS of security considerations depending how these other parts are done, and some of those do affect what is done in the SCTP stack. This makes analyzing the security really hard. > > Scope might be clearer, but that does not solve the issue what I have > > with the document, i.e. it is very hard to evaluate the proposal when > > I do not know the architecture. > > If the IESG thinks it makes more sense to develop a technique for > encapsulating SCTP in UDP within a particular application, which also > covers the negotiation of the encapsulation, that is fine. > That would give a complete, application specific solution. I do not think you need to go and make application specific solution, but knowing what is the intended scope for this document and against which its security properties have been analyzed would make things better. > Hmm. So you would prefer to limit the scope to the above (which is > fine with me), but that would not change the provided mechanism in > any way and this mechanism can be used in a wider scope. I would prefer have narrow scope, which makes it possible to analyze the security in that scope. If someone wants to use this in ways which are outside that scope, then someone needs to write new document explaining how it is used there, and analyze the security in that situation. > > I think adding that would make document more usable, and would allow > > making interoperable implementations already based on this document, > > without the need of another document explaining how this is used in > > real world (or interop event where implementors decide and agree on > > the cases, and then those decisions are left as folklore in the > > industry, and there is no written description about it). > > OK. We can add that. However this only makes sense if the document > can proceed. If the IESG also requires to add the application level > NAT traversal stuff, then this becomes much more complex. I'm not sure > think that TSVWG has the expertise for that task. The IESG will do the decision anyway, I am just saying that it is bit hard for me to try to understand the security considerations when I do not see the whole system, I can only see one piece (the SCTP stack part) of the system. > > I can try to invent couple different attacks, but all of those would > > be depended how the bits which are left out of this document is done. > > But before going to those it would be much better to know what is the > > scope of this document. > > hmm. I guess part of the problem is that I try to make clear that > the scope is limited to the SCTP stack whereas most reviewers think > that the scope has to include how an application will do the > negotiation for NAT traversal (possibly including STUN/ICE/TURN or > alternate solutions). Yes, at least I am trying to understand how this will be used in the end products, and try to think security considerations of the whole system. > This document would then be part of such a document. Or part of the document set, i.e. this would be perfectly fine part of the protocol explaining how to do things in SCTP stack, and then another document would tell how to do other things like negotiations and finding which port to talk to, and what kind of overall architectures are possible using these documents. -- kivinen@iki.fi From tuexen@fh-muenster.de Tue Feb 5 03:59:50 2013 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 2E0EC21F8734; Tue, 5 Feb 2013 03:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwBMxq8VlXp5; Tue, 5 Feb 2013 03:59:49 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id D3B7221F8727; Tue, 5 Feb 2013 03:59:47 -0800 (PST) Received: from [192.168.1.101] (p508FB80F.dip.t-dialin.net [80.143.184.15]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 4EC211C0C069C; Tue, 5 Feb 2013 12:59:45 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <20752.58179.975895.810541@fireball.kivinen.iki.fi> Date: Tue, 5 Feb 2013 12:59:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0A285B4C-2114-4A26-9267-895FD3C51AD7@fh-muenster.de> References: <20718.54159.713629.567812@fireball.kivinen.iki.fi> <8D58A3AD-A276-4AA6-B454-E3D07AB7C90A@fh-muenster.de> <20743.57390.456600.844778@fireball.kivinen.iki.fi> <2D128C1C-ADE8-43CB-990C-56CB7E0C327C@fh-muenster.de> <20746.18802.364266.587982@fireball.kivinen.iki.fi> <0A880226-D910-403B-8D17-1AB928612E36@fh-muenster.de> <20751.46745.772166.652412@fireball.kivinen.iki.fi> <20752.58179.975895.810541@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1283) Cc: draft-ietf-tsvwg-sctp-udp-encaps.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-tsvwg-sctp-udp-encaps-07.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, 05 Feb 2013 11:59:50 -0000 On Feb 5, 2013, at 11:47 AM, Tero Kivinen wrote: > Michael Tuexen writes: >> =46rom my understanding this depends on the scope. The scope of the >> document is limited to the SCTP stack. This has been implemented >> in a kernel stack (FreeBSD) and is also available in a userland >> stack based on the FreeBSD kernel stack. >> However, it does not cover how to use the API provided and therefore >> how to build a complete application. >=20 > The problem is that I am trying to see if there are any security > considerations using this, and I can see a LOTS of security > considerations depending how these other parts are done, and some of > those do affect what is done in the SCTP stack. This makes analyzing > the security really hard.=20 Understood. >=20 >>> Scope might be clearer, but that does not solve the issue what I = have >>> with the document, i.e. it is very hard to evaluate the proposal = when >>> I do not know the architecture.=20 >>=20 >> If the IESG thinks it makes more sense to develop a technique for >> encapsulating SCTP in UDP within a particular application, which also >> covers the negotiation of the encapsulation, that is fine. >> That would give a complete, application specific solution. >=20 > I do not think you need to go and make application specific solution, > but knowing what is the intended scope for this document and against > which its security properties have been analyzed would make things > better.=20 >=20 >> Hmm. So you would prefer to limit the scope to the above (which is >> fine with me), but that would not change the provided mechanism in >> any way and this mechanism can be used in a wider scope. >=20 > I would prefer have narrow scope, which makes it possible to analyze > the security in that scope. If someone wants to use this in ways which > are outside that scope, then someone needs to write new document > explaining how it is used there, and analyze the security in that > situation.=20 OK. So what about servers using the IANA registered ports numbers not behind a NAT a clients possibly behind a NAT. Does is help, if we narrow = it down to that scope. I could live with that. >=20 >>> I think adding that would make document more usable, and would allow >>> making interoperable implementations already based on this document, >>> without the need of another document explaining how this is used in >>> real world (or interop event where implementors decide and agree on >>> the cases, and then those decisions are left as folklore in the >>> industry, and there is no written description about it).=20 >>=20 >> OK. We can add that. However this only makes sense if the document >> can proceed. If the IESG also requires to add the application level >> NAT traversal stuff, then this becomes much more complex. I'm not = sure >> think that TSVWG has the expertise for that task. >=20 > The IESG will do the decision anyway, I am just saying that it is bit > hard for me to try to understand the security considerations when I do > not see the whole system, I can only see one piece (the SCTP stack > part) of the system. Understood. Maybe the scope mentioned above would be acceptable? >=20 >>> I can try to invent couple different attacks, but all of those would >>> be depended how the bits which are left out of this document is = done. >>> But before going to those it would be much better to know what is = the >>> scope of this document. >>=20 >> hmm. I guess part of the problem is that I try to make clear that >> the scope is limited to the SCTP stack whereas most reviewers think >> that the scope has to include how an application will do the >> negotiation for NAT traversal (possibly including STUN/ICE/TURN or >> alternate solutions).=20 >=20 > Yes, at least I am trying to understand how this will be used in the > end products, and try to think security considerations of the whole > system.=20 >=20 >> This document would then be part of such a document. >=20 > Or part of the document set, i.e. this would be perfectly fine part of > the protocol explaining how to do things in SCTP stack, and then > another document would tell how to do other things like negotiations > and finding which port to talk to, and what kind of overall > architectures are possible using these documents.=20 That would make sense. Best regards Michael > --=20 > kivinen@iki.fi >=20 From randall@lakerest.net Tue Feb 5 03:16:38 2013 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 449E321F86F0; Tue, 5 Feb 2013 03:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4M3lj3khF2x; Tue, 5 Feb 2013 03:16:34 -0800 (PST) Received: from lakerest.net (lakerest.net [70.155.160.98]) by ietfa.amsl.com (Postfix) with ESMTP id A206321F8751; Tue, 5 Feb 2013 03:16:25 -0800 (PST) Received: from [10.1.1.101] (bsd4.lakerest.net [70.155.160.102]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id r15BD6HV038236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Feb 2013 06:14:06 -0500 (EST) (envelope-from randall@lakerest.net) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Randy Stewart In-Reply-To: <20752.58179.975895.810541@fireball.kivinen.iki.fi> Date: Tue, 5 Feb 2013 06:12:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20718.54159.713629.567812@fireball.kivinen.iki.fi> <8D58A3AD-A276-4AA6-B454-E3D07AB7C90A@fh-muenster.de> <20743.57390.456600.844778@fireball.kivinen.iki.fi> <2D128C1C-ADE8-43CB-990C-56CB7E0C327C@fh-muenster.de> <20746.18802.364266.587982@fireball.kivinen.iki.fi> <0A880226-D910-403B-8D17-1AB928612E36@fh-muenster.de> <20751.46745.772166.652412@fireball.kivinen.iki.fi> <20752.58179.975895.810541@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Tue, 05 Feb 2013 05:06:00 -0800 Cc: draft-ietf-tsvwg-sctp-udp-encaps.all@tools.ietf.org, Michael Tuexen , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-tsvwg-sctp-udp-encaps-07.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, 05 Feb 2013 11:16:38 -0000 On Feb 5, 2013, at 5:47 AM, Tero Kivinen wrote: > Michael Tuexen writes: >> =46rom my understanding this depends on the scope. The scope of the >> document is limited to the SCTP stack. This has been implemented >> in a kernel stack (FreeBSD) and is also available in a userland >> stack based on the FreeBSD kernel stack. >> However, it does not cover how to use the API provided and therefore >> how to build a complete application. >=20 > The problem is that I am trying to see if there are any security > considerations using this, and I can see a LOTS of security > considerations depending how these other parts are done, and some of > those do affect what is done in the SCTP stack. This makes analyzing > the security really hard.=20 >=20 >>> Scope might be clearer, but that does not solve the issue what I = have >>> with the document, i.e. it is very hard to evaluate the proposal = when >>> I do not know the architecture.=20 >>=20 >> If the IESG thinks it makes more sense to develop a technique for >> encapsulating SCTP in UDP within a particular application, which also >> covers the negotiation of the encapsulation, that is fine. >> That would give a complete, application specific solution. >=20 > I do not think you need to go and make application specific solution, > but knowing what is the intended scope for this document and against > which its security properties have been analyzed would make things > better.=20 >=20 >> Hmm. So you would prefer to limit the scope to the above (which is >> fine with me), but that would not change the provided mechanism in >> any way and this mechanism can be used in a wider scope. >=20 > I would prefer have narrow scope, which makes it possible to analyze > the security in that scope. If someone wants to use this in ways which > are outside that scope, then someone needs to write new document > explaining how it is used there, and analyze the security in that > situation.=20 >=20 >>> I think adding that would make document more usable, and would allow >>> making interoperable implementations already based on this document, >>> without the need of another document explaining how this is used in >>> real world (or interop event where implementors decide and agree on >>> the cases, and then those decisions are left as folklore in the >>> industry, and there is no written description about it).=20 >>=20 >> OK. We can add that. However this only makes sense if the document >> can proceed. If the IESG also requires to add the application level >> NAT traversal stuff, then this becomes much more complex. I'm not = sure >> think that TSVWG has the expertise for that task. >=20 > The IESG will do the decision anyway, I am just saying that it is bit > hard for me to try to understand the security considerations when I do > not see the whole system, I can only see one piece (the SCTP stack > part) of the system. >=20 >>> I can try to invent couple different attacks, but all of those would >>> be depended how the bits which are left out of this document is = done. >>> But before going to those it would be much better to know what is = the >>> scope of this document. >>=20 >> hmm. I guess part of the problem is that I try to make clear that >> the scope is limited to the SCTP stack whereas most reviewers think >> that the scope has to include how an application will do the >> negotiation for NAT traversal (possibly including STUN/ICE/TURN or >> alternate solutions).=20 >=20 > Yes, at least I am trying to understand how this will be used in the > end products, and try to think security considerations of the whole > system.=20 >=20 >> This document would then be part of such a document. >=20 > Or part of the document set, i.e. this would be perfectly fine part of > the protocol explaining how to do things in SCTP stack, and then > another document would tell how to do other things like negotiations > and finding which port to talk to, and what kind of overall > architectures are possible using these documents.=20 It sounds to me that we need another document besides this. Maybe taking this document and mention as Pete said you could use the assigned port as an example but other scenarios are possible but not described here. This whole document started when I built the tunneling ability into the FreeBSD stack and we originally only setup the SCTP assigned port. = Of course for kernel land its now sysctl'able.. and can be changed=85 but it gets a lot more dicy when you are doing multiple user stacks (as the detailed discussion here shows ;-D) R > --=20 > kivinen@iki.fi >=20 ----- Randall Stewart randall@lakerest.net From shawn.emery@oracle.com Wed Feb 6 00:38:39 2013 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 680B721F8510; Wed, 6 Feb 2013 00:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKwKQKZLA0WE; Wed, 6 Feb 2013 00:38:38 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 98D5B21F8501; Wed, 6 Feb 2013 00:38:38 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r168cbtX024572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Feb 2013 08:38:38 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r168cbuh027817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2013 08:38:37 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r168cbvx000368; Wed, 6 Feb 2013 02:38:37 -0600 Received: from [10.159.70.158] (/10.159.70.158) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 Feb 2013 00:38:36 -0800 Message-ID: <5112164C.3060009@oracle.com> Date: Wed, 06 Feb 2013 01:37:32 -0700 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.11) Gecko/20121204 Thunderbird/10.0.11 MIME-Version: 1.0 To: secdir@ietf.org References: <50A9523F.9070607@oracle.com> <50DFE815.2020501@oracle.com> In-Reply-To: <50DFE815.2020501@oracle.com> Content-Type: multipart/alternative; boundary="------------010200040103040708010602" X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: draft-ietf-oauth-assertions.all@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] Review of draft-ietf-oauth-assertions-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: Wed, 06 Feb 2013 08:38:39 -0000 This is a multi-part message in MIME format. --------------010200040103040708010602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A new version of this draft has been made, 10, which implicitly addresses the concerns that I had brought up during the secdir review. Shawn. -- On 12/30/12 12:07 AM, Shawn Emery 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 internet-draft describes an assertion framework for the OAuth 2.0 protocol. Given that > that this is a framework, subsequent drafts would be needed for a deployed mechanism. > > The security considerations section does exist and outlines various issues including > impersonation, replay, and privacy. The section then suggests ways of mitigating these > threats. This seems sufficient, but can there be more guidance on the Assertion ID to > avoid collision or replay (e.g. length, roll-over, etc.)? > > General comments: > > None. > > Editorial comments: > > Redundant wordings, suggested fix: > > Old: > > An IEFT URN for use as the "XXXX" value can be requested using > the template in An IETF URN Sub-Namespace for OAuth [RFC6755 ]. > > New: > > An IEFT URN for use as the "XXXX" value can be requested using > the template in [RFC6755 ]. > > Shouldn't urn:ietf:params:oauth:grant_type:* be > urn:ietf:params:oauth:grant-type:*? > > s/included yet all/included, yet all/ > > Shawn. > -- > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --------------010200040103040708010602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
A new version of this draft has been made, 10, which implicitly addresses the concerns that I had brought up during the secdir review. 

Shawn.
--
On 12/30/12 12:07 AM, Shawn Emery 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 internet-draft describes an assertion framework for the OAuth 2.0 protocol.  Given that
that this is a framework, subsequent drafts would be needed for a deployed mechanism.

The security considerations section does exist and outlines various issues including
impersonation, replay, and privacy.  The section then suggests ways of mitigating these
threats.  This seems sufficient, but can there be more guidance on the Assertion ID to
avoid collision or replay (e.g. length, roll-over, etc.)?

General comments:

None.

Editorial comments:

Redundant wordings, suggested fix:

Old:

 An IEFT URN for use as the "XXXX" value can be requested using
 the template in An IETF URN Sub-Namespace for OAuth [RFC6755].

New:

 An IEFT URN for use as the "XXXX" value can be requested using
 the template in [RFC6755].

Shouldn't urn:ietf:params:oauth:grant_type:* be 
urn:ietf:params:oauth:grant-type:*?

s/included yet all/included, yet all/

Shawn.
--



_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

--------------010200040103040708010602-- From stephen.farrell@cs.tcd.ie Wed Feb 6 01:44:45 2013 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 2FA5521F8550 for ; Wed, 6 Feb 2013 01:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6FewPDO81Pi for ; Wed, 6 Feb 2013 01:44:43 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 841CB21F85E2 for ; Wed, 6 Feb 2013 01:44:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CC28ABE1E for ; Wed, 6 Feb 2013 09:44:20 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xequTM+ItFMx for ; Wed, 6 Feb 2013 09:44:20 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.41.62.183]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CB8E9BE35 for ; Wed, 6 Feb 2013 09:44:19 +0000 (GMT) Message-ID: <511225F1.7010008@cs.tcd.ie> Date: Wed, 06 Feb 2013 09:44:17 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "secdir@ietf.org" References: <4613980CFC78314ABFD7F85CC30277211199D0A8@IL-EX10.ad.checkpoint.com> In-Reply-To: <4613980CFC78314ABFD7F85CC30277211199D0A8@IL-EX10.ad.checkpoint.com> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <4613980CFC78314ABFD7F85CC30277211199D0A8@IL-EX10.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] Fwd: RE: SecDir review of draft-williams-websec-session-continue-prob-00 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, 06 Feb 2013 09:44:45 -0000 Hi the websec WG would like to get an early review of this one as they consider adopting it. Any takers? Ta, S -------- Original Message -------- Subject: RE: SecDir review of draft-williams-websec-session-continue-prob-00 Date: Wed, 6 Feb 2013 08:40:01 +0000 From: Yoav Nir To: Sean P. Turner , Stephen Farrell CC: Tobias Gondrom Sean? Stephen? -----Original Message----- From: Yoav Nir Sent: Wednesday, January 30, 2013 7:02 AM To: Sean P. Turner; Stephen Farrell Cc: Tobias Gondrom Subject: SecDir review of draft-williams-websec-session-continue-prob-00 Hi The subject draft is about creating a session management protocol for HTTP, that will be (a) more secure than using cookies and (b) tied to authentication. This is a proposed work item for the WebSec working group, and is not (yet) part of our charter. I think having a security review this early on will help the working group reach a decision (hopefully in or around Orlando), and may help us find that we've missed some really important issues and requirements. Would you be willing to ask SecDir to review this? Thanks Yoav From alexey.melnikov@isode.com Wed Feb 6 02:23:37 2013 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 B1BF021F8793; Wed, 6 Feb 2013 02:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shBDp9H3n+uI; Wed, 6 Feb 2013 02:23:36 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 8D77221F8715; Wed, 6 Feb 2013 02:23:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1360146214; d=isode.com; s=selector; i=@isode.com; bh=ich5xI+lhgY3fBwK53gL37vdF4o/RUffwBdPGrbpa8s=; 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=D7768oi+stXmaCxgRj4QQOrk+6AlnZUAvh/ZVPJmGJMmc1UXvJ6DQQRa1hfUYNRxhwhpH+ wxHObjzZzss1DjKfZDrqte0XlVzwl19gjmw0AhH5dRllFPoPBpYrpZXWVqqRvWX1C+jO/w 7PaQ86H7eNNHGSoQt5/YZFs3Pj8YIxk=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 6 Feb 2013 10:23:34 +0000 Message-ID: <51122F5E.4060804@isode.com> Date: Wed, 06 Feb 2013 10:24:30 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-roll-p2p-measurement.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Secdir review of draft-ietf-roll-p2p-measurement-09.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, 06 Feb 2013 10:23:37 -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 specifies a mechanism that enables an RPL router [RFC6550] to measure the aggregated values of given routing metrics along an existing route towards another RPL router, thereby allowing the router to decide if it wants to initiate the discovery of a better route. The Security Considerations section talks about compromised routers causing CPU overload in the routers in the network, draining their batteries and causing traffic congestion in the network. It also talks about using this extension to discover topological features of the LLN (such as the identity of the key routers in the topology) or the remaining energy levels [RFC6551] in the routers in order to attack LLN. It points to use of Secure Measurement Object as a way to provide authorization for performing such discovery operation. This looks adequate to me. From benl@google.com Wed Feb 6 17:58:29 2013 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 4BA2A21E8034 for ; Wed, 6 Feb 2013 17:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POYRZanis0tK for ; Wed, 6 Feb 2013 17:58:28 -0800 (PST) Received: from mail-ia0-x236.google.com (mail-ia0-x236.google.com [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id C2B5021F8505 for ; Wed, 6 Feb 2013 17:58:28 -0800 (PST) Received: by mail-ia0-f182.google.com with SMTP id w33so2415115iag.41 for ; Wed, 06 Feb 2013 17:58:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uKBaZDO+noa/CK6161nRTbVWKcnjAh3R31hLoMzVUGY=; b=bymugGmf1AnhtaKjmHzj4s+mnozV+ZOwmWGm7YB9FGhPMf94h4uCTgg8wmW+vYg7I+ q6I1jLueJxYMYyv2XSku7AbVeetElERX6Fc1KFCjYYVxJfLatDEVimq3q2cSbR77livJ srldgSC0Ymota++Eq/Bmiv6L1y47nLXqKpYyGUChkz1KGBI4fm4Ybkf/XVjyUZP9uGH4 jAbirqAoydBZmikq/4SapLrSDKVVcAgz4G4PH8Ul6pRRzmzbwh1fFMmCYvqy1cwmakB4 UqRsg9v8jYP41y5Ad6vlQydQnd5rEpt7HOSNHgYS7ArD3/j7IY1vnywL4m/NODZC2Nkn 1RRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=uKBaZDO+noa/CK6161nRTbVWKcnjAh3R31hLoMzVUGY=; b=JGK6RvdZhH7hQr9SYWqPHsGY7ilfe7rL18LeWPp4ONTwiTRIPmnrcit8OzZFJLPPDD w9iHqgPpO2b9/FFoBUHzHwg6RH52Ei3u/nRQ3TuutEmww6ye3VqbpUqwc0gS5KcgDn45 yAINQi73UQapVRUb0byWxYQyGm8x7DtE5g5ucUd83xi8dZQuz+eYRHCA84e/Ji3hyPTs TGWLLYVNUyLZYgqEM5tQWjEx3jVbAxlm+oS3h/Bncuq2Yt+TMyDW6MGUvRNpMb7gyf4W 6ozB3WcJQthfBVCCD3GKuUzED2mIFrBRO9mPZwa7Jc4BBt0OHvOWR4acCIyMbuPJH2ph E0tA== MIME-Version: 1.0 X-Received: by 10.50.236.41 with SMTP id ur9mr10771422igc.7.1360202307865; Wed, 06 Feb 2013 17:58:27 -0800 (PST) Received: by 10.64.5.168 with HTTP; Wed, 6 Feb 2013 17:58:27 -0800 (PST) In-Reply-To: <511225F1.7010008@cs.tcd.ie> References: <4613980CFC78314ABFD7F85CC30277211199D0A8@IL-EX10.ad.checkpoint.com> <511225F1.7010008@cs.tcd.ie> Date: Thu, 7 Feb 2013 01:58:27 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQklBdY+NAym8r6HERyvsrbxyK/PpDux5Hmx4ZRp+sJ+om5xTqyuhoqF8VXsi4gpvX0tsClX1iEY20a9rJjdAlbkHBot7hhmlzRae9I/YXpEyAG59koB3b7kWWvzY75EE1blnGJbeRLRqqtqFZqh1EaFO6Xrb3prrYkSkUn8AmSKcXIKCnsztbYI17ptWwrv7G3nZiIV Cc: "secdir@ietf.org" Subject: Re: [secdir] Fwd: RE: SecDir review of draft-williams-websec-session-continue-prob-00 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, 07 Feb 2013 01:58:29 -0000 On 6 February 2013 09:44, Stephen Farrell wrote: > > Hi the websec WG would like to get an early review of this > one as they consider adopting it. Any takers? Not really a proper review, but some thoughts: " 4. Resistance to active attacks on https. [NOTE: This should probably NOT be a requirement. Instead we should be happy to note where a proposed protocol provides this.]" I'm very confused by this point, but... a) What active attacks? Need to specify them. b) If there are active attacks that are actually effective (surely not?) that can be avoided by these protocols, then avoidance should be compulsory. And then... " 8. Session continuation must provide protection against man-in-the- middle (MITM) attacks when using TLS. (This is important when using anonymous Diffie-Hellman cipher suites for TLS, as well as when using server certificates from low-value Public Key Infrastructures (PKI)." Seems to be a couple of examples of what they're talking about. " 10. Must work across all types of proxies. Proxies that can modify the plaintext HTTP requests and responses can (but should not) interfere with any session continuation protocol." A man-in-the-middle is a type of proxy, so this seems like an unsatisfiable requirement. > > Ta, > S > > > -------- Original Message -------- > Subject: RE: SecDir review of draft-williams-websec-session-continue-prob-00 > Date: Wed, 6 Feb 2013 08:40:01 +0000 > From: Yoav Nir > To: Sean P. Turner , Stephen Farrell > > CC: Tobias Gondrom > > Sean? Stephen? > > -----Original Message----- > From: Yoav Nir > Sent: Wednesday, January 30, 2013 7:02 AM > To: Sean P. Turner; Stephen Farrell > Cc: Tobias Gondrom > Subject: SecDir review of draft-williams-websec-session-continue-prob-00 > > Hi > > The subject draft is about creating a session management protocol for > HTTP, that will be (a) more secure than using cookies and (b) tied to > authentication. > > This is a proposed work item for the WebSec working group, and is not > (yet) part of our charter. > > I think having a security review this early on will help the working > group reach a decision (hopefully in or around Orlando), and may help us > find that we've missed some really important issues and requirements. > > Would you be willing to ask SecDir to review this? > > Thanks > > Yoav > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From benl@google.com Thu Feb 7 00:10:50 2013 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 0A90B21F8901 for ; Thu, 7 Feb 2013 00:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+2ZS+dp26hL for ; Thu, 7 Feb 2013 00:10:49 -0800 (PST) Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 99B6521F886A for ; Thu, 7 Feb 2013 00:10:49 -0800 (PST) Received: by mail-ia0-f171.google.com with SMTP id z13so2668684iaz.16 for ; Thu, 07 Feb 2013 00:10:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=raX0uomONUI3tL+8LJjB7OsIyYVTqyMwXKPY73uR4nk=; b=gyLYsH2mQnX8vKX6nQkzv7T+sICUi1ZADsifpiV26e87m6UC478XxSt8YsV/Rehr5A /eIQs8cjbtVs/iVXRKpi7Eb3lmyathAe/O8yINTL8QgsvDWYfXZeztqMuBR4iu3X8Xp5 cUF8lEnKKC6gc9Ub9XwhQylvZEgZlciJFSVLGQOUyldTbeHAInR0NV03dn2hLWPmAjyO Jg3yAebwtSaPAm5DrE/1mLK3ZZ9nu/eNzI+o2SanTFAE3RjfgfDea10nqmunM62p7qrd gPfufmMx47NNyc58JPWinXb6suaDyOeDtR51OwIHdNdTdzfusE8IDJ4/tIoXdJJoSH4m Dkqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=raX0uomONUI3tL+8LJjB7OsIyYVTqyMwXKPY73uR4nk=; b=aEQRyvPUi7LebYqKwVX5kA6cNdsrGbZ6MD3Aw4e38ZUWeHV2bKWZimW/8CEbhiqj6d 8HckxexZV6ra1qTg7ilm62a6Y5QTYPD+6nY6M4YljINIkdvAO8iUD872Y+nVjdZ0rjnT EGImFtFRN7DPs36BkhVy4IF5/m27NNwD+5h0nnGgmZKkJs14rxT5bXRYuFjkMEXVsXQX voLKPhUNlxLTVVMSuwPFv9L5/ITUiwwuc2B9j/hx6crd3R9uTyaYv8JBe1RqJFUXCZ+/ NSupgDJlbkj3LKx8K/eqN/UBRwVz5eLThtrDh+HEk7gQMpwd88veXW3XOEGcbSHh5iLF CwFg== MIME-Version: 1.0 X-Received: by 10.50.222.195 with SMTP id qo3mr881823igc.14.1360224649093; Thu, 07 Feb 2013 00:10:49 -0800 (PST) Received: by 10.64.5.168 with HTTP; Thu, 7 Feb 2013 00:10:48 -0800 (PST) In-Reply-To: <4613980CFC78314ABFD7F85CC30277211199DCC1@IL-EX10.ad.checkpoint.com> References: <4613980CFC78314ABFD7F85CC30277211199DCC1@IL-EX10.ad.checkpoint.com> Date: Thu, 7 Feb 2013 08:10:48 +0000 Message-ID: From: Ben Laurie To: Yoav Nir , "secdir@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkqEOdwPSEOEJV58mH/mfGrXtsS0Zm3RRd36rgYQc0hCPvjImYiw/pgwt73Vmwkb7FsN0Cri11MZ73Fa4bFLtuDEQQ+GUt5TtqnwLo7Kytpdkdzgo+dAxA5pJIq0UX7aCXNvJnGCmkZMgxrWkEBUk7YbuDnUV+q6PA6estnSp068V0zlZ3FJesIzXkbufhkdr6vjXZC Cc: "ietf-websec-sessions@googlegroups.com" , IETF WebSec WG Subject: Re: [secdir] [websec] Fwd: SecDir review of draft-williams-websec-session-continue-prob-00 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, 07 Feb 2013 08:10:50 -0000 On 7 February 2013 07:46, Yoav Nir wrote (that I wrote): > " 10. Must work across all types of proxies. Proxies that can modify > > the plaintext HTTP requests and responses can (but should not) > interfere with any session continuation protocol." > > A man-in-the-middle is a type of proxy, so this seems like an > unsatisfiable requirement. Actually, that's not quite right. Protocols can work across a proxy, but what's required is that the proxy does not gain the ability to pretend to be one of the endpoints. If you satisfy this, then a MitM can snoop, but can't masquerade. But this seems to impose quite a strong constraint on the protocol: in particular, future traffic must somehow be bound to the (end-to-end) session continuation. From olaf@NLnetLabs.nl Thu Feb 7 02:21:55 2013 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 006AE21F846E; Thu, 7 Feb 2013 02:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgSbxlqiMB3u; Thu, 7 Feb 2013 02:21:53 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B468D21F845D; Thu, 7 Feb 2013 02:21:52 -0800 (PST) Received: from [192.168.2.18] (166-49-134-82.eu.bt.net [166.49.134.82] (may be forged)) (authenticated bits=0) by open.nlnetlabs.nl (8.14.6/8.14.4) with ESMTP id r17ALl8d017101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 11:21:48 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) DKIM-Filter: OpenDKIM Filter v2.7.4 open.nlnetlabs.nl r17ALl8d017101 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1360232510; bh=Pi6adQFKT09l5xFXgwuVJpBholVTZ0YyLdNtEo+x+0M=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=eAvSgHcu/FIXJZsx1iUJ09S/Ru1q1ZLFbhWlJE0aYhkzSvN6mlgeIy6xr/A7gS7oP S+PevWE/SnG+RW4dBGym2AW7w5wVeH/4Bfo9aL1W4k6PLUTKEggY5d9LbCtY8iC1aV MsQg+4j1a7bRotOYQcmB8TeZ8e6aSRdccZJ/xs3o= Content-Type: multipart/signed; boundary="Apple-Mail=_7981D21B-77D2-4573-8B04-43C0E6532F95"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Olaf Kolkman In-Reply-To: Date: Thu, 7 Feb 2013 11:21:45 +0100 Message-Id: References: To: secdir@ietf.org X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Thu, 07 Feb 2013 11:21:49 +0100 (CET) Cc: IAB IAB , Hannes Tschofenig Subject: Re: [secdir] EU Cyber Security Strategy. 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, 07 Feb 2013 10:21:55 -0000 --Apple-Mail=_7981D21B-77D2-4573-8B04-43C0E6532F95 Content-Type: multipart/alternative; boundary="Apple-Mail=_3BA1CF52-B84E-486E-9AE8-083A41D38D8A" --Apple-Mail=_3BA1CF52-B84E-486E-9AE8-083A41D38D8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folk, Life from the meeting: It seems that a coordination task-force from the = MSP is being set up for 'Cyber security and Privacy'. The charter is vague to non-available. I've asked the questions/made the = point of openness of such task-force but that didn't really hit base. Appearantly this the strategy will be made public later today: = http://ec.europa.eu/digital-agenda/news-redirect/9589 (at the moment of = posting this URI was not yet working). IEEE is joining this security group, W3C is not. Anyway, it might be good for somebody to track this task-force. If only = to understand that our presence there is not needed, and/or to try and = get some openness. I do not, and don't want to be that person. Hannes, = you perhaps, or another SEC person from Europe? I think this will be mostly e-mail. --Olaf NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf@NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands --Apple-Mail=_3BA1CF52-B84E-486E-9AE8-083A41D38D8A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Olaf M. Kolkman


Science Park 400, 1098 XH Amsterdam, The = Netherlands



= --Apple-Mail=_3BA1CF52-B84E-486E-9AE8-083A41D38D8A-- --Apple-Mail=_7981D21B-77D2-4573-8B04-43C0E6532F95 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJRE4A6AAoJEFRqER47aqpkMw4QAIymvN7azXLIDlXwzbe08cId 6ycnOoaFhoRzBu0Mms1fLgvROhkKev5q79gUop2XRcGatBKJSC7XGRDM1AaqD3an Y6c95ihknZx/JN40XqLnKlIvIxUpAbctBK+UVuXolGq6BjwH2MUH/TQ9HorErOnU C1YiOTUMo0vbyyIZdWXDSovKGzCtQ1A1tMMKAgIKCeqCFYZbot6lbCqfyeCgS4pu T4Mm/eB4rpWZv5LKn4dmoOCxR3hYU0n7/LDY2KR76C1pPxiyHtZ61JB/uD/RYPrk OkeXFCPWfPRXOg5Wb05A/nNF6r3VO+Rp3GvJvIBo33TxSxUtrRSWglP0L6H1SRs2 Fyo1EvJqIOLOu23bAdUZYAvqu1iFvVg0c9OycCxmbRfRiFTNUFSqXUV3vMm2mxnY SHtHdzmzumZJSpE4YEb78CT71em+84Qf1TjB7a79glwYZJba0rJKla2VM8Ik0pBV n+BQfQH6NEq5MtlJCjwd16z2wproXkRgK5D+oVbbEWjmZE3RlmhJfTrvgWCCG5Sv aErsZAH4Rbu886Thv+wSubx68jNB5hKwevObEbvsIFsfBYLb4bGb5nnN7A6pCPMg RC/N9kW0s+JGI9TSmZV7Rhex+tZs/ua5IdSlZpiX5p8XktjhWcRhd27v9u4Rj3i8 4RhSFKuj9zWJLGRMB8K+ =52pS -----END PGP SIGNATURE----- --Apple-Mail=_7981D21B-77D2-4573-8B04-43C0E6532F95-- From kivinen@iki.fi Thu Feb 7 04:11:59 2013 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 7D25C21F85FC for ; Thu, 7 Feb 2013 04:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfcs1xN7oorM for ; Thu, 7 Feb 2013 04:11:58 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 62A3221F857C for ; Thu, 7 Feb 2013 04:11:58 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r17CBoEJ013092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Feb 2013 14:11:50 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r17CBnPW015787; Thu, 7 Feb 2013 14:11:49 +0200 (EET) 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: <20755.39429.174723.54646@fireball.kivinen.iki.fi> Date: Thu, 7 Feb 2013 14:11:49 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min 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, 07 Feb 2013 12:11:59 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Sam Hartman is next in the rotation. For telechat 2013-02-07 Reviewer LC end Draft Shawn Emery TR2012-12-24 draft-ietf-oauth-assertions-10 Phillip Hallam-Baker T 2013-01-03 draft-ietf-roll-p2p-rpl-16 Julien Laganier T 2013-01-21 draft-ietf-ccamp-lmp-behavior-negotiation-10 Ondrej Sury T 2013-01-31 draft-ietf-rtgwg-ordered-fib-09 Brian Weis TR2013-02-07 draft-ietf-sidr-algorithm-agility-11 For telechat 2013-02-21 Shawn Emery T 2013-02-18 draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 Phillip Hallam-Baker T 2013-02-15 draft-ietf-paws-problem-stmt-usecases-rqmts-12 David Harrington T 2013-02-20 draft-templin-intarea-seal-51 Matt Lepinski T 2013-01-25 draft-ietf-radext-radius-extensions-11 Sandy Murphy T 2013-01-29 draft-ietf-6man-nd-extension-headers-03 Hilarie Orman T 2013-02-11 draft-leiba-urnbis-ietf-namespace-01 Tina TSOU T 2013-02-14 draft-gp-obsolete-icmp-types-iana-01 Carl Wallace T 2013-02-05 draft-ietf-behave-nat64-discovery-heuristic-13 David Waltermire T 2013-02-20 draft-shafranovich-mime-sql-03 Brian Weis T 2013-02-06 draft-ietf-mpls-tp-security-framework-08 Nico Williams T 2013-02-18 draft-templin-ironbis-12 For telechat 2013-02-28 Alan DeKok T 2013-02-28 draft-eastlake-additional-xmlsec-uris-08 Donald Eastlake T 2013-02-28 draft-harkins-brainpool-ike-groups-04 Last calls and special requests: Rob Austein 2013-03-06 draft-arkko-iesg-crossarea-03 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-05 Tobias Gondrom 2013-02-18 draft-ietf-mpls-tp-ethernet-addressing-05 Steve Hanna 2013-02-14 draft-ietf-simple-simple-08 Dan Harkins - draft-richardson-roll-applicability-template-01 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-09 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Eric Rescorla 2013-01-24 draft-ietf-ospf-ospfv3-iid-registry-update-01 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-03 Vincent Roca 2013-01-25 draft-ietf-eman-rfc4133bis-05 Nico Williams - draft-ietf-httpbis-p5-range-21 Tom Yu 2013-02-11 draft-ietf-ospf-rfc3137bis-03 Glen Zorn 2013-02-11 draft-ietf-mpls-tp-use-cases-and-design-06 -- kivinen@iki.fi From stephen.farrell@cs.tcd.ie Thu Feb 7 06:47:31 2013 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 B05C621F84D9 for ; Thu, 7 Feb 2013 06:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMtfz-IbLqjP for ; Thu, 7 Feb 2013 06:47:29 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A735D21F8445 for ; Thu, 7 Feb 2013 06:47:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 28B5EBE3F; Thu, 7 Feb 2013 14:47:06 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+vzKFaBtQS6; Thu, 7 Feb 2013 14:47:03 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.46.17.203]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AA574BE3B; Thu, 7 Feb 2013 14:47:03 +0000 (GMT) Message-ID: <5113BE67.5030800@cs.tcd.ie> Date: Thu, 07 Feb 2013 14:47:03 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Olaf Kolkman References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IAB IAB , Hannes Tschofenig , secdir@ietf.org Subject: Re: [secdir] EU Cyber Security Strategy. 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, 07 Feb 2013 14:47:31 -0000 Thanks Olaf, I guess if any interested secdir.eu volunteers exist I guess best is to contact Olaf and Hannes, but it'd be good to let this list know too if you end up doing something. I might offer to monitor too if that makes sense. Ta, S. On 02/07/2013 10:21 AM, Olaf Kolkman wrote: > > Folk, > > Life from the meeting: It seems that a coordination task-force from the MSP is being set up for 'Cyber security and Privacy'. > > The charter is vague to non-available. I've asked the questions/made the point of openness of such task-force but that didn't really hit base. > > Appearantly this the strategy will be made public later today: http://ec.europa.eu/digital-agenda/news-redirect/9589 (at the moment of posting this URI was not yet working). > > IEEE is joining this security group, W3C is not. > > Anyway, it might be good for somebody to track this task-force. If only to understand that our presence there is not needed, and/or to try and get some openness. I do not, and don't want to be that person. Hannes, you perhaps, or another SEC person from Europe? > > I think this will be mostly e-mail. > > > --Olaf > > > NLnet > Labs > Olaf M. Kolkman > > www.NLnetLabs.nl > olaf@NLnetLabs.nl > > Science Park 400, 1098 XH Amsterdam, The Netherlands > > > > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From new-work-bounces@ietf.org Fri Feb 8 13:32:58 2013 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 B8A3C21F8C05; Fri, 8 Feb 2013 13:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1360359178; bh=KNwgotGK2Mpchq7c0elYMN0wyF7n4/mPgfB24KeULB4=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=ZTOcPgRbLZA56yAegVSHqla/vjq2td0Ps4JLmwIKiFmTGxcgt5tiOXWJyFCslLiEg U91UjVvRCJyihfD8Dy7OzCf0DIccTAR3VDyvgUK7EaNGZm3WxlAdvdEY/LzXuEYKLe Cw7/yctK2rBF9bqeblNergVQNgrWUegshVOQ1pbk= 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 4036C21F8C05 for ; Fri, 8 Feb 2013 13:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huSMoi2mkJHg for ; Fri, 8 Feb 2013 13:32:57 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id C186621F8C03 for ; Fri, 8 Feb 2013 13:32:57 -0800 (PST) Received: from bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.69) (envelope-from ) id 1U3vZ2-0004zt-EF; Fri, 08 Feb 2013 16:32:56 -0500 To: new-work@ietf.org Date: Fri, 08 Feb 2013 22:32:56 +0100 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/12.14 (MacIntel) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 08 Feb 2013 13:35:27 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: HTML Working Group (until 2013-03-12) 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, 08 Feb 2013 21:32:58 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the HTML Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the HTML Working Group: http://www.w3.org/html/wg/charter/2012/ 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 2013-03-12 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 Mike Smith, HTML Activity Lead . Thank you, Coralie Mercier, W3C Communications [0] http://www.w3.org/MarkUp/Activity [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +33643220001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From tobias.gondrom@gondrom.org Fri Feb 8 22:26:34 2013 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 5E4AA21F87FA for ; Fri, 8 Feb 2013 22:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.762 X-Spam-Level: X-Spam-Status: No, score=-94.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, J_CHICKENPOX_62=0.6, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTlDBo3qel7W for ; Fri, 8 Feb 2013 22:26:33 -0800 (PST) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id D8FF221F8C7A for ; Fri, 8 Feb 2013 22:26:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=s4Puv7IH6wHmQL0d6tbAxYZnyh4dJ586wzcMCrGFvmYSEHBEnZed6lOF62mjbELFmVstJ228OAHWhaAlQkpyeKX25OpmtALxWPh7f70xmJ0BOmUbd0W2TzqAa6RaWRU1; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 3643 invoked from network); 9 Feb 2013 07:26:27 +0100 Received: from d1-162-57-143-118-on-nets.com (HELO ?10.8.18.138?) (118.143.57.162) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 9 Feb 2013 07:26:26 +0100 Message-ID: <5115EC0E.8060903@gondrom.org> Date: Sat, 09 Feb 2013 14:26:22 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: stephen.farrell@cs.tcd.ie, olaf@NLnetLabs.nl References: <5113BE67.5030800@cs.tcd.ie> In-Reply-To: <5113BE67.5030800@cs.tcd.ie> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: iab@iab.org, Hannes.Tschofenig@nsn.com, secdir@ietf.org Subject: Re: [secdir] EU Cyber Security Strategy. X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 06:26:34 -0000 Thanks Olaf et al. for bringing this up, the link is working, and they put a number of docs up there. But after reading through most of them, must say did not see good info refering to the "coordiantion task-force" and did not find a lot of new things. A large number of pages with high-level good intentions, but not very clear on what _specific_ steps the EU has in mind. Anyway, as there might be some synergy with another NGO on web and application security (OWASP, www.owasp.org) I am working with, and am a EU citizen, I could offer to volunteer. Either for monitoring and/or involvement if necessary. Feel free to put me in touch. Best regards, Tobias Tobias Gondrom Managing Director Thames Stanley email: tobias.gondrom@gondrom.org mobile: +44 7521003005 mobile: +852 56002975 On 07/02/13 22:47, Stephen Farrell wrote: > Thanks Olaf, > > I guess if any interested secdir.eu volunteers exist I guess best > is to contact Olaf and Hannes, but it'd be good to let this list > know too if you end up doing something. > > I might offer to monitor too if that makes sense. > > Ta, > S. > > On 02/07/2013 10:21 AM, Olaf Kolkman wrote: >> Folk, >> >> Life from the meeting: It seems that a coordination task-force from the MSP is being set up for 'Cyber security and Privacy'. >> >> The charter is vague to non-available. I've asked the questions/made the point of openness of such task-force but that didn't really hit base. >> >> Appearantly this the strategy will be made public later today: http://ec.europa.eu/digital-agenda/news-redirect/9589 (at the moment of posting this URI was not yet working). >> >> IEEE is joining this security group, W3C is not. >> >> Anyway, it might be good for somebody to track this task-force. If only to understand that our presence there is not needed, and/or to try and get some openness. I do not, and don't want to be that person. Hannes, you perhaps, or another SEC person from Europe? >> >> I think this will be mostly e-mail. >> >> >> --Olaf >> >> >> NLnet >> Labs >> Olaf M. Kolkman >> >> www.NLnetLabs.nl >> olaf@NLnetLabs.nl >> >> Science Park 400, 1098 XH Amsterdam, The Netherlands >> >> >> >> >> >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From tobias.gondrom@gondrom.org Fri Feb 8 22:28:39 2013 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 9F2DF21F841C for ; Fri, 8 Feb 2013 22:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.062 X-Spam-Level: X-Spam-Status: No, score=-95.062 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3p0Fw1y1VOcC for ; Fri, 8 Feb 2013 22:28:39 -0800 (PST) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 01BA021F8C93 for ; Fri, 8 Feb 2013 22:28:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=Xbdge+bKLGkkPMv65/cVslxknrZeWNTPZqhXWehXTLzqv2HakX3eDB0iMb3ua+/dVM1PwevgB8TpcXzdeR/Zp2RxRSt8Oh3iBfuJNRAo2ekgd1KliDIp4GrwYAZ95PfY; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 3686 invoked from network); 9 Feb 2013 07:28:37 +0100 Received: from d1-162-57-143-118-on-nets.com (HELO ?10.8.18.138?) (118.143.57.162) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 9 Feb 2013 07:28:37 +0100 Message-ID: <5115EC91.6010709@gondrom.org> Date: Sat, 09 Feb 2013 14:28:33 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: secdir@ietf.org, iesg@ietf.org, draft-ietf-mpls-tp-ethernet-addressing.all@tools.ietf.org References: <50E2A5EB.7040706@gondrom.org> In-Reply-To: <50E2A5EB.7040706@gondrom.org> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-ietf-mpls-tp-ethernet-addressing X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 06:28:39 -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 ust like any other last call comments. This ID is Standards Track, is about the link-layer addressing of Ethernet frames carrying MPLS-TP packets. The document is short and ok and the Security Consideration section does discuss the potential issues sufficiently. I have no further comments. Best regards, Tobias From tobias.gondrom@gondrom.org Sat Feb 9 05:35:00 2013 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 342C021F8A89 for ; Sat, 9 Feb 2013 05:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.162 X-Spam-Level: X-Spam-Status: No, score=-95.162 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q45VkBc9Fkp for ; Sat, 9 Feb 2013 05:34:59 -0800 (PST) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 004BE21F8A71 for ; Sat, 9 Feb 2013 05:34:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=qyY7INa+xDJ1c291QljZpW1JrFPGxf/Op7OQ59Dj1fBJKeEWRJRvmqiC7GIaExc0BFxP84lWVUs2tRTAWn4bw3tW1v9ZDs75o3IuaMZ1Z08gcKzC9e42Oabd137nkBNv; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Priority:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 7589 invoked from network); 9 Feb 2013 14:34:57 +0100 Received: from d1-162-57-143-118-on-nets.com (HELO ?10.8.18.138?) (118.143.57.162) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 9 Feb 2013 14:34:57 +0100 Message-ID: <5116507D.7070000@gondrom.org> Date: Sat, 09 Feb 2013 21:34:53 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: benl@google.com X-Priority: 4 (Low) References: <1359054393.10945.15.camel@minbar.fac.cs.cmu.edu> <26550_1359459340_r0TBZdV2026657_CABrd9STdUzPok8bcAUJddcQ0iWkk=VhP6SZOF-Tv8NFf1fUDFQ@mail.gmail.com> <1359494919.17745.12.camel@minbar.fac.cs.cmu.edu> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org, iesg@ietf.org, draft-laurie-pki-sunlight.all@tools.ietf.org, jhutz@cmu.edu Subject: Re: [secdir] dir review of draft-laurie-pki-sunlight-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: Sat, 09 Feb 2013 13:35:00 -0000 Hi Ben, I also just read through your draft in version -07. I can see the draft consists of two parts: 1. data structure 2. protocol. For part #1 the data structure: in case you are not aware of it, some years ago the IETF LTANS WG has done something a bit similar in a more generic way (i.e. for any data not only for certificates) in form of RFC4998 and RFC6283 with a number of implementations by major ECM and DMS vendors. Just as a thought, maybe helpful looking at or even for re-use instead of re-inventing the wheel? Best regards, Tobias On 30/01/13 18:15, Ben Laurie wrote: > On 29 January 2013 21:28, Jeffrey Hutzelman wrote: >> On Tue, 2013-01-29 at 11:35 +0000, Ben Laurie wrote: >>> On 24 January 2013 19:06, Jeffrey Hutzelman wrote: >>>> Similarly, as an anti-spam measure, this document proposes that logs accept >>>> only certificates which chain back to a known CA, and requires that logs >>>> validate each submitted certificate before appending it to the log. This >>>> sounds good, but it's not the only possible mechanism, and so I think MUST >>>> is too strong here. Additionally, there is no discussion of the security >>>> implications if a client depends on a log to do this and the log does not >>>> actually do so. Rather than requiring that logs validate every submitted >>>> certificate, the document should only RECOMMEND that they do so, and make >>>> clear that clients MUST NOT depend on such validation having been done. >>> On second thoughts, whilst that is an effective anti-spam measure, it >>> is also part of the functionality of CT: i.e. to identify misissue and >>> give some means to do something about it. The CA check ensures we have >>> someone to blame for misissue. >> Hrm. I sort of thought the idea was for the logs to be untrusted >> repositories, able to be audited but not themselves expected to detect >> problems. If logs are expected to do validation of this sort, is there >> a way for a third party to discover whether they are doing so (or at >> least, whether they are accepting certificates they shouldn't)? > A third party can indeed verify this - they just watch the log like > any monitor does. > >>> I am not averse to suggestions that achieve the overall aim, but I >>> don't see the virtue of leaving it vague in the description of the >>> experiment we are actually running. >> I'm not suggesting vagueness; rather, I'm merely suggesting downgrading >> a MUST to a SHOULD, which is still quite strong. What happens if >> someone wants to start logging certs issued by a private CA, or >> self-signed certs they have observed, or...? > I don't see an issue with logging certs from a private CA. As for > self-signed certs, I don't see the point, but I guess if someone > figures out a point we can relax it in the next version. > >> I'm suppose I'm OK with keeping the scope narrower than that for >> purposes of the experiment, as long as it is possible to relax the >> requirement later without breaking the system. Hence the importance of >> making it clear that clients must not rely on logs to have done >> validation (on which point I think we've already reached agreement). > Cool. > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From benl@google.com Sat Feb 9 12:47:03 2013 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 8053921F87AC for ; Sat, 9 Feb 2013 12:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K3rQMhvY4Gv for ; Sat, 9 Feb 2013 12:47:03 -0800 (PST) Received: from mail-ie0-x22e.google.com (ie-in-x022e.1e100.net [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6560721F876E for ; Sat, 9 Feb 2013 12:47:02 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id k10so6394610iea.33 for ; Sat, 09 Feb 2013 12:47:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+E4xCKywpB65hLYfTVgQxIPTFgj0EAjdBYkyXOzzNM4=; b=ct2QoHtm/RhfuQ+nsYlm9DiCZZdzQxAbug1bjgIi49TTLsAER5WEmcTlBIPdF6BkcJ F0xx5iH00LItqrKFfntOSoWEKRhywEBlU+axKLG2Pt5oXTyvTRzbV2Cr5q7A3PVBk3ck K6elooyK9Gh+ApvK6jNquBcv8/VkVMcQO6/IiDTpLqDQW9gXFz4HOqTZayQp+Ou/gOt4 KD9uq7XG36/gL18TQN9EPfpGsa+v3GXTlz8HlyaEPjFSx+SN7QUoc0JXbpBb8KLyM3Oy f+qlBMSxdiew0Gd0xrROPSjoHUdNEYeDocIZWMCTu5E0jmPA8OFXTFUXd2icUdRb8v3f 2scg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=+E4xCKywpB65hLYfTVgQxIPTFgj0EAjdBYkyXOzzNM4=; b=bF8H0rRRUfXqDM5Mk/W1GgIZa69FkHwkM7S+bzpL9n4e4aZ4nKeWFd82pHL3f7VJHa gEr53HxA63JRDlyoc3gV21y2s9dMIChlI3sA50DoShSVw8hYXA3PviuRKOej7iZkuEIs Ho1PwPBXkhtX2hizfZfcSWEsecEYrg/Zh/DEnlo05jmJRz0NdD/reeOMD0Z5HBrUj+K0 4BPwvdt0O7hRlC4wbHo3XD4/JKaRf67DX9kTLxeqgtG9KALeUwFbL9o6BkktxcYXSmqo tp7Cvypz51CEb9B41bxjq63MS4DccQbqFtuqCUA5TQPdufE1s4YNZKXztFomipIgwjGI 5v4g== MIME-Version: 1.0 X-Received: by 10.50.222.195 with SMTP id qo3mr8374227igc.14.1360442821902; Sat, 09 Feb 2013 12:47:01 -0800 (PST) Received: by 10.64.5.168 with HTTP; Sat, 9 Feb 2013 12:47:01 -0800 (PST) In-Reply-To: <5116507D.7070000@gondrom.org> References: <1359054393.10945.15.camel@minbar.fac.cs.cmu.edu> <26550_1359459340_r0TBZdV2026657_CABrd9STdUzPok8bcAUJddcQ0iWkk=VhP6SZOF-Tv8NFf1fUDFQ@mail.gmail.com> <1359494919.17745.12.camel@minbar.fac.cs.cmu.edu> <5116507D.7070000@gondrom.org> Date: Sat, 9 Feb 2013 20:47:01 +0000 Message-ID: From: Ben Laurie To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnPyJJ1Fn4jJ9pkEx6yBQC+fN2C3FWgWiIoy3TraOp6LEzM9YWGpTD5FTWI649PDJiEdaraxuRpQslU6bIDx2FZmvEGbdNvlg73R5FQ4xUbSHENwNJnM3Sq988vnmr4T2GhVdsWkvAj1TU7GYI7H5Q03d46YdfqtxPJp6Jc0jzKk5IW7D2up1xXBDiGllrKXFMPPaU3 Cc: "secdir@ietf.org" , The IESG , draft-laurie-pki-sunlight.all@tools.ietf.org, Jeffrey Hutzelman Subject: Re: [secdir] dir review of draft-laurie-pki-sunlight-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: Sat, 09 Feb 2013 20:47:03 -0000 On 9 February 2013 13:34, Tobias Gondrom wrote: > Hi Ben, > > I also just read through your draft in version -07. > I can see the draft consists of two parts: > 1. data structure > 2. protocol. > > For part #1 the data structure: in case you are not aware of it, some > years ago the IETF LTANS WG has done something a bit similar in a more > generic way (i.e. for any data not only for certificates) in form of > RFC4998 and RFC6283 Interesting. I was not aware of these. From a quick skim they are indeed similar, but would need a bunch of added machinery to get them to where CT is (e.g. not append only, no concept of MMD). > with a number of implementations by major ECM and > DMS vendors. No idea what ECM or DMS are in this context. > Just as a thought, maybe helpful looking at or even for re-use instead > of re-inventing the wheel? > > Best regards, Tobias > > > > On 30/01/13 18:15, Ben Laurie wrote: >> On 29 January 2013 21:28, Jeffrey Hutzelman wrote: >>> On Tue, 2013-01-29 at 11:35 +0000, Ben Laurie wrote: >>>> On 24 January 2013 19:06, Jeffrey Hutzelman wrote: >>>>> Similarly, as an anti-spam measure, this document proposes that logs accept >>>>> only certificates which chain back to a known CA, and requires that logs >>>>> validate each submitted certificate before appending it to the log. This >>>>> sounds good, but it's not the only possible mechanism, and so I think MUST >>>>> is too strong here. Additionally, there is no discussion of the security >>>>> implications if a client depends on a log to do this and the log does not >>>>> actually do so. Rather than requiring that logs validate every submitted >>>>> certificate, the document should only RECOMMEND that they do so, and make >>>>> clear that clients MUST NOT depend on such validation having been done. >>>> On second thoughts, whilst that is an effective anti-spam measure, it >>>> is also part of the functionality of CT: i.e. to identify misissue and >>>> give some means to do something about it. The CA check ensures we have >>>> someone to blame for misissue. >>> Hrm. I sort of thought the idea was for the logs to be untrusted >>> repositories, able to be audited but not themselves expected to detect >>> problems. If logs are expected to do validation of this sort, is there >>> a way for a third party to discover whether they are doing so (or at >>> least, whether they are accepting certificates they shouldn't)? >> A third party can indeed verify this - they just watch the log like >> any monitor does. >> >>>> I am not averse to suggestions that achieve the overall aim, but I >>>> don't see the virtue of leaving it vague in the description of the >>>> experiment we are actually running. >>> I'm not suggesting vagueness; rather, I'm merely suggesting downgrading >>> a MUST to a SHOULD, which is still quite strong. What happens if >>> someone wants to start logging certs issued by a private CA, or >>> self-signed certs they have observed, or...? >> I don't see an issue with logging certs from a private CA. As for >> self-signed certs, I don't see the point, but I guess if someone >> figures out a point we can relax it in the next version. >> >>> I'm suppose I'm OK with keeping the scope narrower than that for >>> purposes of the experiment, as long as it is possible to relax the >>> requirement later without breaking the system. Hence the importance of >>> making it clear that clients must not rely on logs to have done >>> validation (on which point I think we've already reached agreement). >> Cool. >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From tobias.gondrom@gondrom.org Sat Feb 9 18:54:54 2013 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 CCB5821F859D for ; Sat, 9 Feb 2013 18:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.212 X-Spam-Level: X-Spam-Status: No, score=-95.212 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoVrrpMdMdw0 for ; Sat, 9 Feb 2013 18:54:54 -0800 (PST) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id A403E21F8233 for ; Sat, 9 Feb 2013 18:54:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=oa7LaHCdgmRo611XpJwfhUOeLjOf2cE1ToXHfWzYJ8+ydh11/V4RedwfyG282ho1FRfurCLgQHHj2zCpRpsJfbJEOFR3/uSzNupKZT4TBKFGauVA7NGECYeDB7Vc2nNo; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 15438 invoked from network); 10 Feb 2013 03:54:52 +0100 Received: from d1-162-57-143-118-on-nets.com (HELO ?10.8.18.138?) (118.143.57.162) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 10 Feb 2013 03:54:51 +0100 Message-ID: <51170BF7.6060409@gondrom.org> Date: Sun, 10 Feb 2013 10:54:47 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: benl@google.com References: <1359054393.10945.15.camel@minbar.fac.cs.cmu.edu> <26550_1359459340_r0TBZdV2026657_CABrd9STdUzPok8bcAUJddcQ0iWkk=VhP6SZOF-Tv8NFf1fUDFQ@mail.gmail.com> <1359494919.17745.12.camel@minbar.fac.cs.cmu.edu> <5116507D.7070000@gondrom.org> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org, iesg@ietf.org, draft-laurie-pki-sunlight.all@tools.ietf.org, jhutz@cmu.edu Subject: Re: [secdir] dir review of draft-laurie-pki-sunlight-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: Sun, 10 Feb 2013 02:54:54 -0000 On 10/02/13 04:47, Ben Laurie wrote: > On 9 February 2013 13:34, Tobias Gondrom wrote: >> Hi Ben, >> >> I also just read through your draft in version -07. >> I can see the draft consists of two parts: >> 1. data structure >> 2. protocol. >> >> For part #1 the data structure: in case you are not aware of it, some >> years ago the IETF LTANS WG has done something a bit similar in a more >> generic way (i.e. for any data not only for certificates) in form of >> RFC4998 and RFC6283 > Interesting. I was not aware of these. From a quick skim they are > indeed similar, but would need a bunch of added machinery to get them > to where CT is (e.g. not append only, no concept of MMD). You are welcome. I believe the gap is mostly towards the protocol side (e.g. including MMD). As the RFCs only define the data structure. >> with a number of implementations by major ECM and >> DMS vendors. > No idea what ECM or DMS are in this context. ECM: Enterprise Content Management DMS: Document Management System (Systems that store electronic documents/data. And protect the proof of integrity / non-repudiation with Timestamps and RFC4998/RFC6283.) > >> Just as a thought, maybe helpful looking at or even for re-use instead >> of re-inventing the wheel? >> >> Best regards, Tobias >> >> >> >> On 30/01/13 18:15, Ben Laurie wrote: >>> On 29 January 2013 21:28, Jeffrey Hutzelman wrote: >>>> On Tue, 2013-01-29 at 11:35 +0000, Ben Laurie wrote: >>>>> On 24 January 2013 19:06, Jeffrey Hutzelman wrote: >>>>>> Similarly, as an anti-spam measure, this document proposes that logs accept >>>>>> only certificates which chain back to a known CA, and requires that logs >>>>>> validate each submitted certificate before appending it to the log. This >>>>>> sounds good, but it's not the only possible mechanism, and so I think MUST >>>>>> is too strong here. Additionally, there is no discussion of the security >>>>>> implications if a client depends on a log to do this and the log does not >>>>>> actually do so. Rather than requiring that logs validate every submitted >>>>>> certificate, the document should only RECOMMEND that they do so, and make >>>>>> clear that clients MUST NOT depend on such validation having been done. >>>>> On second thoughts, whilst that is an effective anti-spam measure, it >>>>> is also part of the functionality of CT: i.e. to identify misissue and >>>>> give some means to do something about it. The CA check ensures we have >>>>> someone to blame for misissue. >>>> Hrm. I sort of thought the idea was for the logs to be untrusted >>>> repositories, able to be audited but not themselves expected to detect >>>> problems. If logs are expected to do validation of this sort, is there >>>> a way for a third party to discover whether they are doing so (or at >>>> least, whether they are accepting certificates they shouldn't)? >>> A third party can indeed verify this - they just watch the log like >>> any monitor does. >>> >>>>> I am not averse to suggestions that achieve the overall aim, but I >>>>> don't see the virtue of leaving it vague in the description of the >>>>> experiment we are actually running. >>>> I'm not suggesting vagueness; rather, I'm merely suggesting downgrading >>>> a MUST to a SHOULD, which is still quite strong. What happens if >>>> someone wants to start logging certs issued by a private CA, or >>>> self-signed certs they have observed, or...? >>> I don't see an issue with logging certs from a private CA. As for >>> self-signed certs, I don't see the point, but I guess if someone >>> figures out a point we can relax it in the next version. >>> >>>> I'm suppose I'm OK with keeping the scope narrower than that for >>>> purposes of the experiment, as long as it is possible to relax the >>>> requirement later without breaking the system. Hence the importance of >>>> making it clear that clients must not rely on logs to have done >>>> validation (on which point I think we've already reached agreement). >>> Cool. >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From d3e3e3@gmail.com Sat Feb 9 20:07:00 2013 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 EB88F21F858E; Sat, 9 Feb 2013 20:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.402 X-Spam-Level: X-Spam-Status: No, score=-103.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeShRL0DB-yd; Sat, 9 Feb 2013 20:06:59 -0800 (PST) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id 595A921F857C; Sat, 9 Feb 2013 20:06:59 -0800 (PST) Received: by mail-oa0-f54.google.com with SMTP id n12so5234035oag.41 for ; Sat, 09 Feb 2013 20:06:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=dcOI88gCeprikCbCaYIg+5ktuGMnPaRBixxdYco/49Y=; b=Pnh+2+w3wTerSGQhjTCws2E9m0mWI0yzmEgwucrBzAv0Ci78wWqojxJHvdLFlu71co +LLQlv7nI9mpDSDLtVBpSv73fnpT69D2/w1s8WQFeXwDpvJqk+Dgzw02AgAVlaY/+FVJ A1S4VrNHMD+WpV+CzNmRTAP5M7J3E3rCT/9LO8P+jUnW4CXZhVMYlFyYzgA4n9Q6LUiA SZTbTG2PGzPFd5bIikatJLzEESvlnREQVyQZxyc++EgdhMgMuxqPOgYiLOidFGsVYJSs PLHCquVEySfcE9p+2/257zIySslhIyWxYrwBDn5em0uLa3R0b2+8FVxKje7gci48DUQk 2FVg== X-Received: by 10.182.164.8 with SMTP id ym8mr2456334obb.68.1360469218944; Sat, 09 Feb 2013 20:06:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.98.168 with HTTP; Sat, 9 Feb 2013 20:06:37 -0800 (PST) From: Donald Eastlake Date: Sat, 9 Feb 2013 23:06:37 -0500 Message-ID: To: iesg@ietf.org, secdir@ietf.org, draft-harkins-brainpool-ike-groups-all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] SECDIR review draft-harkins-brainpool-ike-groups-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: Sun, 10 Feb 2013 04:07:00 -0000 I have reviewed this informational 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. I see this draft as a useful document to achieve the bureaucratic function of getting some elliptic curves that are already specified in an IETF RFC into an already existing IANA Registry because that Registry is referenced by already adopted standards (including 802.11). The only complicating factor is that the original intended use of this Registry is deprecated so this draft provides for the added entries to be annotated to exclude such deprecated use. (In case you were wondering, there is no inherent problem in appropriate IANA actions being based on an Informational RFC.) The Security Considerations section seems to be a reasonable for the elliptic curves covered by this draft but for that purpose. I do not think that the Reference to RFC 2119 is necessary and the one 2119 word used, "MUST", does not need to be in all capitals. MINOR: arithmatical -> arithmetical I suggest that the body of [IEEE802.11] reference be change to: IEEE, "Telecommunications and information exchange between systems Local and metropolitan area networks - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2012, 29 March 2012. I verified the Domain Parameters that have been copied from RFC 5639 (all but the z parameter) and they appear to have been faithfully copied. I have not verified the test data. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From tlyu@mit.edu Sun Feb 10 11:29:16 2013 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 D223521F8794; Sun, 10 Feb 2013 11:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w83nco2gpFV4; Sun, 10 Feb 2013 11:29:16 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1548621F878F; Sun, 10 Feb 2013 11:29:15 -0800 (PST) X-AuditID: 12074423-b7f5b6d000007e03-eb-5117f50bfc5a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 29.17.32259.B05F7115; Sun, 10 Feb 2013 14:29:15 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r1AJTEBe007780; Sun, 10 Feb 2013 14:29:15 -0500 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r1AJTCYM011001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 10 Feb 2013 14:29:14 -0500 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r1AJTCYH014834; Sun, 10 Feb 2013 14:29:12 -0500 (EST) To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ospf-rfc3137bis.all@tools.ietf.org From: Tom Yu Date: Sun, 10 Feb 2013 14:29:11 -0500 Message-ID: Lines: 23 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUixG6nrsv9VTzQ4HmPtMWaA1dZLWb8mchs 8WHhQxYHZo8lS34yeXy5/JktgCmKyyYlNSezLLVI3y6BK+PBs3amguvsFTc2P2NtYOxn62Lk 5JAQMJE4PPkSK4QtJnHh3nqwuJDAPkaJX5sUuxi5gOyNjBIzb91khHDOMUks2nmIGaKqi1Hi 82z1LkYODhGBKIlnTVogprCAucSZliQQk01AWuLo4jKQYhYBVYlvW78ygdi8AhYSk04eZgUp 4RHglJi0IBkiLChxcuYTFhCbWUBL4sa/l0wTGPlmIUnNQpJawMi0ilE2JbdKNzcxM6c4NVm3 ODkxLy+1SNdMLzezRC81pXQTIzjEXJR3MP45qHSIUYCDUYmHl+GxWKAQa2JZcWXuIUZJDiYl Ud6tn8UDhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwHj8ElONNSaysSi3Kh0lJc7AoifNeS7np LySQnliSmp2aWpBaBJOV4eBQkuBd8wWoUbAoNT21Ii0zpwQhzcTBCTKcB2j4UpDFvMUFibnF mekQ+VOMilLivEdBEgIgiYzSPLheWAp4xSgO9IowrzrICh5g+oDrfgU0mAloMGcO2OCSRISU VAMj98aY4CIW6XSBw8IZavOkf9gHZG8/Fq3OZ2EdqfNYcH2iZcnZpikfj2/u5T1SzTgrwvf8 tdiv89laZt/733Jx7xO5g8x5QbM/R/tYK21b8TXBWyC+RX3d8nbzmY+Vl9olXTj99+6mqddf POU7HHn5stTP+jxJ1v19Vj4FNcl5845mPHS72f9JiaU4I9FQi7moOBEA3h8MYtwCAAA= Subject: [secdir] secdir review of draft-ietf-ospf-rfc3137bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 19:29:16 -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 Security Considerations section of this document states: The technique described in this document does not introduce any new security issues into the OSPF protocol. I believe this is true. Editorial comments: * The acronym LSA appears in this document, but there appears to be no expansion of it in the document. * Section 2 mentions MaxLinkMetric, but the document doesn't define it until Section 3. I looked in vain in the OSPF RFCs until I realized this document newly defines this value. Consider indicating this forward reference in Section 2, e.g. "...set to MaxLinkMetric (defined in Section 3)". From hilarie@purplestreak.com Sun Feb 10 22:50:07 2013 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 9457721F88A3; Sun, 10 Feb 2013 22:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojIBXHk9Uz7u; Sun, 10 Feb 2013 22:50:06 -0800 (PST) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0A00A21F8888; Sun, 10 Feb 2013 22:50:05 -0800 (PST) Received: from mx02.mta.xmission.com ([166.70.13.212]) by out03.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1U4nDJ-0002GB-9g; Sun, 10 Feb 2013 23:50:05 -0700 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=sylvester.rhmr.com) by mx02.mta.xmission.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1U4nDI-0003Z0-Bi; Sun, 10 Feb 2013 23:50:05 -0700 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.3/Debian-9.1ubuntu1) with ESMTP id r1B6nLRN002886; Sun, 10 Feb 2013 23:49:21 -0700 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id r1B6nL8u002884; Sun, 10 Feb 2013 23:49:21 -0700 Date: Sun, 10 Feb 2013 23:49:21 -0700 Message-Id: <201302110649.r1B6nL8u002884@sylvester.rhmr.com> From: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx02.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700) X-SA-Exim-Scanned: Yes (on mx02.mta.xmission.com) Subject: [secdir] Secdir review of draft-leiba-urnbis-ietf-namespace-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 06:50:07 -0000 Secdir review of Registration of Second-Level URI Namespaces Under "ietf" draft-leiba-urnbis-ietf-namespace-01 Do not be alarmed. 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. >From the Abstract: RFC 2648 defines the "ietf" URN namespace, and defines a number of sub-namespaces. RFC 3553 defines an additional sub-namespace, "params", and creates a registry to document allocations under that. But there is no registry that lists, in one place, all sub-namespaces of "ietf". This document creates and populates such a registry. I agree with the author's assessment that there are no security ramifications. Hilarie From new-work-bounces@ietf.org Tue Feb 12 13:34:43 2013 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 B681321F8C6B; Tue, 12 Feb 2013 13:34:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1360704883; bh=OogHAMEVT7RcrnTzPe/rGY8ZTA5qjijnY/0i1GW1Ols=; 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=paOiaIfL7x5U9ku0ryOrajPIz2r7QHFiDBT67el8UcE2CVdDsTTVclVdJBndrWWSE a9orp2WyEdbc9n/0P1qzapG8KD0T/Wj7haq/Sb3Omm5VU3XXQ8ZbZz4QKq5XzH+nxf E+36+VNHQx234HWoogE0Ll5Y+yk+xECl9/pjM9YY= 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 BF82421F8C5C; Tue, 12 Feb 2013 13:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 0E9A3qe55Jmu; Tue, 12 Feb 2013 13:34:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C9C21F8C4B; Tue, 12 Feb 2013 13:34:40 -0800 (PST) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130212213440.3452.98137.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2013 13:34:40 -0800 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, 12 Feb 2013 14:12:39 -0800 Subject: [secdir] [new-work] WG Review: Web PKI OPS (wpkops) 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, 12 Feb 2013 21:34:44 -0000 A new IETF working group has been proposed in the Operations and Management Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-01-29. Web PKI OPS (wpkops) ------------------------------------------------ Current Status: Proposed Working Group Chairs: Tim Moses Assigned Area Director: Ronald Bonica Mailing list Address: wpkops@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/wpkops Archive: http://www.ietf.org/mail-archive/web/wpkops/ Charter of Working Group: The Web PKI is the set of systems, policies and procedures most commonly used, in conjunction with security protocols (e.g. TLS/SSL and OCSP), to protect the confidentiality, integrity and authenticity of communications between Web browsers and Web content servers. More specifically, the Web PKI (as considered here) consists of the fields included in the certificates issued to Web content and application providers by Certification Authorities (CAs), the certificate status services provided by the Authorities to Web browsers and their users, and the TLS/SSL protocol stacks embedded in web servers and browsers. The Web PKI first appeared in 1993 or thereabouts and has developed continuously in a somewhat organic fashion since then. Taking into account all the versions of Web servers and browsers that have been released in the intervening years, there are now hundreds of variations on the Web PKI in regular use. And this is a source of problems for end-users, certificate holders, and certificate issuers (CAs). For end-users (i.e. relying parties), there is no clear view whether certificate "problems" remain when they see indication of a "good" connection. For instance, in some browsers, a "good" indication is displayed when a "revoked" response has been received and "accepted" by the user, whereas other browsers refuse to display the contents under these circumstances. Many certificate holders are unsure which browser versions will reject their certificate if certain certificate profiles are not met, such as a subject public key that does not satisfy a minimum key size, or a certificate policies extension that does not contain a particular standard policy identifier. And for certificate issuers, it is difficult to predict whether a certificate chain with certain characteristics will be accepted. For instance, some browsers include a nonce in their OCSP requests and expect one in the corresponding responses, not all servers include a nonce in their replies, and this means some certificate chains will validate while others won't. Starting from the premise that more consistency in Web security behavior is desirable, a natural first step is to document current and historic browser and server behavior, including: the trust model on which they are based; the contents and processing of fields and extensions; the processing of the various revocation schemes; and how the TLS stack deals with PKI, including varying interpretations and implementation errors, as well as state changes visible to the user. Where appropriate, specific products and specific versions of those products will be identified. The effectiveness of the Web PKI depends critically upon decisions made by its users in response to information provided in the user interfaces of its various components. Therefore, such information should be accurate and complete, yet comprehensible. While recording the design details of the user interfaces of specific products is not necessary, state changes that are visible to, and/or controlled by, the user should be captured. Such a project has to be bounded. Therefore, only server-authentication behavior encountered in more than 0.1 percent of connections made by desktop and mobile browsers is to be considered. While it is not intended to apply the threshold with any precision, it will be used to justify the inclusion or exclusion of a technique. Future activities may attempt to prescribe how the Web PKI "should" work, and the prescription may turn out to be a proper subset of the PKIX PKI. However, that task is explicitly not a goal of the proposed working group. Instead, the group's goal is merely to describe how the Web PKI "actually" works in the set of browsers and servers that are in common use today. Additionally, a number of applications (such as client authentication, document signing, code signing, and email) often use the same trust anchors and certificate processing mechanisms as those used for Web server authentication. This reuse creates problems in some situations [1]. While these applications are outside the scope of this working group, deliverables should (wherever practical within the available expertise and time) identify mechanisms that are reused by other applications and identify the implications of that reuse. Also, the reliability of the Web PKI depends critically on the "practices" of its certificate issuers. These practices comprise how certificate issuers perform their functions and implement controls, and are described in documents known as "Certification Practice Statements" [2][3] and operational requirements documents [4][5]. However, the topic of certification practices is outside the scope of the working group. That there are technical shortcomings with Web PKI, as it is practiced today, is well recognized. And, that there is also some urgency in addressing these shortcomings is also well recognized. But, it is felt that too much haste can be counter-productive. The expectation is that the work of this group will bring to light, in a systematic way, aspects of the Web PKI that should be progressed in future working groups of the IETF's Security Area, and that Web servers, browsers and CAs will be willing to participate in those working groups and modify their products to comply with their standards. Given the urgency of the required developments and the scale of the task, it is agreed that adherence to the published schedule should take precedence over completeness of the results, without sacrificing technical correctness. Milestones ========== 1. First WG draft of "trust model" document (4 months). 2. First WG draft of "field and extension processing for certificates, CRLs, and OCSP responses" document (12 months). 3. First WG draft of "certificate revocation" document (8 months). 4. First WG draft of "TLS stack operation" document (8 months). 5. IESG submission of "trust model" document (16 months). 6. IESG submission of "field and extension processing for certificates, CRLs, and OCSP responses" document (24 months). 7. IESG submission of "certificate revocation" document (20 months). 8. IESG submission of "TLS stack operation" document (16 months). References: [1] https://www.ietf.org/mail-archive/web/wpkops/current/msg00104.html [2] Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. S. Chokhani et al, IETF RFC3647 https://tools.ietf.org/html/rfc3647 [3] Electronic Signatures and Infrastructures (ESI); Policy requirements for certification authorities issuing public key certificates. ETSI TS 102 042 V2.2.1 (2011- 12) http://www.etsi.org/deliver/etsi_ts/102000_102099/102042/02.02. 01_60/ts_102042v020201p.pdf [4] Network and certificate system security requirements, CA/Browser Forum, Aug 2012, https://www.cabforum.org/Network_Security_Controls_V1.pdf [5] Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates Version 1.0, CA/Browser Forum, Nov 2011, https://www.cabforum.org/Baseline_Requirements_V1.pdf Milestones: _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Feb 12 13:52:08 2013 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 5EEA021F8B81; Tue, 12 Feb 2013 13:52:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1360705923; bh=G6qLpssegWeHAXW2BShhqWsYH6+qDVfQq5Fs11HF0Uc=; 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=MSQHTIb91W8bn4Wre4vkqqjzC5K0m+gVbm9oQa/Jv/D+zymZ6P9QOEvOpiZ48FQLR GtbvF3TN7Dt+XY+hKFuDps8yV8KM7UCSYmNMt2Xc9GXOZbRDMMjC7EWggdtTzMHlwu YBphwULe6R1lPtcYpgZ++CakqPfMZdff2pEWa5mI= 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 AB3CD21F8B85; Tue, 12 Feb 2013 13:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 ExCY1QEAd-nX; Tue, 12 Feb 2013 13:51:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BA321F8B73; Tue, 12 Feb 2013 13:51:53 -0800 (PST) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130212215153.14058.73204.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2013 13:51:53 -0800 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, 12 Feb 2013 14:12:39 -0800 Subject: [secdir] [new-work] WG Review: Common Authentication Technology Next Generation (kitten) 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, 12 Feb 2013 21:52:08 -0000 The Common Authentication Technology Next Generation (kitten) working group in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-02-19. Common Authentication Technology Next Generation (kitten) ------------------------------------------------ Current Status: Active Working Group Chairs: Shawn Emery Josh Howlett Sam Hartman Secretaries: Simon Josefsson Assigned Area Director: Stephen Farrell Mailing list Address: kitten@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/kitten Archive: http://www.ietf.org/mail-archive/web/kitten/ Charter of Working Group: Description of Working Group: ------------------------------------------ The purpose of the Common Authentication Technology Next Generation (Kitten) working group (WG) is to develop extensions/improvements to the GSS-API and to the Kerberos authentication system, shepherd specific GSS-API security mechanisms, and provide guidance for any new SASL-related submissions. This charter combines the work of the Kerberos WG and the kitten WG (under the aegis of the kitten WG). In places, it identifies which WG was previously home for that work. The working group will develop extensions and/or updates to the GSS-API, working on specific items regarding credential management, replay cache avoidance, error reporting, and supporting stateless and/or distributed acceptors. The working group will also maintain and improve upon the Kerberos protocol, working on items regarding internationalization, new initial authentication types, authorization framework/data, replay cache avoidance, cryptography advances, interop with 3rd party authentication, and identity management. In detail, both existing and new work items include: Existing Working Group Items --------------------------- SASL Mechanism for OAuth (draft-ietf-kitten-sasl-oauth) SASL Mechansim for SAML-EC (draft-ietf-kitten-sasl-saml-ec) GSS-API IANA Registry (draft-ietf-kitten-gssapi-extensions-iana) KDC Model (draft-ietf-krb-wg-kdc-model) PKINIT Hash Agility (draft-ietf-krb-wg-pkinit-alg-agility) Kerberos IANA Registry (draft-ietf-kitten-kerberos-iana-registries) Initial and Pass Through Authentication in Kerberos 5 (draft-ietf-krb-wg-iakerb) Unencrypted Portion of Ticket Extensions (draft-ietf-krb-wg-ticket-extensions) GSS-API Related --------------- Provide new interfaces for credential management, which include the following: initializing credentials iterating credentials exporting/importing credentials Negotiable replay cache avoidance Define interfaces for better error message reporting. Specify an option for exporting partially-established security contexts and possibly a utility function for exporting security contexts in an encrypted form, as well as a corresponding utility function to decrypt and import such security context tokens. Specify one-time password / two-factor authentication needs for SASL applications. This could be achieved through an explicit new GSS-API/SASL mechanism (e.g., http://tools.ietf.org/html/draft-josefsson-kitten-crotp-00) or if the consensus is that due to usability reasons, it is preferable to do OTP/2FA through an higher level protocol (Kerberos/OpenID/SAML/SAML20EC/EAP?) then prepare a document explaining the usability problem and provide pointers for implementers. Kerberos Related ---------------- Prepare and advance one or more standards-track specifications which update the Kerberos version 5 protocol to support non-ASCII principal and realm names, salt strings, and passwords, and localized error reporting. Maximizing backward compatibility is strongly desired. Prepare, review, and advance standards-track and informational specifications defining new authorization data types for carrying supplemental information about the client to which a Kerberos ticket has been issued and/or restrictions on what the ticket can be used for. To enhance this ongoing authorization data work, a container format supporting the use cases of draft-ietf-krb-wg-pad may be standardized. Prepare a standards-track protocol to solve the use cases addressed by draft-hotz-kx509-01 including new support for digital signatures. Today Kerberos requires a replay cache to be used in AP exchanges in almost all cases. Replay caches are quite complex to implement correctly, particularly in clustered systems. High-performance replay caches are even more difficult to implement. The WG will pursue extensions to minimize the need for replay caching, optimize replay caching, and/or elide the need for replay caching. Prepare, review, and advance standards-track and informational specifications defining use of new cryptographic algorithms in the Kerberos protocol using the RFC3961 framework, on an ongoing basis. Cryptographic algorithms intended for standards track status must be of good quality, have broad international support, and fill a definite need. Prepare, review, and advance standards-track and informational specifications of new pre-authentication types for the Kerberos protocol, on an ongoing basis. Prepare, review, and advance standards track updates and extensions to RFC4121, as needed and on an ongoing basis. Goals and Milestones -------------------- Mar 2013 draft-ietf-kitten-sasl-oauth to IESG Mar 2013 draft-ietf-krb-wg-pkinit-alg-agility to IESG Apr 2013 draft-ietf-kitten-sasl-saml-ec to IESG Apr 2013 draft-ietf-krb-wg-iakerb to IESG May 2013 draft-ietf-kitten-gssapi-extensions-iana to IESG May 2013 draft-ietf-krb-wg-cammac to IESG Jun 2013 draft-ietf-kitten-kerberos-iana-registries to IESG Jun 2013 draft-ietf-krb-wg-pad to IESG Jul 2013 Adopt work on one or more items for GSS-API cred management Jul 2013 Adopt work on better error reporting in the GSS-API Aug 2013 Adopt work on exporting partially-established GSS-API contexts Aug 2013 draft-ietf-krb-wg-ticket-extensions to IESG Sep 2013 Adopt work on the GSS-API for replay cache avoidance Milestones: Jul 2011 - Submit SASL OpenID mechanism to the IESG as Proposed Standard Jul 2011 - Submit naming-exts to the IESG as Proposed Standard Jul 2011 - WGLC on gssapi-extensions-iana Aug 2011 - Submit SASL SAML mechanisms to the IESG as Proposed Standard Sep 2011 - Submit gssapi-extensions-iana to the IESG as Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Feb 12 14:01:10 2013 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 C81F921F8A64; Tue, 12 Feb 2013 14:01:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1360706470; bh=8Z+6YJyXvkW9rO7uWxElgWObK9JYeMFgWjfs1EZIxdw=; 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=y7/bfVvrnMvmdHMThiRPvRO/OauIiD8OKtEq1EHcoudm8Qyq+fJGZLaMcVt2AVELx c8GMbqYBEpCpBKvC8vduzlArOjy9ehRawGrPHQYZvEhUqDbeUuMSGG/cPOenj/4nsp nx7EHxYPC2SDRvNynobLw3CWa3zzWsXguwRlmP/o= 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 34A8121F8A67; Tue, 12 Feb 2013 14:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 DpjFWD9QfgUR; Tue, 12 Feb 2013 14:00:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3057621F8A61; Tue, 12 Feb 2013 14:00:53 -0800 (PST) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130212220053.32469.22467.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2013 14:00:53 -0800 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, 12 Feb 2013 14:12:39 -0800 Subject: [secdir] [new-work] REVISED WG Review: Web PKI OPS (wpkops) 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, 12 Feb 2013 22:01:11 -0000 A new IETF working group has been proposed in the Operations and Management Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-02-19. Web PKI OPS (wpkops) ------------------------------------------------ Current Status: Proposed Working Group Chairs: Tim Moses Assigned Area Director: Ronald Bonica Mailing list Address: wpkops@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/wpkops Archive: http://www.ietf.org/mail-archive/web/wpkops/ Charter of Working Group: The Web PKI is the set of systems, policies and procedures most commonly used, in conjunction with security protocols (e.g. TLS/SSL and OCSP), to protect the confidentiality, integrity and authenticity of communications between Web browsers and Web content servers. More specifically, the Web PKI (as considered here) consists of the fields included in the certificates issued to Web content and application providers by Certification Authorities (CAs), the certificate status services provided by the Authorities to Web browsers and their users, and the TLS/SSL protocol stacks embedded in web servers and browsers. The Web PKI first appeared in 1993 or thereabouts and has developed continuously in a somewhat organic fashion since then. Taking into account all the versions of Web servers and browsers that have been released in the intervening years, there are now hundreds of variations on the Web PKI in regular use. And this is a source of problems for end-users, certificate holders, and certificate issuers (CAs). For end-users (i.e. relying parties), there is no clear view whether certificate "problems" remain when they see indication of a "good" connection. For instance, in some browsers, a "good" indication is displayed when a "revoked" response has been received and "accepted" by the user, whereas other browsers refuse to display the contents under these circumstances. Many certificate holders are unsure which browser versions will reject their certificate if certain certificate profiles are not met, such as a subject public key that does not satisfy a minimum key size, or a certificate policies extension that does not contain a particular standard policy identifier. And for certificate issuers, it is difficult to predict whether a certificate chain with certain characteristics will be accepted. For instance, some browsers include a nonce in their OCSP requests and expect one in the corresponding responses, not all servers include a nonce in their replies, and this means some certificate chains will validate while others won't. Starting from the premise that more consistency in Web security behavior is desirable, a natural first step is to document current and historic browser and server behavior, including: the trust model on which they are based; the contents and processing of fields and extensions; the processing of the various revocation schemes; and how the TLS stack deals with PKI, including varying interpretations and implementation errors, as well as state changes visible to the user. Where appropriate, specific products and specific versions of those products will be identified. The effectiveness of the Web PKI depends critically upon decisions made by its users in response to information provided in the user interfaces of its various components. Therefore, such information should be accurate and complete, yet comprehensible. While recording the design details of the user interfaces of specific products is not necessary, state changes that are visible to, and/or controlled by, the user should be captured. Such a project has to be bounded. Therefore, only server-authentication behavior encountered in more than 0.1 percent of connections made by desktop and mobile browsers is to be considered. While it is not intended to apply the threshold with any precision, it will be used to justify the inclusion or exclusion of a technique. Future activities may attempt to prescribe how the Web PKI "should" work, and the prescription may turn out to be a proper subset of the PKIX PKI. However, that task is explicitly not a goal of the proposed working group. Instead, the group's goal is merely to describe how the Web PKI "actually" works in the set of browsers and servers that are in common use today. Additionally, a number of applications (such as client authentication, document signing, code signing, and email) often use the same trust anchors and certificate processing mechanisms as those used for Web server authentication. This reuse creates problems in some situations [1]. While these applications are outside the scope of this working group, deliverables should (wherever practical within the available expertise and time) identify mechanisms that are reused by other applications and identify the implications of that reuse. Also, the reliability of the Web PKI depends critically on the "practices" of its certificate issuers. These practices comprise how certificate issuers perform their functions and implement controls, and are described in documents known as "Certification Practice Statements" [2][3] and operational requirements documents [4][5]. However, the topic of certification practices is outside the scope of the working group. That there are technical shortcomings with Web PKI, as it is practiced today, is well recognized. And, that there is also some urgency in addressing these shortcomings is also well recognized. But, it is felt that too much haste can be counter-productive. The expectation is that the work of this group will bring to light, in a systematic way, aspects of the Web PKI that should be progressed in future working groups of the IETF's Security Area, and that Web servers, browsers and CAs will be willing to participate in those working groups and modify their products to comply with their standards. Given the urgency of the required developments and the scale of the task, it is agreed that adherence to the published schedule should take precedence over completeness of the results, without sacrificing technical correctness. Milestones ========== 1. First WG draft of "trust model" document (4 months). 2. First WG draft of "field and extension processing for certificates, CRLs, and OCSP responses" document (12 months). 3. First WG draft of "certificate revocation" document (8 months). 4. First WG draft of "TLS stack operation" document (8 months). 5. IESG submission of "trust model" document (16 months). 6. IESG submission of "field and extension processing for certificates, CRLs, and OCSP responses" document (24 months). 7. IESG submission of "certificate revocation" document (20 months). 8. IESG submission of "TLS stack operation" document (16 months). References: [1] https://www.ietf.org/mail-archive/web/wpkops/current/msg00104.html [2] Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. S. Chokhani et al, IETF RFC3647 https://tools.ietf.org/html/rfc3647 [3] Electronic Signatures and Infrastructures (ESI); Policy requirements for certification authorities issuing public key certificates. ETSI TS 102 042 V2.2.1 (2011- 12) http://www.etsi.org/deliver/etsi_ts/102000_102099/102042/02.02. 01_60/ts_102042v020201p.pdf [4] Network and certificate system security requirements, CA/Browser Forum, Aug 2012, https://www.cabforum.org/Network_Security_Controls_V1.pdf [5] Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates Version 1.0, CA/Browser Forum, Nov 2011, https://www.cabforum.org/Baseline_Requirements_V1.pdf Milestones: _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Wed Feb 13 14:49:49 2013 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 9E41A21E809C; Wed, 13 Feb 2013 14:49:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1360795789; bh=Pb6INvWTnAdYDXcXLRbd+8Vh3VwHY6p2VjYM4dKeStI=; 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=VtRGbiyB5WskWJDNCVORELtlDm8V5WQh8HhIfdlBrSyDxfJAM/SahMitk342cd8tp MxygJMp9Nbqyk+JC6bcv5Kug/9hT1w5+IOeHFzXSgqW82134omszFQBW1zKJiYcKLF IQ9my+Pp+ojplNT5S8RwvMt7eOZ90nS0FG3w2iz4= 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 489DB21E809C; Wed, 13 Feb 2013 14:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4NIoXfxr5T1; Wed, 13 Feb 2013 14:49:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A34521F86CB; Wed, 13 Feb 2013 14:49:48 -0800 (PST) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130213224948.3216.94880.idtracker@ietfa.amsl.com> Date: Wed, 13 Feb 2013 14:49:48 -0800 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 13 Feb 2013 14:50:43 -0800 Subject: [secdir] [new-work] REVISED WG Review: Web PKI OPS (wpkops) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 22:49:49 -0000 A new IETF working group has been proposed in the Operations and Management Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-02-20. Web PKI OPS (wpkops) ------------------------------------------------ Current Status: Proposed Working Group Chairs: Tim Moses Assigned Area Director: Ronald Bonica Mailing list Address: wpkops@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/wpkops Archive: http://www.ietf.org/mail-archive/web/wpkops/ Charter of Working Group: The Web Public Key Infrastructure (PKI) is the set of systems, policies, and procedures used to protect the confidentiality, integrity, and authenticity of communications between Web browsers and Web content servers. The Web PKI is used in conjunction with security protocols such as TLS/SSL and OCSP. More specifically, the Web PKI (as considered here) consists of the fields included in the certificates issued to Web content and application providers by Certification Authorities (CAs), the certificate status services provided by the Authorities to Web browsers and their users, and the TLS/SSL protocol stacks embedded in web servers and browsers. The Web PKI Operations (wpkops) working group will work to improve the consistency of Web security behavior. It will address the problems caused by the many hundreds of variations of the Web PKI currently in use: - For end-users (i.e. relying parties), there is no clear view of whether certificate "problems" remain once they see an indication of a "good" connection. For instance, in some browsers, a "good" indication is displayed when a "revoked" response has been received and "accepted" by the user, whereas other browsers refuse to display the contents under these circumstances. - Many certificate holders are unsure which browser versions will reject their certificate if certain certificate profiles are not met, such as a subject public key that does not satisfy a minimum key size, or a certificate policies extension that does not contain a particular standard policy identifier. - Certificate issuers (i.e., CAs) find it difficult to predict whether a certificate chain with certain characteristics will be accepted. For instance, some browsers include a nonce in their OCSP requests and expect one in the corresponding responses, not all servers include a nonce in their replies, and this means some certificate chains will validate while others won't. The working group's goal is to describe how the Web PKI "actually" works in the set of browsers and servers that are in common use today. To that end, the working group will document current and historic browser and server behavior. For each this will include: - The trust model on which it is based; - The contents and processing of fields and extensions; - The processing of the various revocation schemes; - How the TLS stack deals with PKI, including varying interpretations and implementation errors, as well as state changes visible to the user. - The state changes that are visible to and/or controlled by the user (to help predict the decisions that will be made the users and so determine the effectiveness of the Web PKI). - Identification of when Web PKI mechanisms are reused by other applications and implications of that reuse. Where appropriate, specific products and specific versions of those products will be identified, but recording the design details of the user interfaces of specific products is not necessary. Only server-authentication behavior encountered in more than 0.1 percent of connections made by desktop and mobile browsers is to be considered. While it is not intended to apply the threshold with any precision, it will be used to justify the inclusion or exclusion of a technique. A number of activities are outside the immedaiate scope of this working group, but might be considered in future re-chartering activity or included in the work of other working groups: - The working group will not work to describe how thw Web PKI "should work. - The working group will not examine the certification practices of certificate issuers. - The working group will not investigate applications (such as client authentication, document signing, code signing, and email) that often use the same trust anchors and certificate processing mechanisms as those used for Web server authentication. Given the urgency of the required developments and the scale of the task, it is agreed that adherence to the published milestones will take precedence over completeness of the results, without sacrificing technical correctness. Milestones ========== 1. First WG draft of "trust model" document (4 months). 2. First WG draft of "field and extension processing for certificates, CRLs, and OCSP responses" document (12 months). 3. First WG draft of "certificate revocation" document (8 months). 4. First WG draft of "TLS stack operation" document (8 months). 5. IESG submission of "trust model" document (16 months). 6. IESG submission of "field and extension processing for certificates, CRLs, and OCSP responses" document (24 months). 7. IESG submission of "certificate revocation" document (20 months). 8. IESG submission of "TLS stack operation" document (16 months). _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From kivinen@iki.fi Thu Feb 14 02:42:47 2013 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 23BAB21F86CC for ; Thu, 14 Feb 2013 02:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmKkJS5dWE2l for ; Thu, 14 Feb 2013 02:42:46 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E83021F85AF for ; Thu, 14 Feb 2013 02:42:43 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r1EAgdUl021018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Feb 2013 12:42:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r1EAgaqU000587; Thu, 14 Feb 2013 12:42:36 +0200 (EET) 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: <20764.49052.496549.658092@fireball.kivinen.iki.fi> Date: Thu, 14 Feb 2013 12:42:36 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min 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, 14 Feb 2013 10:42:47 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Charlie Kaufman is next in the rotation. For telechat 2013-02-21 Reviewer LC end Draft Shawn Emery T 2013-02-18 draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 Phillip Hallam-Baker T 2013-02-15 draft-ietf-paws-problem-stmt-usecases-rqmts-12 Steve Hanna T 2013-02-14 draft-ietf-simple-simple-08 David Harrington T 2013-02-20 draft-templin-intarea-seal-51 Matt Lepinski T 2013-01-25 draft-ietf-radext-radius-extensions-11 Sandy Murphy T 2013-01-29 draft-ietf-6man-nd-extension-headers-03 Vincent Roca T 2013-01-25 draft-ietf-eman-rfc4133bis-06 Tina TSOU T 2013-02-14 draft-gp-obsolete-icmp-types-iana-01 Carl Wallace T 2013-02-05 draft-ietf-behave-nat64-discovery-heuristic-13 David Waltermire T 2013-02-20 draft-shafranovich-mime-sql-04 Brian Weis T 2013-02-06 draft-ietf-mpls-tp-security-framework-08 Nico Williams T 2013-02-18 draft-templin-ironbis-12 For telechat 2013-02-28 Alan DeKok T 2013-02-28 draft-eastlake-additional-xmlsec-uris-09 Paul Hoffman T 2013-02-24 draft-cardenas-dff-09 Simon Josefsson T 2013-02-26 draft-ietf-tcpm-proportional-rate-reduction-04 Stephen Kent TR2013-02-25 draft-ietf-dhc-secure-dhcpv6-07 Last calls and special requests: Rob Austein 2013-03-06 draft-arkko-iesg-crossarea-03 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-05 Dan Harkins - draft-richardson-roll-applicability-template-01 Sam Hartman 2013-02-22 draft-ietf-idr-as-private-reservation-03 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Jeffrey Hutzelman 2013-02-27 draft-ietf-geopriv-flow-identity-01 Leif Johansson 2013-02-27 draft-ietf-mpls-gach-adv-06 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-09 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Eric Rescorla 2013-01-24 draft-ietf-ospf-ospfv3-iid-registry-update-02 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-03 Nico Williams - draft-ietf-httpbis-p5-range-21 Glen Zorn 2013-02-11 draft-ietf-mpls-tp-use-cases-and-design-06 -- kivinen@iki.fi From shanna@juniper.net Thu Feb 14 09:21:28 2013 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 27F1221F87AA; Thu, 14 Feb 2013 09:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdvAdS7wGGJq; Thu, 14 Feb 2013 09:21:27 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 5076E21F863F; Thu, 14 Feb 2013 09:21:27 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUR0dDGyhhZHEn1HIXLamQ31z8yskHQG1@postini.com; Thu, 14 Feb 2013 09:21:27 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 14 Feb 2013 09:18:59 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 14 Feb 2013 09:18:58 -0800 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.140) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 14 Feb 2013 09:27:39 -0800 Received: from mail88-db3-R.bigfish.com (10.3.81.246) by DB3EHSOBE009.bigfish.com (10.3.84.29) with Microsoft SMTP Server id 14.1.225.23; Thu, 14 Feb 2013 17:18:54 +0000 Received: from mail88-db3 (localhost [127.0.0.1]) by mail88-db3-R.bigfish.com (Postfix) with ESMTP id 75EA9160394; Thu, 14 Feb 2013 17:18:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -1 X-BigFish: PS-1(zz4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received: from mail88-db3 (localhost.localdomain [127.0.0.1]) by mail88-db3 (MessageSwitch) id 1360862332169077_28829; Thu, 14 Feb 2013 17:18:52 +0000 (UTC) Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.227]) by mail88-db3.bigfish.com (Postfix) with ESMTP id 249F8A007E; Thu, 14 Feb 2013 17:18:52 +0000 (UTC) Received: from SN2PRD0510HT005.namprd05.prod.outlook.com (157.56.234.117) by DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 14 Feb 2013 17:18:51 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.72]) by SN2PRD0510HT005.namprd05.prod.outlook.com ([10.255.116.40]) with mapi id 14.16.0263.000; Thu, 14 Feb 2013 17:18:48 +0000 From: Stephen Hanna To: The IESG , "secdir@ietf.org" , "draft-ietf-simple-simple.all@tools.ietf.org" Thread-Topic: secdir review for draft-ietf-simple-simple Thread-Index: Ac4K11jPA2hth1f7SJmGYyh0I+VW8A== Date: Thu, 14 Feb 2013 17:18:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [secdir] secdir review for draft-ietf-simple-simple 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, 14 Feb 2013 17:21: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 provides a guide to the many specifications related to SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions). The document is quite useful for people like me who know little about SIMPLE and would like to get a quick overview. Bravo to the authors! The Security Considerations section of the document states that "This specification is an overview of existing specifications, and does not introduce any security considerations on its own." I agree. I did notice one thing that may be a typo. Section 3.2 says: RFC 4975, The Message Session Relay Protocol (MSRP) (S): [RFC4975] defines a small text-based protocol for exchanging arbitrarily sized content of any time between users. I don't understand the words "of any time". Maybe they're supposed to say "of any kind"? Or "at any time"? Not a big deal but the text is confusing. Other than that little glitch, I think the document is ready to go. Thanks, Steve From Tina.Tsou.Zouting@huawei.com Thu Feb 14 14:42:56 2013 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 EE67121F86DD; Thu, 14 Feb 2013 14:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpLU0i1Z4gLX; Thu, 14 Feb 2013 14:42:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3393021F862E; Thu, 14 Feb 2013 14:42:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APS89586; Thu, 14 Feb 2013 22:42:53 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 14 Feb 2013 22:42:26 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 14 Feb 2013 22:42:37 +0000 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.165]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.007; Thu, 14 Feb 2013 14:42:33 -0800 From: Tina TSOU To: The IESG , "secdir@ietf.org" , "draft-gp-obsolete-icmp-types-iana@tools.ietf.org" Thread-Topic: Secdir review for draft-gp-obsolete-icmp-types-iana-01 Thread-Index: AQHOCwSUjNgLuml/IE+aB1xikNScig== Date: Thu, 14 Feb 2013 22:42:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [secdir] Secdir review for draft-gp-obsolete-icmp-types-iana-01 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, 14 Feb 2013 22:42:57 -0000 Dear all, 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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document looks good to me, ready for publication. Thank you, Tina From cpignata@cisco.com Thu Feb 14 15:05:48 2013 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 BBFCC21F8777; Thu, 14 Feb 2013 15:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTVZr4lnsWSq; Thu, 14 Feb 2013 15:05:46 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB2F21F8756; Thu, 14 Feb 2013 15:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=620; q=dns/txt; s=iport; t=1360883146; x=1362092746; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PIUq4moKx6kBgTy4vKgFJL2rd2yfr9tMMAsULjPpYGY=; b=i2oHgTIEmuWLeCGoK+x1mgiH56BGTPz6X7nQ9DRJOoUY1BbmFfilmsm3 DhCTW/UyF+oBFmPqvnNqBOkuYxUMJ1YFtGKtLYMjWzPMbwaKWUpMyvMgZ cjOmlSRw7CoW4Do5O6voO52OylD0NR3Cd+3bNGE3MGF/A7PzAOQZxEpUh g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYFABhtHVGtJV2b/2dsb2JhbABFhgK6VhZzgh8BAQEDATo/BQsCAQg2EDIlAgQOBYgMBr0ykSNhA5YkkFODBw X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; d="scan'208";a="177342332" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 14 Feb 2013 23:05:46 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1EN5kG0026873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Feb 2013 23:05:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Thu, 14 Feb 2013 17:05:45 -0600 From: "Carlos Pignataro (cpignata)" To: Tina TSOU Thread-Topic: Secdir review for draft-gp-obsolete-icmp-types-iana-01 Thread-Index: AQHOCwSUjNgLuml/IE+aB1xikNSciph5+Zr7 Date: Thu, 14 Feb 2013 23:05:45 +0000 Message-ID: <2CB59CA0-D253-42E9-BEFF-93F3BA673420@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-gp-obsolete-icmp-types-iana@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review for draft-gp-obsolete-icmp-types-iana-01 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, 14 Feb 2013 23:05:48 -0000 Thanks Tina! Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Feb 14, 2013, at 5:42 PM, "Tina TSOU" wro= te: > Dear all, > I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. These = comments were written primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments just like = any other last call comments. >=20 > This document looks good to me, ready for publication. >=20 > Thank you, > Tina >=20 From hartmans@mit.edu Fri Feb 15 04:38:51 2013 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 811D621F85BC; Fri, 15 Feb 2013 04:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.866 X-Spam-Level: X-Spam-Status: No, score=-102.866 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kabiP4-wA+Gb; Fri, 15 Feb 2013 04:38:51 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 01D5321F842B; Fri, 15 Feb 2013 04:38:49 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 972D32016B; Fri, 15 Feb 2013 07:34:20 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E7FCF43FD; Fri, 15 Feb 2013 07:38:46 -0500 (EST) From: Sam Hartman To: secdir@ietf.org Date: Fri, 15 Feb 2013 07:38:46 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: iesg@ietf.org Subject: [secdir] Secdir review of draft-ietf-idr-as-private-reservation-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 12:38:51 -0000 I reviewed this draft. It reserves a new range of private-use ASNs from the 4-octet range and updates the existing reservation from the 16-bit range. It's effectively just an IANA action. I believe the security implications of private-use ASNs are adequately documented elsewhere and really fall into the category of "mostly harmless". I see no issues. From jdrosen@jdrosen.net Sat Feb 16 04:33:00 2013 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 B233621F8756; Sat, 16 Feb 2013 04:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flR+cI6Af3sf; Sat, 16 Feb 2013 04:33:00 -0800 (PST) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1066921F8700; Sat, 16 Feb 2013 04:33:00 -0800 (PST) Received: from mail-wg0-f52.google.com ([74.125.82.52]:36361) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1U6gwt-0002JF-3W; Sat, 16 Feb 2013 07:32:59 -0500 Received: by mail-wg0-f52.google.com with SMTP id 12so3515784wgh.7 for ; Sat, 16 Feb 2013 04:32:58 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.76.7 with SMTP id g7mr9456882wjw.50.1361017978807; Sat, 16 Feb 2013 04:32:58 -0800 (PST) Received: by 10.194.165.230 with HTTP; Sat, 16 Feb 2013 04:32:58 -0800 (PST) In-Reply-To: References: Date: Sat, 16 Feb 2013 07:32:58 -0500 Message-ID: From: Jonathan Rosenberg To: Stephen Hanna Content-Type: multipart/alternative; boundary=047d7beba20228e4c504d5d6b1b6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Sat, 16 Feb 2013 04:33:33 -0800 Cc: "draft-ietf-simple-simple.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review for draft-ietf-simple-simple X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 12:33:00 -0000 --047d7beba20228e4c504d5d6b1b6 Content-Type: text/plain; charset=ISO-8859-1 Thanks Stephen for the comments. Great catch on the typo. It is indeed supposed to say, "of any kind" and has been fixed. Thanks, Jonathan R. On Thu, Feb 14, 2013 at 12:18 PM, Stephen Hanna 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 provides a guide to the many specifications related to > SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions). > The document is quite useful for people like me who know little about > SIMPLE and would like to get a quick overview. Bravo to the authors! > > The Security Considerations section of the document states that > "This specification is an overview of existing specifications, and > does not introduce any security considerations on its own." I agree. > > I did notice one thing that may be a typo. Section 3.2 says: > > RFC 4975, The Message Session Relay Protocol (MSRP) (S): [RFC4975] > defines a small text-based protocol for exchanging arbitrarily > sized content of any time between users. > > I don't understand the words "of any time". Maybe they're supposed > to say "of any kind"? Or "at any time"? Not a big deal but the text > is confusing. > > Other than that little glitch, I think the document is ready to go. > > Thanks, > > Steve > > > -- Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net http://www.jdrosen.net --047d7beba20228e4c504d5d6b1b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Stephen for the comments. Great catch on the typo. = It is indeed supposed to say, "of any kind" and has been fixed.
Thanks,
Jonathan R.


On Thu, Feb 14, 2013 at 12:18 PM, Stephe= n Hanna <shanna@juniper.net> wrote:
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. =A0These comments were written primarily for the benefit of the
security area directors. =A0Document editors and WG chairs should treat
these comments just like any other last call comments.

This document provides a guide to the many specifications related to
SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions).
The document is quite useful for people like me who know little about
SIMPLE and would like to get a quick overview. Bravo to the authors!

The Security Considerations section of the document states that
"This specification is an overview of existing specifications, and
does not introduce any security considerations on its own." I agree.
I did notice one thing that may be a typo. Section 3.2 says:

=A0 =A0RFC 4975, The Message Session Relay Protocol (MSRP) (S): =A0[RFC4975= ]
=A0 =A0 =A0 defines a small text-based protocol for exchanging arbitrarily<= br> =A0 =A0 =A0 sized content of any time between users.

I don't understand the words "of any time". Maybe they're= supposed
to say "of any kind"? Or "at any time"? Not a big deal = but the text
is confusing.

Other than that little glitch, I think the document is ready to go.

Thanks,

Steve





--
--047d7beba20228e4c504d5d6b1b6-- From leifj@sunet.se Mon Feb 18 05:08:22 2013 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 B5E2021F8835; Mon, 18 Feb 2013 05:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRDqJB5G2Odv; Mon, 18 Feb 2013 05:08:22 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id CB9EE21F87A5; Mon, 18 Feb 2013 05:08:21 -0800 (PST) Received: from [192.36.125.238] (dhcp.pilsnet.sunet.se [192.36.125.238] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id r1ID8FU6006784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2013 14:08:17 +0100 (CET) Message-ID: <512227BF.6050207@sunet.se> Date: Mon, 18 Feb 2013 14:08:15 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "secdir@ietf.org" , draft-ietf-mpls-gach-adv.all@tools.ietf.org, "iesg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-ietf-mpls-gach-adv-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, 18 Feb 2013 13:08:22 -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 technology is somewhat outside my area of expertise but I found the document relatively easy to follow anyway. I'm a fan of writing crypto-related algorithms with very little left for the imagination of the reader. To that end I would strongly suggest specifying what goes into the GAP message hash even more clearly. In this case I suspect the intent is that the inner hash is over all bytes of GAP message except the GAP authentication TLV which is added to the message _after_ the hash is computed. Conversely the validation phase needs to clearly say what bits of the message are to be included in computing the hash. Also I would change the timestamp verification step to use normative language, eg: "... the receiver MUST, upon successfully authenticating a message verify that the timestamp field corresponds... The receiver MUST silently discard a GAP message that fails timestamp verification." From danfrost@cisco.com Mon Feb 18 06:31:47 2013 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 7FBDB21F8A2F; Mon, 18 Feb 2013 06:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAhDte98xLPa; Mon, 18 Feb 2013 06:31:45 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B421421F8A14; Mon, 18 Feb 2013 06:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2668; q=dns/txt; s=iport; t=1361197905; x=1362407505; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=WpagxTaNX9dBuN8jXMsA8s5mjGbRU48GsvzSPH6yR2M=; b=hvyEBV7RDBmEPilAzsF0XIQH133+ol4Q45MH3fAkyodp8o8vDVN+A1xn 5YXIVubEJVQTQl09a7IBgm4+gjht+seudK7ZN2ckLOn/KNQBsGBebE1Cr HO2gag6YPXVGKZM6FmCipLxhyk8a8lh6QNx7axfCdsaBxguhkPuKNcuqT I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADo6IlGtJXG+/2dsb2JhbABFwCOBAxZzgh8BAQEDAToxDgULCxgJJQ8FSYgfBsBDjzcHgl9hA5YrAZBYgweBayQ X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; d="scan'208";a="175311582" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 18 Feb 2013 14:31:45 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [10.83.106.70]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1IEVi6c008865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2013 14:31:45 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id r1IEVgW9029648; Mon, 18 Feb 2013 09:31:44 -0500 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id r1IEVgSK029647; Mon, 18 Feb 2013 14:31:42 GMT Date: Mon, 18 Feb 2013 14:31:42 +0000 From: Dan Frost To: Leif Johansson Message-ID: <20130218143142.GA26032@cisco.com> References: <512227BF.6050207@sunet.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <512227BF.6050207@sunet.se> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: draft-ietf-mpls-gach-adv.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-mpls-gach-adv-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, 18 Feb 2013 14:31:47 -0000 Hi Leif, On Mon, Feb 18, 2013 at 02:08:15PM +0100, Leif Johansson 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 technology is somewhat outside my area of expertise but I found > the document relatively easy to follow anyway. Thanks for your review. > I'm a fan of writing crypto-related algorithms with very little left > for the imagination of the reader. To that end I would strongly suggest > specifying what goes into the GAP message hash even more clearly. > > In this case I suspect the intent is that the inner hash is over all > bytes of GAP message except the GAP authentication TLV which is added > to the message _after_ the hash is computed. No need to suspect; the current text is explicit. ;) It says: 2. First Hash First, the Authentication Data field is filled with the value Apad. Then, a first hash, also known as the inner hash, is computed as follows: First-Hash = H(Ko XOR Ipad || (GAP Message)) Here the GAP Message is the portion of the packet that follows the Associated Channel Header. The last paragraph specifies that the hash is computed over all bytes of the GAP Message that follow the Associated Channel Header. This includes the Authentication TLV, which is not a problem because "First, the Authentication Data field is filled with the value Apad." > Conversely the validation phase needs to clearly say what bits of the > message are to be included in computing the hash. The text states that "When the message is received, the receiver computes a hash for it as described below", where "below" is Section 6.3 (we should probably s/below/Section 6.3/ here). In other words, the transmitter and receiver perform the same computation with the same input (modulo the Authentication Data field, which is normalised by the computation itself). > Also I would change the timestamp verification step to use normative > language, eg: "... the receiver MUST, upon successfully authenticating > a message verify that the timestamp field corresponds... The receiver > MUST silently discard a GAP message that fails timestamp verification." Well, use of the replay mitigation mechanism is not required, so I'm not sure that adding "MUST" language is appropriate. Cheers, -d From leifj@sunet.se Mon Feb 18 07:07:34 2013 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 A0C0E21F87AD; Mon, 18 Feb 2013 07:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxQqaRTaGaDy; Mon, 18 Feb 2013 07:07:33 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 9575B21F875C; Mon, 18 Feb 2013 07:07:32 -0800 (PST) Received: from [10.33.3.161] ([212.247.15.226]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id r1IF7NKL024283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2013 16:07:26 +0100 (CET) Message-ID: <512243AB.7000400@sunet.se> Date: Mon, 18 Feb 2013 16:07:23 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Dan Frost References: <512227BF.6050207@sunet.se> <20130218143142.GA26032@cisco.com> In-Reply-To: <20130218143142.GA26032@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-mpls-gach-adv.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-mpls-gach-adv-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, 18 Feb 2013 15:07:34 -0000 On 02/18/2013 03:31 PM, Dan Frost wrote: > Hi Leif, > > On Mon, Feb 18, 2013 at 02:08:15PM +0100, Leif Johansson 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 technology is somewhat outside my area of expertise but I found >> the document relatively easy to follow anyway. > Thanks for your review. > >> I'm a fan of writing crypto-related algorithms with very little left >> for the imagination of the reader. To that end I would strongly suggest >> specifying what goes into the GAP message hash even more clearly. >> >> In this case I suspect the intent is that the inner hash is over all >> bytes of GAP message except the GAP authentication TLV which is added >> to the message _after_ the hash is computed. > No need to suspect; the current text is explicit. ;) It says: > > 2. First Hash > > First, the Authentication Data field is filled with the value > Apad. > > Then, a first hash, also known as the inner hash, is computed > as follows: > > First-Hash = H(Ko XOR Ipad || (GAP Message)) > > Here the GAP Message is the portion of the packet that follows > the Associated Channel Header. > > The last paragraph specifies that the hash is computed over all bytes of > the GAP Message that follow the Associated Channel Header. This > includes the Authentication TLV, which is not a problem because "First, > the Authentication Data field is filled with the value Apad." if you would just add that last sentence it would have been that much clearer to me at least. > >> Conversely the validation phase needs to clearly say what bits of the >> message are to be included in computing the hash. > The text states that "When the message is received, the receiver > computes a hash for it as described below", where "below" is Section 6.3 > (we should probably s/below/Section 6.3/ here). In other words, the > transmitter and receiver perform the same computation with the same > input (modulo the Authentication Data field, which is normalised by the > computation itself). So in the verification phase you first fill the Authentication Data field with Apad? That wasn't clear to me from reading the text. > >> Also I would change the timestamp verification step to use normative >> language, eg: "... the receiver MUST, upon successfully authenticating >> a message verify that the timestamp field corresponds... The receiver >> MUST silently discard a GAP message that fails timestamp verification." > Well, use of the replay mitigation mechanism is not required, so I'm not > sure that adding "MUST" language is appropriate. I guess I'm then questioning the judgement of not making replay checking a requirement since it seems fairly simple to do. > > Cheers, > -d > From turners@ieca.com Tue Feb 19 09:01:03 2013 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 C004921F8E32 for ; Tue, 19 Feb 2013 09:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.685 X-Spam-Level: X-Spam-Status: No, score=-100.685 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OSxmBs8hHfM for ; Tue, 19 Feb 2013 09:01:03 -0800 (PST) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.22.93]) by ietfa.amsl.com (Postfix) with ESMTP id CD12921F8DEB for ; Tue, 19 Feb 2013 09:01:02 -0800 (PST) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 5A0C8742F9E5A; Tue, 19 Feb 2013 11:01:01 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 28FD7742F9D0B for ; Tue, 19 Feb 2013 11:01:01 -0600 (CST) Received: from [108.45.16.214] (port=49569 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1U7qYu-0001yu-Es for secdir@ietf.org; Tue, 19 Feb 2013 11:01:00 -0600 Message-ID: <5123AFCB.8090804@ieca.com> Date: Tue, 19 Feb 2013 12:00:59 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: (thunderfish.local) [108.45.16.214]:49569 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [secdir] secdir lunch details 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, 19 Feb 2013 17:01:03 -0000 We've been assigned a room at our usual Tuesday lunch time: Assigned Room: Caribbean 7 Assigned Date: 03/12/2013 Assigned Start Time: 11:30:00 At this point, I'm unsure what lunch options are available. spt From vincent.roca@inria.fr Tue Feb 19 12:34:58 2013 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 80F5621F8856; Tue, 19 Feb 2013 12:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.138 X-Spam-Level: X-Spam-Status: No, score=-110.138 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3ammZKlnocC; Tue, 19 Feb 2013 12:34:58 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id 91F9021F87B6; Tue, 19 Feb 2013 12:34:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,697,1355094000"; d="scan'208";a="3607439" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.114]) ([82.236.155.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 19 Feb 2013 21:34:55 +0100 From: Vincent Roca Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 19 Feb 2013 19:27:26 +0100 Message-Id: <0F853B07-BBF2-462A-9081-F67DB87BCADA@inria.fr> To: IESG , draft-ietf-eman-rfc4133bis.all@tools.ietf.org, secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [secdir] Secdir review of draft-ietf-eman-rfc4133bis-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: Tue, 19 Feb 2013 20:34:58 -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 document is an update of RFC4311. It therefore inherits, updates and improves the security considerations section of that RFC. This section seems well written and accurate. I just have a small comment. I see there's a wide range of techniques to secure communication with MIBs. This document specifies a Mandatory To Implement solution (USM with AES), mentions a SHOULD support solution (security features of RFC3410), as well as a MAY support approach (TSM with SSH/TLS).That's a lot. I imagine there are good reasons (I don't know the SNMP/MIB domain) to do that... Cheers, Vincent From turners@ieca.com Tue Feb 19 12:40:50 2013 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 B6D9021F8C12 for ; Tue, 19 Feb 2013 12:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.921 X-Spam-Level: X-Spam-Status: No, score=-101.921 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IUNajaUdWUZ for ; Tue, 19 Feb 2013 12:40:50 -0800 (PST) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.56.236.29]) by ietfa.amsl.com (Postfix) with ESMTP id 52EC221F8C10 for ; Tue, 19 Feb 2013 12:40:50 -0800 (PST) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id C790D66321144; Tue, 19 Feb 2013 14:40:49 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway08.websitewelcome.com (Postfix) with ESMTP id A9FD0663210AD for ; Tue, 19 Feb 2013 14:40:49 -0600 (CST) Received: from [108.45.16.214] (port=51215 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1U7tzd-0003Ff-HE; Tue, 19 Feb 2013 14:40:49 -0600 Message-ID: <5123E350.4040809@ieca.com> Date: Tue, 19 Feb 2013 15:40:48 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: (thunderfish.local) [108.45.16.214]:51215 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 11 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: Ralph Droms Subject: [secdir] volunteer for draft-rafiee-intarea-cga-tsig 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, 19 Feb 2013 20:40:50 -0000 Anybody interested in CGAs that would like to review this one for Ralph? spt From bclaise@cisco.com Tue Feb 19 13:16:48 2013 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 49C4721F87E4; Tue, 19 Feb 2013 13:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.541 X-Spam-Level: X-Spam-Status: No, score=-10.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egwi9cLSBnDA; Tue, 19 Feb 2013 13:16:47 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id F12B821F87E0; Tue, 19 Feb 2013 13:16:46 -0800 (PST) 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 r1JLGj5D024328; Tue, 19 Feb 2013 22:16:45 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1JLFssS001318; Tue, 19 Feb 2013 22:16:15 +0100 (CET) Message-ID: <5123EB8A.6030805@cisco.com> Date: Tue, 19 Feb 2013 22:15:54 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Vincent Roca References: <0F853B07-BBF2-462A-9081-F67DB87BCADA@inria.fr> In-Reply-To: <0F853B07-BBF2-462A-9081-F67DB87BCADA@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-eman-rfc4133bis.all@tools.ietf.org, IESG , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-eman-rfc4133bis-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: Tue, 19 Feb 2013 21:16:48 -0000 Hi Vincent, Thanks for your review. See in line > 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 document is an update of RFC4311. It therefore inherits, updates > and improves the security considerations section of that RFC. > This section seems well written and accurate. I just have a small comment. > > I see there's a wide range of techniques to secure communication with MIBs. > This document specifies a Mandatory To Implement solution (USM with AES), > mentions a SHOULD support solution (security features of RFC3410), as well > as a MAY support approach (TSM with SSH/TLS).That's a lot. > I imagine there are good reasons (I don't know the SNMP/MIB domain) to do > that... This comes from http://www.ietf.org/iesg/directorate/mib-doctors.html -> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security Regards, Benoit > > > Cheers, > > Vincent > > From paul.hoffman@vpnc.org Tue Feb 19 13:40:36 2013 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 EC87C21E8064 for ; Tue, 19 Feb 2013 13:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU-MIxyne35G for ; Tue, 19 Feb 2013 13:40:36 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 548BB21E8050 for ; Tue, 19 Feb 2013 13:40:36 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1JLeYJM050254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 19 Feb 2013 14:40:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <308C8DD6-3F66-453A-9AE3-C6C8DA5F3E96@vpnc.org> Date: Tue, 19 Feb 2013 13:40:34 -0800 To: secdir Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [secdir] Secdir review of draft-cardenas-dff 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, 19 Feb 2013 21:40:37 -0000 Greetings again. draft-cardenas-dff, "Depth-First Forwarding in = Unreliable Networks (DFF)", describes an experimental protocol that lets = the network try to heal routing problems with messages in the data plane = (instead of in the control plane). The protocol will change the routing = of future packets in a way very similar to routing changes do today. The security considerations section seems complete well thought-out. = Basically, it says "content of redirected packets is out of scope, as is = upper-layer security", which seems fine. It discusses the main concerns, = which is this protocol making some denial-of-service attacks a bit = easier, and does so fairly completely. --Paul Hoffman= From dbharrington@comcast.net Tue Feb 19 15:28:00 2013 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 AE99A21F877A for ; Tue, 19 Feb 2013 15:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvX5YlEsz-cf for ; Tue, 19 Feb 2013 15:28:00 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 65DC121F8771 for ; Tue, 19 Feb 2013 15:27:59 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta15.westchester.pa.mail.comcast.net with comcast id 2PQC1l00517dt5G5FPTyUP; Tue, 19 Feb 2013 23:27:58 +0000 Received: from JV6RVH1 ([71.233.85.150]) by omta13.westchester.pa.mail.comcast.net with comcast id 2PTx1l00g3Ecudz3ZPTyEa; Tue, 19 Feb 2013 23:27:58 +0000 From: "David Harrington" To: , Date: Tue, 19 Feb 2013 18:27:36 -0500 Message-ID: <00cb01ce0ef8$b3cc6c00$1b654400$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4O7BlKKbPyA+c4TYSxJNkgdU4/gg== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361316478; bh=VNtLHJ+vyhhV95JtU1KfWFQy/xdXHxYdOh6V1TVBn6s=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=fG2GdW2PaxuvK62pAkCoI0E85bNwdVSgjCl6L+4p1jfC0TV/HowmtQRjfeT2WW73n QQdmyN4HJ6wnDHM4Fbs9AiKIk0j+VTabbTB3ZJ3QJ4YPDPrr2czxBqbkmQGp7uBkIU zbJLb17XDRkOPYEJxtFrOX8W0KPd/+fqYRfT2nUivl0Eh/RbvXwMzhugr4HtVPCbmy 5S9++jYqNbRH3LwBK0GX6LIFQDdfDp6p0YY3y9DR74x5VoGHIbeJpVDP/O7qdYIsI+ D3jJB89H/EFpSIL2cCgiLWkCeiEbYdo0gt7WuSDv9E3xt1dCnr6qjUf2+NR2OMGbxw dJryGgKFpd0PA== Cc: secdir@ietf.org Subject: [secdir] secdir review of draft-templin-intarea-seal 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, 19 Feb 2013 23:28:00 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. -- This document is an individual submission in the INT area, and obsoletes RFC5320, which was published as Experimental in the ISE stream. RC5320 contains an IESG Note, saying the decision to publish is not based on IETF review for things like security. This document is being published as Informational, not Standards-track. I do not consider my security review as thorough as a standards-track doc might deserve. SEAL is the Subnetwork Encapsulation and Adaptation Layer. It is a layer between the (IP and transport headers) and the content being sent (so it is between the Transport layer and the Application layer). Its goal is to provide a virtual topology overlay using content encapsulation between a point in the network that serves as a SEAL ingress point and another point in the tunnel that serves as a Seal egress point, over a multiple-hop physical or virtual network topology. The SEAL protocol addresses issues relating to MTU consistency, detection of duplicate packets and packet reordering, segment-to-segment data origin authentication, segment-to-segment packet header integrity and anti-replay. The document also defines a control message protocol that addresses issues with use of ICMP, where ICMP might be impacted by middleboxes, among other things. These specifications are meant to supplement IP's end-to-end message integrity checking, authentication and confidentiality. The document appears well-written, clear, and unambiguous. The security considerations section is short (only 4 paragraphs) but describes what security issues SEAL is meant to address, and which issues it is not meant to address. The Security Considerations section discusses some possible attacks and ways to mitigate them. The security features of SEAL are discussed throughout the document. I feel the security considerations section is reasonable. I have a few concerns, most not related to security, and the Security Ads can decide whether they feel these are important to address: 1) The document defines what is effectively SEALv2 to obsolete the SEALv1 defined in RFC5320. SEALv1 had no version field; SEALv2 adds a version field. It is unclear to me whether there are issues of deploying implementations of both versions in the same network. The two versions have significant differences, described in section 1.3, which show these are quite different protocols, not just a minor evolution. Since v1 was never supposed to be deployed, this may not be an issue. 2) The identification and Integrity check fields are optional (section 5.3), and without these fields SEAL doesn't seem to address important security issues). It does still provide for MTU consistency, segmentation, etc., but not security. 3) in 5.4.3, it states that the ITE (ingress point) may maintain packet sizing variables per ETE (egress point), rather than per SEAL path. It doesn't discuss in detail the implications of this decision, nor how it might impact interoperability or performance. The existing discussion might be enough, but the discussion is very short. 4) There are a couple places where IDs are referenced, and it is unclear whether it should be normative or informative, and what effect the completion of the ID would have on the SEAL protocol. The most notable for me was section 5.4.5, which references draft-ietf-6man-udpzero. This document says set the checksum to 0, and points to the draft for additional considerations. It is unclear whether SEAL implementations are expected to change when udpzero gets published or not. This might impact interoperability, if some set the checksum to 0 and other implementations do not. Of course, this document is only informational, so normative might not be important. 5) section 5.4.7 suggests taking some ICMP messages as "hints". I wonder if using these as hints, or not, might impact interoperability. 6) In 5.5.4, there is mention of the window of acceptable values. I wonder if a recommended default, or a default algorithm for determining window size is appropriate. 7) In 5.6.2.1, an ITE should "only process the message if it is able to recognize the packet as one it had previously set." This seems a bit loose to me, and I wonder if it could be tightened up. 8) The IANA Considerations requests IANA to assign a user port and an IP protocol number. RFC5320 used experimental values from ranges defined in RFC3692 and RFC4727, for experimentation only, and not to be used in any deployments or shipped products. Having IANA assign values is a significant change, presumably appropriate since this is being published as an individual submission rather than experimental. I wanted the Ads to be aware of this change. Hope this helps. David Harrington ietfdbh@comcast.net +1-603-828-1401 From hartmans@mit.edu Tue Feb 19 15:39:15 2013 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 4353E21F887F for ; Tue, 19 Feb 2013 15:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.834 X-Spam-Level: X-Spam-Status: No, score=-102.834 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncP-PhtitbGN for ; Tue, 19 Feb 2013 15:39:14 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 944B921F87EE for ; Tue, 19 Feb 2013 15:39:14 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id CD19920161; Tue, 19 Feb 2013 18:34:35 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A0A5A440A; Tue, 19 Feb 2013 18:39:07 -0500 (EST) From: Sam Hartman To: Sean Turner References: <5123E350.4040809@ieca.com> Date: Tue, 19 Feb 2013 18:39:07 -0500 In-Reply-To: <5123E350.4040809@ieca.com> (Sean Turner's message of "Tue, 19 Feb 2013 15:40:48 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Ralph Droms , secdir@ietf.org Subject: Re: [secdir] volunteer for draft-rafiee-intarea-cga-tsig 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, 19 Feb 2013 23:39:15 -0000 I took a look at draft-rafiee-intarea-cga-tsig. The idea is generally sound although I did not fully debug the algorithm as discussed below. Unfortunately, the draft needs a lot of work before it's ready. Comments: Section 3 contains a number of claims regarding protecting the exchanges between the resolver and client. Is tsig actually used for DNS resolution or just for update/zone transfer? Section 3 should be reviewed to determine whether all the use cases are in fact applicable for use of tsig. The draft really needs help from someone with an eye towards abstraction. Section 4 repeates much of the key generation from the CGA specification and repeats a lot of detail from the TSIG specification as well. The rest of the draft tends to suffer from this as well. Unfortunately, that approach--repeating (and sometimes changing) text from CGA and TSIG is highly problematic. It makes it hard to evaluate correctness of this specification and to identify all the differences between this specification and the existing specifications. In addition, it makes it hard to understand how this specification might interact with existing extensions to CGAs and existing or future extensions to DNS-TSIG. Please ask someone from the DNS community to review the shortening of the TSIG exchange and the removal of the TKEY RR type. The general textual clarity could be significantly improved. I don't think this draft is ready for adoption, but I do think that the ideas expressed here could be a valid basis for future work. --Sam From turners@ieca.com Tue Feb 19 16:04:04 2013 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 C494921F87A5 for ; Tue, 19 Feb 2013 16:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.078 X-Spam-Level: X-Spam-Status: No, score=-102.078 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTFZBKrPQlLQ for ; Tue, 19 Feb 2013 16:04:04 -0800 (PST) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.196.21]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE3D21F8750 for ; Tue, 19 Feb 2013 16:04:04 -0800 (PST) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id DD770A0416E; Tue, 19 Feb 2013 18:04:03 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id C56A8A040DA for ; Tue, 19 Feb 2013 18:04:03 -0600 (CST) Received: from [108.45.16.214] (port=51846 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1U7xAJ-0000iY-IJ; Tue, 19 Feb 2013 18:04:03 -0600 Message-ID: <512412F2.1070701@ieca.com> Date: Tue, 19 Feb 2013 19:04:02 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Sam Hartman References: <5123E350.4040809@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: (thunderfish.local) [108.45.16.214]:51846 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: Ralph Droms , secdir@ietf.org Subject: Re: [secdir] volunteer for draft-rafiee-intarea-cga-tsig 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, 20 Feb 2013 00:04:04 -0000 Sam, Many thanks! spt On 2/19/13 6:39 PM, Sam Hartman wrote: > I took a look at draft-rafiee-intarea-cga-tsig. > > The idea is generally sound although I did not fully debug the algorithm > as discussed below. Unfortunately, the draft needs a lot of work before > it's ready. > > Comments: > > Section 3 contains a number of claims regarding protecting the exchanges > between the resolver and client. Is tsig actually used for DNS > resolution or just for update/zone transfer? > Section 3 should be reviewed to determine whether all the use cases are > in fact applicable for use of tsig. > > The draft really needs help from someone with an eye towards > abstraction. > Section 4 repeates much of the key generation from the CGA specification > and repeats a lot of detail from the TSIG specification as well. > The rest of the draft tends to suffer from this as well. > > Unfortunately, that approach--repeating (and sometimes changing) text > from CGA and TSIG is highly problematic. It makes it hard to evaluate > correctness of this specification and to identify all the differences > between this specification and the existing specifications. In > addition, it makes it hard to understand how this specification might > interact with existing extensions to CGAs and existing or future > extensions to DNS-TSIG. > > Please ask someone from the DNS community to review the shortening of > the TSIG exchange and the removal of the TKEY RR type. > > The general textual clarity could be significantly improved. > > I don't think this draft is ready for adoption, but I do think that the > ideas expressed here could be a valid basis for future work. > > --Sam > From fltemplin@yahoo.com Tue Feb 19 16:31:23 2013 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 B426C21F8878 for ; Tue, 19 Feb 2013 16:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzOOQKIMgIQc for ; Tue, 19 Feb 2013 16:31:22 -0800 (PST) Received: from nm33-vm7.bullet.mail.bf1.yahoo.com (nm33-vm7.bullet.mail.bf1.yahoo.com [72.30.239.207]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA2A21F87FF for ; Tue, 19 Feb 2013 16:31:21 -0800 (PST) Received: from [98.139.212.151] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 20 Feb 2013 00:31:21 -0000 Received: from [98.139.212.250] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 20 Feb 2013 00:31:21 -0000 Received: from [127.0.0.1] by omp1059.mail.bf1.yahoo.com with NNFMP; 20 Feb 2013 00:31:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 139134.75434.bm@omp1059.mail.bf1.yahoo.com Received: (qmail 45606 invoked by uid 60001); 20 Feb 2013 00:31:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361320280; bh=287KGpQIlnoPCKHfYGl/apT+CIhC0QLSNU5tSYqJTiY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eVh1m+h0FFntsR+WQDkN+tq5WVhTq8Zm4PTa2aka3HFHTxWcaCHqOjCukZtYaICw5RgxhlnXxzLkfbrgvpfalJj3/x/t4eYWUAHjHZOzFMPPMszRnzYJjqVhcRpjpOcESfoI9Hr1RJ/+SWMlQtBpZarNVLzuuoYORR93GjFdEYk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5yoJBcaXvxIAdOE2T2MteonzgcDuwcZfvyQamp5OhFBKU9OIOihZYine0WBavg5XBXO1Uz1ihy0ldjq71KX4Lp8Lk4MBRZmoSzXmaksED61TDQLIyFP4gxtC185E+Ry7U9UtUJPuEtqq8OtFFCR/3a0fEpzzMa1PfSZERo+dZFs=; X-YMail-OSG: chik7SoVM1mq3X_kJ9jQOBDRzNHT2NoLsBHqpg.V2qh_sHM BPgKYcNIougTbCJsZfsYwP2UN9dHkDKYqpiblLH62ca63MgwU42rWwjRZMBm .0xcP8yGcI9GY.NQwn5L0FQwMBAdHwm3NjuhDLFC7xIaJ27QSDRqe.zI.B5X Cv6TQYcs1OWP6XiZ7UrkC_xxQFRstKlswG1uxZU8E9yrgZNhlZdMFLMpYGnr .WnAAU3tyMbRhR_15slQU4YZ64U1gBZn7P1XPTv.1hwDgT4qXZYCCtDRaE9T SKzROUpVW.klZZkKIldVMZjz1Bo49C6zk9Uob0gClQmyYEHIwFottQodcZG6 3VkUnLISs3HwK3G74zt8fGhKuUSny2RJW8bvUMG34p8gTD1fUCNhmneqaJ28 GlLG_Jj2EMJD.WGkgU2S2uB_R89jYL_7mNn3ypMbvJxXZfxV8EQrJqX.XDVh axsqIB6YtBJltZvaa8SYZSK6q0unY89irxNdmKnAPs5pNsDaaMM2j8DVapld ePBInCfiG0Zw0IBM- Received: from [130.76.32.40] by web161903.mail.bf1.yahoo.com via HTTP; Tue, 19 Feb 2013 16:31:19 PST X-Rocket-MIMEInfo: 001.001, SGkgRGFuLAoKVGhhbmsgeW91ciBmb3IgbG9va2luZyBvdmVyIHRoZSBkb2N1bWVudCBhbmQgc2VuZGluZyB0aGVzZSB1c2VmdWwgY29tbWVudHMuClBsZWFzZSBzZWUgYmVsb3cgZm9yIHJlc3BvbnNlczoKClJlZ2FyZHMgLSBGcmVkCmZsdGVtcGxpbkBhY20ub3JnCgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBEYXZpZCBIYXJyaW5ndG9uIDxkYmhhcnJpbmd0b25AY29tY2FzdC5uZXQ.Cj4gVG86IGRyYWZ0LXRlbXBsaW4taW50YXJlYS1zZWFsQHRvb2xzLmlldGYub3JnOyBpZXNnQGkBMAEBAQE- X-RocketYMMF: fltemplin X-Mailer: YahooMailWebService/0.8.134.513 References: <00cb01ce0ef8$b3cc6c00$1b654400$@comcast.net> Message-ID: <1361320279.44986.YahooMailNeo@web161903.mail.bf1.yahoo.com> Date: Tue, 19 Feb 2013 16:31:19 -0800 (PST) From: "Fred L. Templin" To: David Harrington , "draft-templin-intarea-seal@tools.ietf.org" , "iesg@ietf.org" In-Reply-To: <00cb01ce0ef8$b3cc6c00$1b654400$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 19 Feb 2013 16:35:08 -0800 Cc: "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-templin-intarea-seal 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: Wed, 20 Feb 2013 00:31:23 -0000 Hi Dan,=0A=0AThank your for looking over the document and sending these use= ful comments.=0APlease see below for responses:=0A=0ARegards - Fred=0Afltem= plin@acm.org=0A=0A=0A=0A----- Original Message -----=0A> From: David Harrin= gton =0A> To: draft-templin-intarea-seal@tools.ie= tf.org; iesg@ietf.org=0A> Cc: secdir@ietf.org=0A> Sent: Tuesday, February 1= 9, 2013 3:27 PM=0A> Subject: secdir review of draft-templin-intarea-seal=0A= > =0A> Hi,=0A> =0A> I have reviewed this document as part of the security d= irectorate's ongoing=0A> effort to review all IETF documents being processe= d by the IESG.=A0 These=0A> comments were written primarily for the benefit= of the security area=0A> directors. Document editors and WG chairs should = treat these comments just=0A> like any other last call comments.=0A> =0A> -= -=0A> This document is an individual submission in the INT area, and obsole= tes=0A> RFC5320, which was published as Experimental in the ISE stream.=0A>= RC5320 contains an IESG Note, saying the decision to publish is not based = on=0A> IETF review for things like security.=0A> This document is being pub= lished as Informational, not Standards-track.=0A> I do not consider my secu= rity review as thorough as a standards-track doc=0A> might deserve.=0A> =0A= > SEAL is the Subnetwork Encapsulation and Adaptation Layer.=0A> It is a la= yer between the (IP and transport headers) and the content being=0A> sent (= so it is between the Transport layer and the Application layer).=0A> Its go= al is to provide a virtual topology overlay using content=0A> encapsulation= between a point in the network that serves as a SEAL ingress=0A> point and= another point in the tunnel that serves as a Seal egress point,=0A> over a= multiple-hop physical or virtual network topology. The SEAL protocol=0A> a= ddresses issues relating to MTU consistency, detection of duplicate packets= =0A> and packet reordering, segment-to-segment data origin authentication,= =0A> segment-to-segment packet header integrity and anti-replay. =0A> The d= ocument also defines a control message protocol that addresses issues=0A> w= ith use of ICMP, where ICMP might be impacted by middleboxes, among other= =0A> things.=0A> These specifications are meant to supplement IP's end-to-e= nd message=0A> integrity checking, authentication and confidentiality.=0A> = =0A> The document appears well-written, clear, and unambiguous.=0A> The sec= urity considerations section is short (only 4 paragraphs) but=0A> describes= what security issues SEAL is meant to address, and which issues it=0A> is = not meant to address.=0A> The Security Considerations section discusses som= e possible attacks and ways=0A> to mitigate them.=0A> The security features= of SEAL are discussed throughout the document.=0A> I feel the security con= siderations section is reasonable.=0A=0AOK.=0A=0A> I have a few concerns, m= ost not related to security, and the Security Ads=0A> can decide whether th= ey feel these are important to address:=0A> 1) The document defines what is= effectively SEALv2 to obsolete the SEALv1=0A> defined in RFC5320. SEALv1 h= ad no version field; SEALv2 adds a version=0A> field. It is unclear to me w= hether there are issues of deploying=0A> implementations of both versions i= n the same network. The two versions have=0A> significant differences, desc= ribed in section 1.3, which show these are=0A> quite different protocols, n= ot just a minor evolution. Since v1 was never=0A> supposed to be deployed, = this may not be an issue.=0A=0AThe RFC5320 version of SEAL was never meant = to be deployed outside of=0Asimple test networks. Hence, implementations of= RFC5320 and implementations=0Aof this new spec will not show up on the sam= e network.=0A=0A> 2) The identification and Integrity check fields are opti= onal (section 5.3),=0A> and without these fields SEAL doesn't seem to addre= ss important security=0A> issues). It does still provide for MTU consistenc= y, segmentation, etc., but=0A> not security.=0A=0AYes, these fields are mai= ntained as optional in case SEAL were to be deployed=0Aon some network that= provides alternate means of security (e.g., a corporate=0Aenterprise netwo= rk that is cordoned off from the Internet with security gateways,=0Afirewal= ls, etc.=0A=0A> 3) in 5.4.3, it states that the ITE (ingress point) may mai= ntain packet=0A> sizing variables per ETE (egress point), rather than per S= EAL path. It=0A> doesn't discuss in detail the implications of this decisio= n, nor how it=0A> might impact interoperability or performance. The existin= g discussion might=0A> be enough, but the discussion is very short.=0A=0ATh= e only implication I am aware of is that the ITE may end up using more=0Aco= nservative values for these constants than necessary for most of the paths= =0Afrom the ITE to the ETE. And, the document already states that:=0A=0A=A0= "The ITE may instead maintain the packet sizing variables and constants as= per ETE=0A=A0=A0 (rather than per SEAL path) values. In that case, the val= ues reflect the lowest-common-=0A=A0=A0 denominator size across all of the = SEAL paths associated with this ETE."=0A=0ADoes this look like enough?=0A= =0A> 4) There are a couple places where IDs are referenced, and it is uncle= ar=0A> whether it should be normative or informative, and what effect the= =0A> completion of the ID would have on the SEAL protocol. The most notable= for=0A> me was section 5.4.5, which references draft-ietf-6man-udpzero. Th= is=0A> document says set the checksum to 0, and points to the draft for add= itional=0A> considerations. It is unclear whether SEAL implementations are = expected to=0A> change when udpzero gets published or not. This might impac= t=0A> interoperability, if some set the checksum to 0 and other implementat= ions do=0A> not. Of course, this document is only informational, so normati= ve might not=0A> be important.=0A=0AYou have touched on an interesting poin= t. The UDP checksum drafts are currently=0Astill in the publication queue, = and I do not know if there is a know date at which=0Athey would be publishe= d. So, I have taken the precedent established in the=0A=A0publication of LI= SP (RFC6830) where these drafts were cited as informational-only.=0A=0A> 5)= section 5.4.7 suggests taking some ICMP messages as "hints". I =0A> wonder= if=0A> using these as hints, or not, might impact interoperability.=0A=0AT= he SEAL decision process is driven by the ITE, and the ETE passively accept= s=0Aand/or evaluates whatever the ITE sends. So, different ITE implementati= ons may=0Atake or not take the recommendations in this sections and still r= emain interoperable=0Awith any ETE implementations.=0A=0A> 6) In 5.5.4, the= re is mention of the window of acceptable values. I wonder=0A> if a recomme= nded default, or a default algorithm for determining window size=0A> is app= ropriate.=0A=0AThe window size is intentionally left unspecified, and left = up to implementations.=0AThe choice of window size will not affect interope= rability even if multiple=0Aimplementations select different window sizes.= =0A=0A> 7) In 5.6.2.1, an ITE should "only process the message if it is abl= e to=0A> recognize the packet as one it had previously set." This seems a b= it loose=0A> to me, and I wonder if it could be tightened up.=0A=0AThe conc= ern is no different than for the security concerns an ordinary host would= =0Ahave to observe when it receives an ICMP packet too big message. Most ho= sts=0Aaccept the message unconditionally, but they really should look at th= e contents=0Aof the message to see whether it corresponds to a packet the h= ost actually sent.=0ASo, I'm not sure whether more could be said about this= ?=0A=0A> 8) The IANA Considerations requests IANA to assign a user port and= an IP=0A> protocol number. RFC5320 used experimental values from ranges de= fined in=0A> RFC3692 and RFC4727, for experimentation only, and not to be u= sed in any=0A> deployments or shipped products. Having IANA assign values i= s a significant=0A> change, presumably appropriate since this is being publ= ished as an=0A> individual submission rather than experimental. I wanted th= e Ads to be aware=0A> of this change.=0A=0AThere have been a number of comm= ents on this. The going consensus now seems=0Ato be that we will still ask = for the TCP/UDP user port number allocations, but we will=0Ano longer ask f= or the IP protocol number assignment.=0A=0A> Hope this helps.=0A=0AThis rev= iew has been very useful, Dan. Thanks again for taking the time!=0A=0A> Dav= id Harrington=0A> ietfdbh@comcast.net=0A> +1-603-828-1401=0A> From bew@cisco.com Tue Feb 19 17:39:44 2013 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 D76BD21F8815; Tue, 19 Feb 2013 17:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.584 X-Spam-Level: X-Spam-Status: No, score=-110.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SrlkRaS1Gk8; Tue, 19 Feb 2013 17:39:44 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 25D0421F8818; Tue, 19 Feb 2013 17:39:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1174; q=dns/txt; s=iport; t=1361324384; x=1362533984; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=zEe9i0qig9d2C64LcUdVURIcdK4dJU7ZoroSYipG3T8=; b=b3i50itHYvxawUQpb+MLpUPy0B9V1QRKJvPNiGTVyLOsMMc3FeNKfypd wRZ6pvNQ9WrFQKVZnRsZanQBhtcM2fvRhM/NsNgCgkk7Y6r1II8GmzIN1 hk1c81nh8vpo7CmD1YPxKEb44EhGnZ0zc2GcLSpkA/8WESOlForKNXms1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAEoJFGrRDoI/2dsb2JhbABFwEeBDhZzgmA/gT4BiCOwNJAgjw6CZmEDiGaNRZBYgyg X-IronPort-AV: E=Sophos;i="4.84,698,1355097600"; d="scan'208";a="70185956" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 20 Feb 2013 01:39:44 +0000 Received: from dhcp-10-155-209-77.cisco.com (dhcp-10-155-209-77.cisco.com [10.155.209.77]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1K1dhRa030434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Feb 2013 01:39:43 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Feb 2013 17:39:44 -0800 Message-Id: <005B9D08-4206-4E54-9EBA-54768ADBBA95@cisco.com> To: "secdir@ietf.org" , The IESG Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: draft-ietf-mpls-tp-security-framework.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-mpls-tp-security-framework-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 01:39:45 -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 provides a security framework for Multiprotocol Label = Switching Transport Profile (MPLS-TP). It is based upon RFC 5920 ("MPLS = and GMPLS security framework"), but particularly addresses MPLS-TP = extensions. It starts with a good background on the security reference = models, highlighting "trusted zones" and "untrusted zones" of various = network architectures. It then outlines threats in an MPLS network that = are either particularly important to MPLS-TP. The primary mitigation for threats to the infrastructure is to use some = form of packet authentication, and this is well covered. It also = stresses threats and mitigations to using a network management system = used to provision MPLS-TP network elements. Draft -08 is much improved = over -07, and I believe is ready to publish. Brian= From shawn.emery@oracle.com Wed Feb 20 00:01:17 2013 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 1AF3C21F893E; Wed, 20 Feb 2013 00:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKpsYEcvNCdE; Wed, 20 Feb 2013 00:01:16 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4CB21F888B; Wed, 20 Feb 2013 00:01:16 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1K81BXR013490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Feb 2013 08:01:12 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1K81BcE022034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2013 08:01:11 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 r1K81AOo019521; Wed, 20 Feb 2013 02:01:10 -0600 Received: from [10.159.102.43] (/10.159.102.43) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 20 Feb 2013 00:01:09 -0800 Message-ID: <5124827A.3070407@oracle.com> Date: Wed, 20 Feb 2013 00:59:54 -0700 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.11) Gecko/20121204 Thunderbird/10.0.11 MIME-Version: 1.0 To: secdir@ietf.org References: <5112164C.3060009@oracle.com> In-Reply-To: <5112164C.3060009@oracle.com> X-Forwarded-Message-Id: <5112164C.3060009@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt.all@tools.ietf.org, The IESG Subject: [secdir] Review of draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-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, 20 Feb 2013 08:01:17 -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 internet-draft describes a way to provide a client link-layer addresses in DHCPv6 Relay-Forward messages.. The security considerations section does exist and discusses an attack scenario involving rogue relay agents and clients where a DHCPv6 node could spoof the address of a separate DHCPv4 node. Subsequently if a Dynamic DNS update is made then a dual-stack node could be made to connect to the DHCPv6 client instead of the DHCPv4 client. To thwart such an attack the draft recommends that administrators configure IPsec between the DHCP server(s) and the relay agents. Besides the security considerations of DHCP in general, I think that this document adequately covers the feature being introduced. General comments: None. Editorial comments: s/will help above mentioned scenarios/will help with the scenarios mentioned above/ s/used in wide/used in a wide/ Shawn. -- From rdroms.ietf@gmail.com Wed Feb 20 06:33:40 2013 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 92ACB21F8780 for ; Wed, 20 Feb 2013 06:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.541 X-Spam-Level: X-Spam-Status: No, score=-103.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7207NpdZlXkn for ; Wed, 20 Feb 2013 06:33:40 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE8E221F875F for ; Wed, 20 Feb 2013 06:33:39 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id l6so5071504vcl.17 for ; Wed, 20 Feb 2013 06:33:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=aQiWj/xwBlDyTTD07YZOrNshtAb5McmJM0WNCP4ohF4=; b=rCyXr1Na38LT8Le8PuF8KxNpuPMB7kZ0uUlvGXowKIImCVhekw0rihfyYDYPgS/LAj jR5izB1uWf6aLbR0I93UTNL86yPASZjpqA/Ifd2zuPF+Tabo2y3lMyCH7gslwcLJzaKe 3n3mQrJFuNJiJfbLUrdnlsBEuvDfJpS/WAIb9F18FbduRrPdEXd4dgl3Cm16FWidRLXd 3x10vclUlPFsuTCUFxqw4nrlW6EJ64HtYCqZ//9UcRO/jtVun3CR1GjfzjxU+G7lvxGr e+FijzTZieDISLn9O5b4h5UReqJfbZvLH6+HehhVj657wEpLZmR1Z2TDuC+bBlVkDDC/ mVuA== X-Received: by 10.52.22.74 with SMTP id b10mr22827607vdf.96.1361370819137; Wed, 20 Feb 2013 06:33:39 -0800 (PST) Received: from ?IPv6:2001:420:2c51:1311:e123:1b78:f56b:cf9c? ([2001:420:2c51:1311:e123:1b78:f56b:cf9c]) by mx.google.com with ESMTPS id i17sm25658105vdj.1.2013.02.20.06.33.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 06:33:38 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ralph Droms In-Reply-To: Date: Wed, 20 Feb 2013 09:33:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <23EF6229-4A9B-48DB-BAA7-2D4B37394247@gmail.com> References: <5123E350.4040809@ieca.com> To: Sam Hartman X-Mailer: Apple Mail (2.1499) Cc: secdir@ietf.org Subject: Re: [secdir] volunteer for draft-rafiee-intarea-cga-tsig 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, 20 Feb 2013 14:33:40 -0000 Thanks for the quick review, Sam. - Ralph On Feb 19, 2013, at 6:39 PM 2/19/13, Sam Hartman = wrote: > I took a look at draft-rafiee-intarea-cga-tsig. >=20 > The idea is generally sound although I did not fully debug the = algorithm > as discussed below. Unfortunately, the draft needs a lot of work = before > it's ready. >=20 > Comments: >=20 > Section 3 contains a number of claims regarding protecting the = exchanges > between the resolver and client. Is tsig actually used for DNS > resolution or just for update/zone transfer? > Section 3 should be reviewed to determine whether all the use cases = are > in fact applicable for use of tsig. >=20 > The draft really needs help from someone with an eye towards > abstraction. > Section 4 repeates much of the key generation from the CGA = specification > and repeats a lot of detail from the TSIG specification as well. > The rest of the draft tends to suffer from this as well. >=20 > Unfortunately, that approach--repeating (and sometimes changing) text > from CGA and TSIG is highly problematic. It makes it hard to evaluate > correctness of this specification and to identify all the differences > between this specification and the existing specifications. In > addition, it makes it hard to understand how this specification might > interact with existing extensions to CGAs and existing or future > extensions to DNS-TSIG. >=20 > Please ask someone from the DNS community to review the shortening of > the TSIG exchange and the removal of the TKEY RR type. >=20 > The general textual clarity could be significantly improved. >=20 > I don't think this draft is ready for adoption, but I do think that = the > ideas expressed here could be a valid basis for future work. >=20 > --Sam From david.waltermire@nist.gov Wed Feb 20 08:02:07 2013 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 B02A321F88B1; Wed, 20 Feb 2013 08:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.519 X-Spam-Level: X-Spam-Status: No, score=-5.519 tagged_above=-999 required=5 tests=[AWL=-0.674, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BV-M8AN5dZsk; Wed, 20 Feb 2013 08:02:07 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8E59521F88AE; Wed, 20 Feb 2013 08:02:06 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 20 Feb 2013 11:02:00 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 20 Feb 2013 11:02:02 -0500 From: "Waltermire, David A." To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-shafranovich-mime-sql-04.all@tools.ietf.org" Date: Wed, 20 Feb 2013 11:02:01 -0500 Thread-Topic: secdir review of draft-shafranovich-mime-sql-04 Thread-Index: Ac4PgqphxS1qs1hVTGqEkpG+JLqKRA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C4930BF4A77E48MBCLUSTERxcha_" MIME-Version: 1.0 Subject: [secdir] secdir review of draft-shafranovich-mime-sql-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, 20 Feb 2013 16:02:07 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930BF4A77E48MBCLUSTERxcha_ 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 captures a proposal to register with IANA the application/sql media type to be used for the Structured Query Language (SQL). It provides the necessary registration application for a media type [RFC6838]. This draft clearly addresses the IANA registration requirements for a new media type entry in the IANA registry. After reviewing this document I do not have any additional security-related concerns. Sincerely, Dave --_000_D7A0423E5E193F40BE6E94126930C4930BF4A77E48MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4 dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUx Nw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLlBsYWluVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48 Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2Vj dGlvbjE+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50 IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MmbmJzcDtvbmdvaW5nIGVmZm9y dCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVT Ry4mbmJzcDsgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJl bmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiZuYnNwOyBEb2N1bWVudCBlZGl0 b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBh bnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+VGhpcyBk cmFmdCBjYXB0dXJlcyBhIHByb3Bvc2FsIHRvIHJlZ2lzdGVyIHdpdGggSUFOQSB0aGUgYXBwbGlj YXRpb24vc3FsIG1lZGlhIHR5cGUgdG8gYmUgdXNlZCBmb3IgdGhlIFN0cnVjdHVyZWQgUXVlcnkg TGFuZ3VhZ2UgKFNRTCkuIEl0IHByb3ZpZGVzIHRoZSBuZWNlc3NhcnkgcmVnaXN0cmF0aW9uIGFw cGxpY2F0aW9uIGZvciBhIG1lZGlhIHR5cGUgW1JGQzY4MzhdLjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+VGhpcyBkcmFmdCBjbGVhcmx5IGFkZHJlc3NlcyB0aGUgSUFOQSByZWdpc3RyYXRpb24gcmVx dWlyZW1lbnRzIGZvciBhIG5ldyBtZWRpYSB0eXBlIGVudHJ5IGluIHRoZSBJQU5BIHJlZ2lzdHJ5 LiZuYnNwOyBBZnRlciByZXZpZXdpbmcgdGhpcyBkb2N1bWVudCBJIGRvIG5vdCBoYXZlIGFueSBh ZGRpdGlvbmFsIHNlY3VyaXR5LXJlbGF0ZWQgY29uY2VybnMuPG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD5TaW5jZXJlbHksPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PkRhdmU8bzpw PjwvbzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_D7A0423E5E193F40BE6E94126930C4930BF4A77E48MBCLUSTERxcha_-- From jhutz@cmu.edu Wed Feb 20 13:04:02 2013 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 5F27E21E803F for ; Wed, 20 Feb 2013 13:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.476 X-Spam-Level: X-Spam-Status: No, score=-106.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2O+y6KBqveH for ; Wed, 20 Feb 2013 13:04:01 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1AE21E803A for ; Wed, 20 Feb 2013 13:04:01 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r1KL3vch019490 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2013 16:03:57 -0500 (EST) Message-ID: <1361394237.9132.27.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Sam Hartman Date: Wed, 20 Feb 2013 16:03:57 -0500 In-Reply-To: <17096_1361317158_r1JNdHtt017963_tslip5n27s4.fsf@mit.edu> References: <5123E350.4040809@ieca.com> <17096_1361317158_r1JNdHtt017963_tslip5n27s4.fsf@mit.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: secdir@ietf.org, Ralph Droms , jhutz@cmu.edu Subject: Re: [secdir] volunteer for draft-rafiee-intarea-cga-tsig 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, 20 Feb 2013 21:04:02 -0000 On Tue, 2013-02-19 at 18:39 -0500, Sam Hartman wrote: > Section 3 contains a number of claims regarding protecting the exchanges > between the resolver and client. Is tsig actually used for DNS > resolution or just for update/zone transfer? Yes, TSIG can be used for resolution. I run caching servers this way in production, such that TSIG is used for queries from those servers to the authoritative servers for my own zones. Among other things, we use this to extend the notion of multiple views visible to different clients into the caches, such that the same set of caching servers cache multiple views. -- Jeff From ghalwasi@cisco.com Wed Feb 20 00:37:07 2013 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 3148721F85E8; Wed, 20 Feb 2013 00:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAYZIo-jzYFu; Wed, 20 Feb 2013 00:37:06 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 739B321F85C9; Wed, 20 Feb 2013 00:37:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1745; q=dns/txt; s=iport; t=1361349426; x=1362559026; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZB9Z/ZYqaQecuInNhfUhFH77gpb3GOCTJSwdlRRMf3A=; b=llYmnvsxF12KJbMLhCfd3UKOLskXWqKl/dpRyrAxIK1lEB5eSfAi5NHQ j+G7sOPUda5A0CT2OMbLI3thUNFK6d28K8Zmj3J19uPp4WPE1RoW4hzcN sfLZYIRWNVikQnR5F9drANfrwLWqYTXP56FS4MfEVXkUqyU4Q86fo5PM1 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACiKJFGtJXG9/2dsb2JhbABFwFR/FnOCHwEBAQQ6PwwEAgEIEQQBAQsUCQcyFAkIAgQBDQUIiAq/eI5dJgsHBoJZYQOnA4MHgic X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; d="scan'208";a="179108229" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 20 Feb 2013 08:37:06 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1K8b5n2006005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Feb 2013 08:37:05 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.248]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 02:37:05 -0600 From: "Gaurav Halwasia (ghalwasi)" To: Shawn Emery , "secdir@ietf.org" Thread-Topic: Review of draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 Thread-Index: AQHOD0CKRlLRIRzxN0yTVWH3M8pIOZiCbBTg Date: Wed, 20 Feb 2013 08:37:04 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB22E62942@xmb-aln-x06.cisco.com> References: <5112164C.3060009@oracle.com> <5124827A.3070407@oracle.com> In-Reply-To: <5124827A.3070407@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 20 Feb 2013 13:42:53 -0800 Cc: "draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt.all@tools.ietf.org" , The IESG Subject: Re: [secdir] Review of draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-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, 20 Feb 2013 08:37:07 -0000 Thanks Shawn for review. We will take care of your Editorial comments in the next revision or at the= time of AUTH48 (whichever is earlier.) Regards -Gaurav -----Original Message----- From: Shawn Emery [mailto:shawn.emery@oracle.com]=20 Sent: Wednesday, February 20, 2013 1:30 PM To: secdir@ietf.org Cc: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt.all@tools.ietf.org; Th= e IESG Subject: Review of draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG.=20 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 internet-draft describes a way to provide a client link-layer addresse= s in DHCPv6 Relay-Forward messages.. The security considerations section does exist and discusses an attack scen= ario involving rogue relay agents and clients where a DHCPv6 node could spo= of the address of a separate DHCPv4 node. Subsequently if a Dynamic DNS up= date is made then a dual-stack node could be made to connect to the DHCPv6 = client instead of the DHCPv4 client. To thwart such an attack the draft re= commends that administrators configure IPsec between the DHCP server(s) and= the relay agents. Besides the security considerations of DHCP in general,= I think that this document adequately covers the feature being introduced. General comments: None. Editorial comments: s/will help above mentioned scenarios/will help with the scenarios mentione= d above/ s/used in wide/used in a wide/ Shawn. -- From lufang@cisco.com Wed Feb 20 13:36:29 2013 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 1F90921F865D; Wed, 20 Feb 2013 13:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.163 X-Spam-Level: X-Spam-Status: No, score=-10.163 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMJo99lsvaiX; Wed, 20 Feb 2013 13:36:28 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 47C7C21F8623; Wed, 20 Feb 2013 13:36:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1911; q=dns/txt; s=iport; t=1361396188; x=1362605788; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0C6fdsP8ISI9wyZZgcP94D+o0/ZxOUgNhZJqWj/fOkY=; b=m4GMGjajfURX7al3+XRxOs2nvwqFQPhBm5s4cqLm4DZvh3By3KURXi55 qQgogR24Xt6vUrubKgcNda02Fzz2m3BkssfBcL42cJcGmoVD1933SlfUD 0msbg2Xao78JwI/7HlqSp/Z7aoolHrhMUamfxttnydpVBe7tzh1eCGWc1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADVBJVGtJV2Y/2dsb2JhbABFwGGBAhZzgh8BAQEEOj8MBgEIEQMBAgsUQh0IAgQBDQUIiArAVo5dJgsHBoJZYQOnB4MHgic X-IronPort-AV: E=Sophos;i="4.84,703,1355097600"; d="scan'208";a="179348810" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 20 Feb 2013 21:36:28 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1KLaRWJ013033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Feb 2013 21:36:27 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.17]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 15:36:27 -0600 From: "Luyuan Fang (lufang)" To: "Brian Weis (bew)" , "secdir@ietf.org" , The IESG Thread-Topic: Secdir review of draft-ietf-mpls-tp-security-framework-08 Thread-Index: AQHODwsx4vb6RL2SRUmHg52vg6/zo5iDV1eA Date: Wed, 20 Feb 2013 21:36:26 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD9310298D2B@xmb-rcd-x03.cisco.com> In-Reply-To: <005B9D08-4206-4E54-9EBA-54768ADBBA95@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.131.12.62] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 20 Feb 2013 13:42:53 -0800 Cc: "draft-ietf-mpls-tp-security-framework.all@tools.ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-mpls-tp-security-framework-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 21:36:29 -0000 Brian, Thank you very much for your review and approval. Luyuan -----Original Message----- From: "Brian Weis (bew)" Date: Tuesday, February 19, 2013 8:39 PM To: "secdir@ietf.org" , The IESG Cc: "draft-ietf-mpls-tp-security-framework.all@tools.ietf.org" Subject: Secdir review of draft-ietf-mpls-tp-security-framework-08 Resent-From: Resent-To: , , , Luyuan Fang , , , , Resent-Date: Tuesday, February 19, 2013 8:39 PM >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 provides a security framework for Multiprotocol Label >Switching Transport Profile (MPLS-TP). It is based upon RFC 5920 ("MPLS >and GMPLS security framework"), but particularly addresses MPLS-TP >extensions. It starts with a good background on the security reference >models, highlighting "trusted zones" and "untrusted zones" of various >network architectures. It then outlines threats in an MPLS network that >are either particularly important to MPLS-TP. > >The primary mitigation for threats to the infrastructure is to use some >form of packet authentication, and this is well covered. It also stresses >threats and mitigations to using a network management system used to >provision MPLS-TP network elements. Draft -08 is much improved over -07, >and I believe is ready to publish. > >Brian From dharkins@lounge.org Wed Feb 20 14:32:11 2013 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 B47A721E8041; Wed, 20 Feb 2013 14:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmytrG1QRHuj; Wed, 20 Feb 2013 14:32:11 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAE621E803A; Wed, 20 Feb 2013 14:31:53 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 4C68E1022404C; Wed, 20 Feb 2013 14:31:53 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 20 Feb 2013 14:31:53 -0800 (PST) Message-ID: <11d667a994d9c2f139958c2e605048fa.squirrel@www.trepanning.net> Date: Wed, 20 Feb 2013 14:31:53 -0800 (PST) From: "Dan Harkins" To: secdir@ietf.org, iesg@ietf.org, draft-richardson-roll-applicability-template.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-richardson-roll-applicability-template-01 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, 20 Feb 2013 22:32:11 -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. Boilerplate aside, I hope that this document is not being processed by the IESG because I don't think it's suitable for publishing even as an Informational RFC (it's intended status). It seems to have the right sections to properly articulate the ROLL Applicability Statement but there is no content there so it is not suitable for any purpose as a stand-alone document and it's not really possible to review it. This seems more like an internal placeholder document for the ROLL WG to work on as a precursor to producing a real applicability statement and not the kind of document that the IETF normally produces, and that the Security Area Directorate normally reviews. Some suggestions for improving this template so some other draft that would be suitable for advancement could be written: - Instead of "Hello", I think the content of "1. Introduction" should be a description of what the applicability statement will be and what it's for, that way this text can just be copied into the real applicability statement. It seems like a template should provide this information. - Make a 1.2 for terminology and put "RPL" and "trickle" there along with some other ROLL-related terms. - there are probably different security considerations for P2P and P2MP communication, probably split those out in section 6 so the applicability statement addresses them. - 4.2.1 should be "Services Provided at Layer 2" or something general like that. If you need an expert that might be better noted as a parenthetical comment for 4.2. regards, Dan. From mcr@sandelman.ca Wed Feb 20 20:25:55 2013 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 5B14221F8D0D; Wed, 20 Feb 2013 20:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASuD8SGhGfdA; Wed, 20 Feb 2013 20:25:54 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 5941421F8D0B; Wed, 20 Feb 2013 20:25:54 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 059FB20168; Wed, 20 Feb 2013 23:32:42 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id D9596102F5; Wed, 20 Feb 2013 23:24:45 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9FDE820007; Wed, 20 Feb 2013 23:24:45 -0500 (EST) From: Michael Richardson To: "Dan Harkins" In-Reply-To: <11d667a994d9c2f139958c2e605048fa.squirrel@www.trepanning.net> References: <11d667a994d9c2f139958c2e605048fa.squirrel@www.trepanning.net> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-richardson-roll-applicability-template-01 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, 21 Feb 2013 04:25:55 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Dan, thanks for the work. >>>>> "Dan" =3D=3D Dan Harkins writes: Dan> Boilerplate aside, I hope that this document is not being processed Dan> by the IESG because I don't think it's suitable for publishing eve= n as Dan> an Informational RFC (it's intended status). It seems to have the = right Dan> sections to properly articulate the ROLL Applicability Statement b= ut Dan> there is no content there so it is not suitable for any purpose Dan> as a *THIS* document is not intended to be published. It remains an ID to be copied. I would have hoped the context for this advance review would have been communicated better.... The idea is that current and future Applicability statements will use the table of contents provided. So, before secdir is asked to review the security implications of a "real" document, we want to figure out what major sections might be *missing* from the table of contents. So I will attempt to fill in the Introduction with an actual Introduction to explain this document. Here are two example applicability statements which we are trying to get into this format.=20=20 http://datatracker.ietf.org/doc/draft-brandt-roll-rpl-applicability-home-bu= ilding/ http://datatracker.ietf.org/doc/draft-phinney-roll-rpl-industrial-applicabi= lity/ If I have my way, many of these documents will be further reduced in scope, resulting in many more than our originally chartered four such documents. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUSWhjIqHRg3pndX9AQLq2gQAvb9Fdz5pBnXQdTZ6tUO/LUM8z+OsmtKM GeSfne6D5l1e1Qt74/jUBovzfTtlvh2S4aIQdz4D2GQuXhT7xFptAaDbxotrVHC2 AtYFUcU1L2NSkotJs7pjqJLNkJPld7xQPKSxNWZC7e6VDl4qG8/BWbyMHFoOVWSM f6EvFTUBe0E= =8dVA -----END PGP SIGNATURE----- --=-=-=-- From kivinen@iki.fi Thu Feb 21 04:16:39 2013 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 C4B2A21F8DC7 for ; Thu, 21 Feb 2013 04:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNODxJtGSOjy for ; Thu, 21 Feb 2013 04:16:39 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id C2D9921F8C9E for ; Thu, 21 Feb 2013 04:16:38 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r1LCGYsg019617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Feb 2013 14:16:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r1LCGYfX027453; Thu, 21 Feb 2013 14:16:34 +0200 (EET) 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: <20774.4130.458961.217401@fireball.kivinen.iki.fi> Date: Thu, 21 Feb 2013 14:16:34 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min 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, 21 Feb 2013 12:16:39 -0000 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 2013-02-21 Reviewer LC end Draft Phillip Hallam-Baker T 2013-02-15 draft-ietf-paws-problem-stmt-usecases-rqmts-13 Matt Lepinski T 2013-01-25 draft-ietf-radext-radius-extensions-12 Sandy Murphy T 2013-01-29 draft-ietf-6man-nd-extension-headers-03 Carl Wallace T 2013-02-05 draft-ietf-behave-nat64-discovery-heuristic-13 Nico Williams T 2013-02-18 draft-templin-ironbis-12 For telechat 2013-02-28 Alan DeKok T 2013-02-28 draft-eastlake-additional-xmlsec-uris-09 Jeffrey Hutzelman T 2013-02-27 draft-ietf-geopriv-flow-identity-01 Simon Josefsson T 2013-02-26 draft-ietf-tcpm-proportional-rate-reduction-04 Stephen Kent TR2013-02-25 draft-ietf-dhc-secure-dhcpv6-07 Last calls and special requests: Rob Austein 2013-03-06 draft-arkko-iesg-crossarea-03 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-05 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Charlie Kaufman 2013-03-06 draft-ietf-appsawg-acct-uri-03 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-09 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Eric Rescorla 2013-01-24 draft-ietf-ospf-ospfv3-iid-registry-update-02 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-03 Nico Williams - draft-ietf-httpbis-p5-range-21 Glen Zorn 2013-02-11 draft-ietf-mpls-tp-use-cases-and-design-06 -- kivinen@iki.fi From new-work-bounces@ietf.org Thu Feb 21 11:35:51 2013 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 A8B0621F8F23; Thu, 21 Feb 2013 11:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1361475351; bh=OR89HwxfYBIMlm1pq+grigbC5MlE7zoIZ/NyplPmq28=; 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=W9UqQje0prZihPog/5nQvYY00UE20SK4dAGLWEPhyIxg4k7yqUoTw/GcPbmJ01+Ud NiiT15Tog7EQkKuTz0cTEUJSxtVpdaJX2wKwabJX82ybCLRKPIj2dexHEM9KFsNTcI hS5wq+PeLuOHfAbxsdlwaQlT+BnDWb/msiOo0EHo= 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 628DC21F8F47; Thu, 21 Feb 2013 11:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDCaXRNEnZc0; Thu, 21 Feb 2013 11:35:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B1C21F8F4B; Thu, 21 Feb 2013 11:35:43 -0800 (PST) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130221193543.679.38814.idtracker@ietfa.amsl.com> Date: Thu, 21 Feb 2013 11:35:43 -0800 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, 21 Feb 2013 11:38:53 -0800 Subject: [secdir] [new-work] WG Review: JSON data formats for vCard and iCalendar (jcardcal) 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, 21 Feb 2013 19:35:51 -0000 A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-02-28. JSON data formats for vCard and iCalendar (jcardcal) ------------------------------------------------ Current Status: Proposed Working Group Assigned Area Director: Pete Resnick Charter of Working Group: jcardcal Working Group - JSON data formats for iCalendar and vCard. Problem Statement: The standard iCalendar [RFC5545] and vCard [RFC6350] data formats are in widespread use for calendaring and contacts data exchange. In addition to the text formats described in the base specifications, alternative XML formats have been defined ([RFC6321] and [RFC6351] respectively). Interest has been expressed in also having JSON [RFC4627] formats for both iCalendar and vCard to allow easier integration of such data with web or other Javascript based applications, and other JSON-based protocols being developed by IETF working groups such as jose, scim, and weirds. Because iCalendar and vCard formats have a similar schema (a component/property/parameter/value model) it is often the case that iCalendar and vCard data handling is carried out by libraries with a high degree of code re-use for each format. It is thus highly desirable that the JSON formats for iCalendar and vCard are aligned in terms of their JSON structures so that the policy of code re-use for iCalendar/vCard parsing/generation can continue. Objectives: The jcardcal working group is chartered to develop JSON-based data formats that are accurate, straightforward representations of iCalendar and vCard data, allowing for conversion between any of the various equivalent data formats without any loss of semantic meaning, and maximal interoperability. Consideration will be given to compactness and readability of the JSON data formats, whilst at the same time maintaining the underlying data models of the respective original formats. The JSON formats will re-use the extensibility model of the base formats. The JSON formats will use similar data models in JSON to allow for optimal code re-use when parsing/generating jCard and jCal. Syntactic requirements from other working groups looking to adopt the jCard or jCal data formats will be considered. However, changes to the semantics of vCard and iCalendar are out of scope. Requirements that are not explicitly mentioned in this charter will be considered so long as they do not conflict with the other stated objectives. Specific requirements for consideration are: * a need for conveying unstructured address information (weirds WG). Milestones: Mar 2013 - Determine initial requirements of other Working Groups. Mar 2013 - Accept jCard and jCal documents as Working Group items. May 2013 - Request publication of jCard document. Jun 2013 - Request publication of jCal document. _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From turners@ieca.com Fri Feb 22 07:12:01 2013 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 93ED321F8A56 for ; Fri, 22 Feb 2013 07:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.694 X-Spam-Level: X-Spam-Status: No, score=-100.694 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2Fp9bowSH7V for ; Fri, 22 Feb 2013 07:12:01 -0800 (PST) Received: from gateway14.websitewelcome.com (unknown [69.56.144.3]) by ietfa.amsl.com (Postfix) with ESMTP id DA02C21F8891 for ; Fri, 22 Feb 2013 07:12:00 -0800 (PST) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 1E07B5371DD76; Fri, 22 Feb 2013 09:11:54 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 2FC1D5371C3BF for ; Fri, 22 Feb 2013 09:11:53 -0600 (CST) Received: from [108.45.16.214] (port=60163 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1U8uHz-00041O-6P for secdir@ietf.org; Fri, 22 Feb 2013 09:11:55 -0600 Message-ID: <51278ABA.2030206@ieca.com> Date: Fri, 22 Feb 2013 10:11:54 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: (thunderfish.local) [108.45.16.214]:60163 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [secdir] alternate shepherd write-up experiment 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, 22 Feb 2013 15:12:01 -0000 secdir members, As the IESG constantly re-examines process, it's been noted that sometimes directorate reviews don't always make it to where they should. It was suggested that all directorate reviews be sent to the ietf@ietf.org, but there was some push back against this idea. I think the process we have documented at: http://trac.tools.ietf.org/group/iesg/trac/wiki/DraftShepherdWriteupWgAlternate is the right one as it allows you to decide whether to also sent to ietf@ietf.org. But, I'd like to take this opportunity to remind everyone that reviews should be sent to draftname.all@tools.ietf.org, secdir@ietf.org, and iesg@ietf.org. This way the responsible AD, shepherd, WG chair, and authors get a copy of the review. Thanks for all the reviews, spt From benl@google.com Fri Feb 22 08:36:23 2013 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 BE36821F8EF4 for ; Fri, 22 Feb 2013 08:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LTjSxGS+WCF for ; Fri, 22 Feb 2013 08:36:23 -0800 (PST) Received: from mail-ie0-x22d.google.com (ie-in-x022d.1e100.net [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1036021F8F6C for ; Fri, 22 Feb 2013 08:36:22 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id 9so932747iec.4 for ; Fri, 22 Feb 2013 08:36:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=z6MFOI7q8BP10JvQzq7G2WQ4irkj07YsWPUTsfCTcAs=; b=RF2F6XodJQ+e49vzP9I6Sp4gEG+u9EXWhINEHdTf1LvlBQLb/J4x/md+AR36SiW/TG PMCqAof0IpaiDiGGhXO5Bc8slaGtH+lBiIb9OXhhkvhup5q+O/TR3YkboV9TTqwOHdLx mkFtAr4fJrG+bOpavAg++5gyAfoA4fIpKFV+eBVg/rpCinVPKOF+cIZxRCSZaRO+LyjR LUZnmvTahAWrT90uZyAcx+6FYceZO/XSm7VLXnxawqeSLj1wUChq1hjmE0imm3chazg8 3GBv0IqWwaGwz6gXoqqdyLkhrGvwwUpQa/+xsw3GKpA2Cydsu4YzTRHzyuDT0upyfEiY fbng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=z6MFOI7q8BP10JvQzq7G2WQ4irkj07YsWPUTsfCTcAs=; b=ZMe6d0GXoNdiGMNTYyZeyHC+cDlqvNK3mllDhCwCzOo0LzhBY9y7uGiTyH/rwvueBr DN2XXzXO5nHfR8VOFC7sWil57eqpMoikafVhSlzujDljBB0soqJChAGCpgXZBUbipE7H ovPTIjuuerIeuDX28uGVY3uqdCzu+ISu4m60SixHbUbhOcEtWC67xLtSvjeiU1k+JkDJ +7n0NagDtRA9ZlGwOZUcuD9FBadHHqzoW+mXbj26ElGYw2HahgC12BW5XhPkStuC4ofo zBRchQX8FykIqmhD8Rmt/HSj2ty/4JRVI3+xNIOHjMXY31OsD+O4eA9D1cz0fdV6cSR/ qGIQ== MIME-Version: 1.0 X-Received: by 10.50.217.230 with SMTP id pb6mr15285079igc.43.1361550982587; Fri, 22 Feb 2013 08:36:22 -0800 (PST) Received: by 10.64.140.71 with HTTP; Fri, 22 Feb 2013 08:36:22 -0800 (PST) In-Reply-To: <51170BF7.6060409@gondrom.org> References: <1359054393.10945.15.camel@minbar.fac.cs.cmu.edu> <26550_1359459340_r0TBZdV2026657_CABrd9STdUzPok8bcAUJddcQ0iWkk=VhP6SZOF-Tv8NFf1fUDFQ@mail.gmail.com> <1359494919.17745.12.camel@minbar.fac.cs.cmu.edu> <5116507D.7070000@gondrom.org> <51170BF7.6060409@gondrom.org> Date: Fri, 22 Feb 2013 16:36:22 +0000 Message-ID: From: Ben Laurie To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQklFbI3+yuALS3/lgHucyOKY2KZ6oIYlha/5gytmAFfu8TgTjnBwhoCSURkPJ/WuCYsDd+F2eDmWMqNm8y4CPJ/ed1efEBfVBPqpOeOBeKVXbLru7r3NyoJFLHzPKWkB+dtuoRKRecb+0pfZCqqRKu81HX2DO91/RGzm97zW8Hv+l0H8vIZFAVoNhp+VVrHoC0exnVy Cc: "secdir@ietf.org" , The IESG , draft-laurie-pki-sunlight.all@tools.ietf.org, Jeffrey Hutzelman Subject: Re: [secdir] dir review of draft-laurie-pki-sunlight-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: Fri, 22 Feb 2013 16:36:23 -0000 On 10 February 2013 02:54, Tobias Gondrom wrote: > On 10/02/13 04:47, Ben Laurie wrote: >> On 9 February 2013 13:34, Tobias Gondrom wrote: >>> Hi Ben, >>> >>> I also just read through your draft in version -07. >>> I can see the draft consists of two parts: >>> 1. data structure >>> 2. protocol. >>> >>> For part #1 the data structure: in case you are not aware of it, some >>> years ago the IETF LTANS WG has done something a bit similar in a more >>> generic way (i.e. for any data not only for certificates) in form of >>> RFC4998 and RFC6283 >> Interesting. I was not aware of these. From a quick skim they are >> indeed similar, but would need a bunch of added machinery to get them >> to where CT is (e.g. not append only, no concept of MMD). > You are welcome. > I believe the gap is mostly towards the protocol side (e.g. including > MMD). As the RFCs only define the data structure. It seems like a lot of work to inherit an essentially trivial data structure. >>> with a number of implementations by major ECM and >>> DMS vendors. >> No idea what ECM or DMS are in this context. > ECM: Enterprise Content Management > DMS: Document Management System > (Systems that store electronic documents/data. > And protect the proof of integrity / non-repudiation with Timestamps and > RFC4998/RFC6283.) These systems rely on trust. :-) > > >> >>> Just as a thought, maybe helpful looking at or even for re-use instead >>> of re-inventing the wheel? >>> >>> Best regards, Tobias >>> >>> >>> >>> On 30/01/13 18:15, Ben Laurie wrote: >>>> On 29 January 2013 21:28, Jeffrey Hutzelman wrote: >>>>> On Tue, 2013-01-29 at 11:35 +0000, Ben Laurie wrote: >>>>>> On 24 January 2013 19:06, Jeffrey Hutzelman wrote: >>>>>>> Similarly, as an anti-spam measure, this document proposes that logs accept >>>>>>> only certificates which chain back to a known CA, and requires that logs >>>>>>> validate each submitted certificate before appending it to the log. This >>>>>>> sounds good, but it's not the only possible mechanism, and so I think MUST >>>>>>> is too strong here. Additionally, there is no discussion of the security >>>>>>> implications if a client depends on a log to do this and the log does not >>>>>>> actually do so. Rather than requiring that logs validate every submitted >>>>>>> certificate, the document should only RECOMMEND that they do so, and make >>>>>>> clear that clients MUST NOT depend on such validation having been done. >>>>>> On second thoughts, whilst that is an effective anti-spam measure, it >>>>>> is also part of the functionality of CT: i.e. to identify misissue and >>>>>> give some means to do something about it. The CA check ensures we have >>>>>> someone to blame for misissue. >>>>> Hrm. I sort of thought the idea was for the logs to be untrusted >>>>> repositories, able to be audited but not themselves expected to detect >>>>> problems. If logs are expected to do validation of this sort, is there >>>>> a way for a third party to discover whether they are doing so (or at >>>>> least, whether they are accepting certificates they shouldn't)? >>>> A third party can indeed verify this - they just watch the log like >>>> any monitor does. >>>> >>>>>> I am not averse to suggestions that achieve the overall aim, but I >>>>>> don't see the virtue of leaving it vague in the description of the >>>>>> experiment we are actually running. >>>>> I'm not suggesting vagueness; rather, I'm merely suggesting downgrading >>>>> a MUST to a SHOULD, which is still quite strong. What happens if >>>>> someone wants to start logging certs issued by a private CA, or >>>>> self-signed certs they have observed, or...? >>>> I don't see an issue with logging certs from a private CA. As for >>>> self-signed certs, I don't see the point, but I guess if someone >>>> figures out a point we can relax it in the next version. >>>> >>>>> I'm suppose I'm OK with keeping the scope narrower than that for >>>>> purposes of the experiment, as long as it is possible to relax the >>>>> requirement later without breaking the system. Hence the importance of >>>>> making it clear that clients must not rely on logs to have done >>>>> validation (on which point I think we've already reached agreement). >>>> Cool. >>>> _______________________________________________ >>>> secdir mailing list >>>> secdir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/secdir >>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From turners@ieca.com Fri Feb 22 08:44:25 2013 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 9A10521F8E7D for ; Fri, 22 Feb 2013 08:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.745 X-Spam-Level: X-Spam-Status: No, score=-101.745 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcOd5UkdBoIz for ; Fri, 22 Feb 2013 08:44:25 -0800 (PST) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.10.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1777A21F8E74 for ; Fri, 22 Feb 2013 08:44:25 -0800 (PST) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 72FA26D7E893F; Fri, 22 Feb 2013 10:44:18 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 5DE576D7E88C6 for ; Fri, 22 Feb 2013 10:44:18 -0600 (CST) Received: from [108.45.16.214] (port=60289 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1U8vjU-0006m2-CZ for secdir@ietf.org; Fri, 22 Feb 2013 10:44:24 -0600 Message-ID: <5127A067.4080308@ieca.com> Date: Fri, 22 Feb 2013 11:44:23 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: (thunderfish.local) [108.45.16.214]:60289 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [secdir] addresses to send reviews to 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, 22 Feb 2013 16:44:25 -0000 secdir members, Sorry about using the wrong subject line in my last message. As the IESG constantly re-examines process, it's been noted that sometimes directorate reviews don't always make it to where they should. It was suggested that all directorate reviews be sent to the ietf@ietf.org, but there was some push back against this idea. I think the process we have documented at: http://trac.tools.ietf.org/group/iesg/trac/wiki/DraftShepherdWriteupWgAlternate is the right one as it allows you to decide whether to also sent to ietf@ietf.org. But, I'd like to take this opportunity to remind everyone that reviews should be sent to draftname.all@tools.ietf.org, secdir@ietf.org, and iesg@ietf.org. This way the responsible AD, shepherd, WG chair, and authors get a copy of the review. Thanks for all the reviews, spt From turners@ieca.com Fri Feb 22 14:30:38 2013 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 B86A121F89B9 for ; Fri, 22 Feb 2013 14:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.767 X-Spam-Level: X-Spam-Status: No, score=-101.767 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EA48GuzsGY-c for ; Fri, 22 Feb 2013 14:30:37 -0800 (PST) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [67.18.137.88]) by ietfa.amsl.com (Postfix) with ESMTP id CC6E421F890D for ; Fri, 22 Feb 2013 14:30:34 -0800 (PST) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 4BF3F551BC9F1; Fri, 22 Feb 2013 16:30:12 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 376E5551BC992 for ; Fri, 22 Feb 2013 16:30:12 -0600 (CST) Received: from [108.45.16.214] (port=61838 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1U918U-0001nC-8x; Fri, 22 Feb 2013 16:30:34 -0600 Message-ID: <5127F189.2040401@ieca.com> Date: Fri, 22 Feb 2013 17:30:33 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Paul Hoffman References: <5127A067.4080308@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: (thunderfish.local) [108.45.16.214]:61838 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: secdir@ietf.org Subject: Re: [secdir] addresses to send reviews to 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, 22 Feb 2013 22:30:38 -0000 On 2/22/13 5:08 PM, Paul Hoffman wrote: > On Feb 22, 2013, at 8:44 AM, Sean Turner wrote: > >> is the right one as it allows you to decide whether to also sent to ietf@ietf.org. But, I'd like to take this opportunity to remind everyone that reviews should be sent to draftname.all@tools.ietf.org, secdir@ietf.org, and iesg@ietf.org. This way the responsible AD, shepherd, WG chair, and authors get a copy of the review. > > And I would like to push back on that. The majority of Secdir reviews fall into two categories: > a) Good enough, no comments > b) Good enough, and I found some nits > > I see no reason that (a) should be sent to draftname.all@tools.ietf.org and iesg@ietf.org. It is information for the Security ADs, not the authors and not the IESG. > > I see no reason that (b) should be sent to iesg@ietf.org. "I found grammar problems" is of no value to the IESG. The point about "good enough" reviews was also brought up and some felt that getting those reviews was of value. I'm just reminding folks what's on: http://trac.tools.ietf.org/area/sec/trac/wiki/SecDirReview If we'd like to crack open the secdir review process, I'm also okay with that. spt From tobias.gondrom@gondrom.org Sat Feb 23 05:42:00 2013 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 4B93C21F8F33 for ; Sat, 23 Feb 2013 05:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.276 X-Spam-Level: X-Spam-Status: No, score=-95.276 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxziEaTzdBEX for ; Sat, 23 Feb 2013 05:41:59 -0800 (PST) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAA521F8F35 for ; Sat, 23 Feb 2013 05:41:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=oL6ZWM/SKHo7aOCkveooHfcYBe6cr5ZUbattws6ap8hmC2chFh7M1ExNbUNbi50h9TdsnrqHbQo0zhQOrVL+FlOTAyVJYscA2l24gQ/E6ajNolpygW0mxjwkFB3mcx7s; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 24332 invoked from network); 23 Feb 2013 14:41:56 +0100 Received: from d1-162-57-143-118-on-nets.com (HELO ?10.8.18.138?) (118.143.57.162) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 23 Feb 2013 14:41:56 +0100 Message-ID: <5128C71E.6000408@gondrom.org> Date: Sat, 23 Feb 2013 21:41:50 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: benl@google.com References: <1359054393.10945.15.camel@minbar.fac.cs.cmu.edu> <26550_1359459340_r0TBZdV2026657_CABrd9STdUzPok8bcAUJddcQ0iWkk=VhP6SZOF-Tv8NFf1fUDFQ@mail.gmail.com> <1359494919.17745.12.camel@minbar.fac.cs.cmu.edu> <5116507D.7070000@gondrom.org> <51170BF7.6060409@gondrom.org> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org, iesg@ietf.org, draft-laurie-pki-sunlight.all@tools.ietf.org, jhutz@cmu.edu Subject: Re: [secdir] dir review of draft-laurie-pki-sunlight-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: Sat, 23 Feb 2013 13:42:00 -0000 On 23/02/13 00:36, Ben Laurie wrote: > On 10 February 2013 02:54, Tobias Gondrom wrote: >> On 10/02/13 04:47, Ben Laurie wrote: >>> On 9 February 2013 13:34, Tobias Gondrom wrote: >>>> Hi Ben, >>>> >>>> I also just read through your draft in version -07. >>>> I can see the draft consists of two parts: >>>> 1. data structure >>>> 2. protocol. >>>> >>>> For part #1 the data structure: in case you are not aware of it, some >>>> years ago the IETF LTANS WG has done something a bit similar in a more >>>> generic way (i.e. for any data not only for certificates) in form of >>>> RFC4998 and RFC6283 >>> Interesting. I was not aware of these. From a quick skim they are >>> indeed similar, but would need a bunch of added machinery to get them >>> to where CT is (e.g. not append only, no concept of MMD). >> You are welcome. >> I believe the gap is mostly towards the protocol side (e.g. including >> MMD). As the RFCs only define the data structure. > It seems like a lot of work to inherit an essentially trivial data structure. Well. Whether you like to take it or parts of it or re-write/re-invent the wheel is obviously up to you. (and I agree that the base data structure (Merkle Hash Tree) itself is pretty trivial. It gets complicated if/when you need to switch to new algorithms over time, which I believe is ERS has proven very useful in implementations. Whether that might be a potential use case for your system, shall be for others to judge.) I only thought I should make you aware of the existing RFCs. > >>>> with a number of implementations by major ECM and >>>> DMS vendors. >>> No idea what ECM or DMS are in this context. >> ECM: Enterprise Content Management >> DMS: Document Management System >> (Systems that store electronic documents/data. >> And protect the proof of integrity / non-repudiation with Timestamps and >> RFC4998/RFC6283.) > These systems rely on trust. :-) > >> >>>> Just as a thought, maybe helpful looking at or even for re-use instead >>>> of re-inventing the wheel? >>>> >>>> Best regards, Tobias >>>> >>>> >>>> >>>> On 30/01/13 18:15, Ben Laurie wrote: >>>>> On 29 January 2013 21:28, Jeffrey Hutzelman wrote: >>>>>> On Tue, 2013-01-29 at 11:35 +0000, Ben Laurie wrote: >>>>>>> On 24 January 2013 19:06, Jeffrey Hutzelman wrote: >>>>>>>> Similarly, as an anti-spam measure, this document proposes that logs accept >>>>>>>> only certificates which chain back to a known CA, and requires that logs >>>>>>>> validate each submitted certificate before appending it to the log. This >>>>>>>> sounds good, but it's not the only possible mechanism, and so I think MUST >>>>>>>> is too strong here. Additionally, there is no discussion of the security >>>>>>>> implications if a client depends on a log to do this and the log does not >>>>>>>> actually do so. Rather than requiring that logs validate every submitted >>>>>>>> certificate, the document should only RECOMMEND that they do so, and make >>>>>>>> clear that clients MUST NOT depend on such validation having been done. >>>>>>> On second thoughts, whilst that is an effective anti-spam measure, it >>>>>>> is also part of the functionality of CT: i.e. to identify misissue and >>>>>>> give some means to do something about it. The CA check ensures we have >>>>>>> someone to blame for misissue. >>>>>> Hrm. I sort of thought the idea was for the logs to be untrusted >>>>>> repositories, able to be audited but not themselves expected to detect >>>>>> problems. If logs are expected to do validation of this sort, is there >>>>>> a way for a third party to discover whether they are doing so (or at >>>>>> least, whether they are accepting certificates they shouldn't)? >>>>> A third party can indeed verify this - they just watch the log like >>>>> any monitor does. >>>>> >>>>>>> I am not averse to suggestions that achieve the overall aim, but I >>>>>>> don't see the virtue of leaving it vague in the description of the >>>>>>> experiment we are actually running. >>>>>> I'm not suggesting vagueness; rather, I'm merely suggesting downgrading >>>>>> a MUST to a SHOULD, which is still quite strong. What happens if >>>>>> someone wants to start logging certs issued by a private CA, or >>>>>> self-signed certs they have observed, or...? >>>>> I don't see an issue with logging certs from a private CA. As for >>>>> self-signed certs, I don't see the point, but I guess if someone >>>>> figures out a point we can relax it in the next version. >>>>> >>>>>> I'm suppose I'm OK with keeping the scope narrower than that for >>>>>> purposes of the experiment, as long as it is possible to relax the >>>>>> requirement later without breaking the system. Hence the importance of >>>>>> making it clear that clients must not rely on logs to have done >>>>>> validation (on which point I think we've already reached agreement). >>>>> Cool. >>>>> _______________________________________________ >>>>> secdir mailing list >>>>> secdir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/secdir >>>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From salvatore.dantonio@uniparthenope.it Sat Feb 23 06:26:04 2013 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 3355521F8EFE; Sat, 23 Feb 2013 06:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.73 X-Spam-Level: X-Spam-Status: No, score=0.73 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWywR6mZehvc; Sat, 23 Feb 2013 06:26:03 -0800 (PST) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by ietfa.amsl.com (Postfix) with ESMTP id B148821F8EFD; Sat, 23 Feb 2013 06:26:02 -0800 (PST) Received: from mail2.uniparthenope.it (unknown [10.1.2.108]) by mail.uniparthenope.it (Postfix) with SMTP id 44C6E31534; Sat, 23 Feb 2013 14:26:00 +0000 (UTC) Received: from (unknown [192.168.241.108]) by mail2.uniparthenope.it with smtp id 1d8b_f1e36490_7dc4_11e2_9101_001372515a5c; Sat, 23 Feb 2013 15:25:59 +0100 Received: from spamk.uniparthenope.it (localhost [127.0.0.1]) by spamk.uniparthenope.it (Postfix) with ESMTP id DC43FC4300; Sat, 23 Feb 2013 15:25:59 +0100 (CET) Received: by spamk.uniparthenope.it (Postfix, from userid 500) id D92BFC4305; Sat, 23 Feb 2013 15:25:59 +0100 (CET) Received: from mail.uniparthenope.it (unknown [192.168.241.109]) by spamk.uniparthenope.it (Postfix) with ESMTP id 30802C4300; Sat, 23 Feb 2013 15:25:59 +0100 (CET) Received: from saldantoPC (unknown [109.112.162.204]) (Authenticated sender: salvatore.dantonio@uniparthenope.it) by mail.uniparthenope.it (Postfix) with ESMTPA id B2A8D31534; Sat, 23 Feb 2013 15:25:55 +0100 (CET) From: "Salvatore D'Antonio" To: "'Nevil Brownlee'" References: <8b9118710c0f73581afe12789d16ae07.squirrel@www.trepanning.net> <50A1290E.6080200@cisco.com> <003d01cdc244$38cfce80$aa6f6b80$@dantonio@uniparthenope.it> <50AA5B41.20705@cisco.com> <00e801cdc673$6d62c2a0$482847e0$@dantonio@uniparthenope.it> <5119AB20.7000704@auckland.ac.nz> <000601ce08f4$6a80ee40$3f82cac0$@dantonio@uniparthenope.it> <51255CDF.7040008@auckland.ac.nz> In-Reply-To: <51255CDF.7040008@auckland.ac.nz> Date: Sat, 23 Feb 2013 15:25:59 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4PwoA+a6Oso2RLQsyvhp6TwN0SQQCDnb/g Content-Language: it Message-ID: <001b01ce11d1$b6848be0$238da3a0$@dantonio@uniparthenope.it> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.42/RELEASE, bases: 20130223 #9529837, check: 20130223 clean Cc: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org, secdir@ietf.org, ipfix-chairs@tools.ietf.org, iesg@ietf.org, 'Benoit Claise' Subject: [secdir] R: 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: Sat, 23 Feb 2013 14:26:04 -0000 Dear all, A new version of the Internet Draft has been submitted that addresses comments from Benoit and Dan Harkins. Kind regards, Salvatore -----Messaggio originale----- Da: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz]=20 Inviato: gioved=EC 21 febbraio 2013 00:32 A: Salvatore D'Antonio Cc: 'Benoit Claise'; = draft-ietf-ipfix-flow-selection-tech@tools.ietf.org; ipfix-chairs@tools.ietf.org Oggetto: Re: secdir review of draft-ietf-ipfix-flow-selection-tech Hi Salvatore: Draft submission deadline for IETF 86 is next Monday, 25 February. Any chance of getting the revised draft done before that, please? Cheers, Nevil On 12/02/13 8:41 PM, Salvatore D'Antonio wrote: > Dear Nevil, > > Thanks for your e-mail. Regrettably I could not work to the Draft in = the > last two months because I was fully involved in the preparation of the final > reports of the research projects of my University. > I just restarted to work to the document in order to implement the = changes > requested by Benoit and I plan to submit a new version early next = week. > > Kind regards, > > Salvatore > > > -----Messaggio originale----- > Da: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] > Inviato: marted=EC 12 febbraio 2013 03:38 > A: Salvatore D'Antonio > Cc: 'Benoit Claise'; = draft-ietf-ipfix-flow-selection-tech@tools.ietf.org; > ipfix-chairs@tools.ietf.org > Oggetto: Re: R: R: secdir review of = draft-ietf-ipfix-flow-selection-tech > > > Hi Salvatore: > > I'm getting set for IETF 86 in Orlando; I see that the flow-selection > draft has been sitting waiting for a revised draft for 130 days! > > Please can you get that published real soon now, it would be really > good to see this draft finally published! > > Cheers, Nevil > > > On 20/11/12 5:32 AM, Salvatore D'Antonio wrote: >> Dear Benoit, >> >> >> >> Ok, I will do. >> >> >> >> Thanks. >> >> >> >> Best regards, >> >> >> >> >> >> Salvatore >> >> >> >> >> >> >> >> Da: Benoit Claise [mailto:bclaise@cisco.com] >> Inviato: luned=EC 19 novembre 2012 17:16 >> A: Salvatore D'Antonio >> Cc: draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org >> Oggetto: Re: R: secdir review of draft-ietf-ipfix-flow-selection-tech >> >> >> >> Salvatore, >> >> Please answer Dan's comment via email before posting the draft, = unless >> you're sure that your resolution will resolve his issue. >> >> Regards, Benoit >> >> Dear all, >> >> >> >> I missed Dan's e-mail. I apologise for that. >> >> >> >> I will address Dan's comments in the new version of the Draft. >> >> >> >> Best regards, >> >> >> >> Salvatore >> >> >> >> >> >> >> >> Da: Benoit Claise [mailto:bclaise@cisco.com] >> Inviato: luned=EC 12 novembre 2012 17:51 >> A: draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org >> Cc: ipfix@ietf.org >> Oggetto: Fwd: secdir review of draft-ietf-ipfix-flow-selection-tech >> >> >> >> Dear authors, >> >> Reading my old emails, I'm not sure that you took into account Dan's >> feedback. >> At the very minimum, you should give a reply >> >> Regards, Benoit >> >> >> >> -------- Original Message -------- >> >> >> Subject: >> >> secdir review of draft-ietf-ipfix-flow-selection-tech >> >> >> 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 >> >> >> >> 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. >> >> >> >> >> >> >> >> >> _____ >> >> Nessun virus nel messaggio. >> Controllato da AVG - www.avg.com >> Versione: 2012.0.2221 / Database dei virus: 2441/5390 - Data di = rilascio: >> 12/11/2012 >> >> >> >> _____ >> >> Nessun virus nel messaggio. >> Controllato da AVG - www.avg.com >> Versione: 2012.0.2221 / Database dei virus: 2629/5404 - Data di = rilascio: >> 18/11/2012 >> >> > > --=20 --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand ----- Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 2013.0.2899 / Database dei virus: 2639/6120 - Data di = rilascio: 20/02/2013 From kent@bbn.com Mon Feb 25 04:41:56 2013 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 5838F21F92FE for ; Mon, 25 Feb 2013 04:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.448 X-Spam-Level: X-Spam-Status: No, score=-106.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0uE3TIThAIh for ; Mon, 25 Feb 2013 04:41:54 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6783E21F92FC for ; Mon, 25 Feb 2013 04:41:54 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:55965 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1U9xNL-0004nW-23; Mon, 25 Feb 2013 07:41:48 -0500 Message-ID: <512B5C07.4070602@bbn.com> Date: Mon, 25 Feb 2013 07:41:43 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: secdir , jiangsheng@huawei.com, =?UTF-8?B?U2VhbiBTaGU=?= =?UTF-8?B?biDmsojng4E=?= , john_brzozowski@cable.comcast.com, ted.lemon@nominum.com, volz@cisco.com, rdroms.ietf@gmail.com, brian@innovationslab.net Content-Type: multipart/alternative; boundary="------------000601020706070802040904" Subject: [secdir] review of draft-ietf-dhc-secure-dhcpv6-07 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, 25 Feb 2013 12:41:56 -0000 This is a multi-part message in MIME format. --------------000601020706070802040904 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit SECDIR review of draft-ietf-dhc-secure-dhcpv6-07 I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors and WG chairs should treat these comments just like any other last call comments. This document proposes use of CGAs to secure DHCPv6 traffic, principally to provide data origin authentication and connectionless integrity for messages transferred between a DHCPv6 server (or relay agent) and a client. These services are derived from the use of a CGA by the communicating peers. The document does not provide a thorough system-level description of how the security mechanisms are to be used, and how clients, servers, and relay agents might need to be configured accordingly. For example, if the primary focus is thwarting fake DHCPv6 server attacks, then a client might not need to signature a query directed to a server. On the other hand, if the goal is to enable servers to selectively provide service to clients, e.g., based on cached CGA values, then a client would need to sign a query. The document needs to provide additional background in this regard, to enable readers (and implementers) to understand what features need to be present in system components making use of these security mechanisms. A description of local configuration variables that can be used to achieve the desired system-level behavior is needed. Section 3 provides a very brief discussion of the vulnerabilities associated with unsecured DHCPv6, and then reviews the security mechanisms offered in RFC 3315. It notes that the symmetric key management approach offered in 3315 is difficult to manage, a conclusion with which I concur. However, the authors overstate the simplicity of their proposed approach, deferring to the Security Considerations section a discussion of public key management. This section also notes that 3315 suggests use of IPsec to secure communications between servers and relay agents (or between relay agents), but dismisses that approach due to complexity. I am less sympathetic to this statement. IPsec is already implemented in all major operating systems, so an argument about its complexity, relevant to a set of proposed new mechanisms, is not especially relevant. Perhaps the authors intend to argue that management of IPsec for this application is more complex than their proposed solution. If so, I suggest that the text in bullet “c” of Section 3 be revised. Section 4 describes the proposed mechanism. The section states the assumptions that underlie use of CGAs in this context, but it does so in a confusing manner. The use of CGAs provides intrinsic authentication of the sender of a signed message, in terms of the IPv6 address of the sender. For DHCPv6 clients, this may be all that is required, but the text does not make that argument. For DHCPv6 servers, clients (and relay agents) simple address authentication does not suffice; a client (or a relay agent) needs to know that the sender of a message is authorized to act as a server (or relay agent). The text is not at all clear on this point, i.e., it fails to state for which entities it is necessary to pre-configure CGA parameters, to enable meaningful authentication (and authorization). The text here states an exception to the need for pre-configuration saying that an entity could have “ … recorded [the parameters] from previous communications.” This leap of faith (LoF) key management approach is discussed again only in Section 7. The discussion there is superficial. More text is needed to explain when LoF may be viewed as appropriate, and to address issues such as how a client that acquired a server’s CGA would transition to a new server CGA, securely. Section 4 ends by noting that the “authentication options” (presumably the signature option) can be used to counter replay attacks. This is not quite accurate, i.e., it is the integrity aspect of the signature that provides a basis for anti-replay mechanisms, vs. the authenticationaspect. More worrisome is that fact that there is no later mention of anti-reply in the document. The authors need to add text discussing anti-replay in this context. Section 4.2 discusses algorithm agility, but does so only for hash algorithms. This section needs to be expanded to discuss signature algorithm agility as well. Also, the text here states that “mainly unilateral notification” is the means by which an algorithm change is made known to a peer communicant, but that not all senders in a network need to transition to a new algorithm at the same time. This section needs to describe how an orderly transition to a new algorithm can be effected in a network. For example, one might add an option that a sender could include in a message, indicating a preferred list of algorithms (signature and has) that it supports. This would enable a server to know whether clients are prepared to transition to a new algorithm. Much of the text in 4.2 should be moved to the Security Considerations section, as it is motivational material not describing the working of the protocol. Section 5 describes the enhancements to DHCPv6 to support the proposed security features. Section 5.1 defines an option to transfer a CGA parameters (as pre RFC 3972). This is a simple option and I didn’t see any problems with the description provided. Section 5.2 defines a signature option. There is a timestamp here, which is present to help “reduce the danger of replay attacks.” However, the processing rules for a receiver (Section 6.2) make no mention of this timestamp. This mismatch needs to be fixed. The description of what data is protected by the signature is a bit complex to follow. A diagram is needed. A padding field is defined, but there is no mention of what padding bits are to be used. Section 5.3 defines a signature option for relayed replies. It is used to enable encapsulation of a reply that passes through one or more relay agents, so that there are separate signatures for each agent and for the target client. The description here is not clear to me, especially if there is more than one relay agent Section 5.4 describes an option that carries the IPv6 address of a server, preserving it for authentication when a reply is relayed through an agent. This is a simple option, and its description seems fairly clear. Sections 6.1 and 6.2 provides processing rules for senders and receivers, respectively. This is a very good structure, but, as noted above, some details are missing, e.g., there is no mention of timestamp use. (If timestamp processing rules are defined elsewhere, e.g., 3515, then this text should include the relevant cite. The description of when the CGA, Signature and DUID options MUST and MUST NOT be used is sufficiently complex that a table needs be included. There is a reference to an Authentication Option near the bottom of page 11, but none is defined in this document. The opening discussion for Section6.2 is confusing when it discusses how a Secure DHCPv6 “enabled” receiver might, or might not, discard messages that omit the CGA and Signature options. The authors may need to distinguish between a receiver that is Secure DHCPv6 “capable” vs. “enabled” to clarify what they mean. Maybe the purported source address of the sender plays a roll here as well. Discarding a packet for which the required options are absent is a SHOULD, here. But, near the bottom of page 12, there is text that says a packet that does not pass all of the checks MUST be discarded. These two statement need to be reconciled. There is no discussion of how a receiver verifies that a message is from an authorized server or relay agent, e.g., by reference to pre-configured CGA data. There is no discussion of when a receiver should cache CGA data for future use, despite an allusion to this possibility in Section 4. These topics must be addressed if the processing rules are to be considered complete. The “minbits” description isbit confusing, as its name specifies a minimum key size, but the description discusses both min and max key sizes. Also, this variable needs to be augmented with an algorithm ID, so that it is clear to which algorithm the key size applies. Section 6.3 describes special processing performed by relay agents, above what is described for them as senders and receivers, in the preceding two sections. Because relay agent processing has already been discussed in 6.1 and 6.2, the additional text here seems confusing to me. The closing paragraph is especially confusing to me, but maybe DHCPv6 experts will find it understandable. The security considerations section states that “… clients should be pre-configured with the DHCPv6 server CGA.” This seems important enough to be “SHOULD” vs. “should.” Similar language is used to describe the need to pre-configure CGAs for relays and servers, and it too needs to be stated more firmly. In both cases the text states that how secure pre-configuration of CGAs is achieved is out of scope. Later in this section the authors suggest that a leaf of faith (LoF) approach to acquisition of these CGAs by clients may be a reasonable alternative to secure distribution of server CGA values. This suggestion ignores the issue of how a key change for a server will be accommodated, or how the addition of a new server would work. Absent a discussion of these issues, the LoF suggestion seems questionable. This section contains a brief discussion of collision attacks against hash functions, and why the current levels of attacks are not a serious concern in this context. Hash functions, per se, do not have a “non-repudiation feature” so I think the text here should be improved. Discussion of the hash function security in the SeND context seems relevant. As noted earlier, the test in 4.2 that talks about why hash functions are adequately secure for this context should move here, and the redundancies should be removed. --------------000601020706070802040904 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

SECDIR review of draft-ietf-dhc-secure-dhcpv6-07

 

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

 

This document proposes use of CGAs to secure DHCPv6 traffic, principally to provide data origin authentication and connectionless integrity for messages transferred between a DHCPv6 server (or relay agent) and a client. These services are derived from the use of a CGA by the communicating peers.

 

The document does not provide a thorough system-level description of how the security mechanisms are to be used, and how clients, servers, and relay agents might need to be configured accordingly. For example, if the primary focus is thwarting fake DHCPv6 server attacks, then a client might not need to signature a query directed to a server. On the other hand, if the goal is to enable servers to selectively provide service to clients, e.g., based on cached CGA values, then a client would need to sign a query. The document needs to provide additional background in this regard, to enable readers (and implementers) to understand what features need to be present in system components making use of these security mechanisms. A description of local configuration variables that can be used to achieve the desired system-level behavior is needed.

 

Section 3 provides a very brief discussion of the vulnerabilities associated with unsecured DHCPv6, and then reviews the security mechanisms offered in RFC 3315. It notes that the symmetric key management approach offered in 3315 is difficult to manage, a conclusion with which I concur. However, the authors overstate the simplicity of their proposed approach, deferring to the Security Considerations section a discussion of public key management.

 

This section also notes that 3315 suggests use of IPsec to secure communications between servers and relay agents (or between relay agents), but dismisses that approach due to complexity. I am less sympathetic to this statement. IPsec is already implemented in all major operating systems, so an argument about its complexity, relevant to a set of proposed new mechanisms, is not especially relevant. Perhaps the authors intend to argue that management of IPsec for this application is more complex than their proposed solution. If so, I suggest that the text in bullet “c” of Section 3 be revised.

 

Section 4 describes the proposed mechanism. The section states the assumptions that underlie use of CGAs in this context, but it does so in a confusing manner. The use of CGAs provides intrinsic authentication of the sender of a signed message, in terms of the IPv6 address of the sender. For DHCPv6 clients, this may be all that is required, but the text does not make that argument. For DHCPv6 servers, clients (and relay agents) simple address authentication does not suffice; a client (or a relay agent) needs to know that the sender of a message is authorized to act as a server (or relay agent). The text is not at all clear on this point, i.e., it fails to state for which entities it is necessary to pre-configure CGA parameters, to enable meaningful authentication (and authorization).

 

The text here states an exception to the need for pre-configuration saying  that an entity could have “ … recorded [the parameters] from previous communications.” This leap of faith (LoF) key management approach is discussed again only in Section 7. The discussion there is superficial. More text is needed to explain when LoF may be viewed as appropriate, and to address issues such as how a client that acquired a server’s CGA would transition to a new server CGA, securely.

 

 

Section 4 ends by noting that the “authentication options” (presumably the signature option) can be used to counter replay attacks. This is not quite accurate, i.e., it is the integrity aspect of the signature that provides a basis for anti-replay mechanisms, vs. the authentication  aspect. More worrisome is that fact that there is no later mention of anti-reply in the document. The authors need to add text discussing anti-replay in this context.

 

Section 4.2 discusses algorithm agility, but does so only for hash algorithms. This section needs to be expanded to discuss signature algorithm agility as well. Also, the text here states that “mainly unilateral notification” is the means by which an algorithm change is made known to a peer communicant, but that not all senders in a network need to transition to a new algorithm at the same time. This section needs to describe how an orderly transition to a new algorithm can be effected in a network. For example, one might add an option that a sender could include in a message, indicating a preferred list of algorithms (signature and has) that it supports. This would enable a server to know whether clients are prepared to transition to a new algorithm.

 

Much of the text in 4.2 should be moved to the Security Considerations section, as it is motivational material not describing the working of the protocol.

 

Section 5 describes the enhancements to DHCPv6 to support the proposed security features. Section 5.1 defines an option to transfer a CGA parameters (as pre RFC 3972). This is a simple option and I didn’t see any problems with the description provided.

 

Section 5.2 defines a signature option. There is a timestamp here, which is present to help “reduce the danger of replay attacks.” However, the processing rules for a receiver (Section 6.2) make no mention of this timestamp. This mismatch needs to be fixed. The description of what data is protected by the signature is a bit complex to follow. A diagram is needed. A padding field is defined, but there is no mention of what padding bits are to be used.

 

Section 5.3 defines a signature option for relayed replies. It is used to enable encapsulation of a reply that passes through one or more relay agents, so that there are separate signatures for each agent and for the target client. The description here is not clear to me, especially if there is more than one relay agent

 

Section 5.4 describes an option that carries the IPv6 address of a server, preserving it for authentication when a reply is relayed through an agent. This is a simple option, and its description seems fairly clear.

 

Sections 6.1 and 6.2 provides processing rules for senders and receivers, respectively. This is a very good structure, but, as noted above, some details are missing, e.g., there is no mention of timestamp use. (If timestamp processing rules are defined elsewhere, e.g., 3515, then this text should include the relevant cite. The description of when the CGA, Signature and DUID options MUST and MUST NOT be used is sufficiently complex that a table needs be included. There is a reference to an Authentication Option near the bottom of page 11, but none is defined in this document.

 

The opening discussion for Section  6.2 is confusing when it discusses how a Secure DHCPv6 “enabled” receiver might, or might not, discard messages that omit the CGA and Signature options. The authors may need to distinguish between a receiver that is Secure DHCPv6 “capable” vs. “enabled” to clarify what they mean. Maybe the purported source address of the sender plays a roll here as well. Discarding a packet for which the required options are absent is a SHOULD, here. But, near the bottom of page 12, there is text that says a packet that does not pass all of the checks MUST be discarded. These two statement need to be reconciled. There is no discussion of how a receiver verifies that a message is from an authorized server or relay agent, e.g., by reference to pre-configured CGA data.  There is no discussion of when a receiver should cache CGA data for future use, despite an allusion to this possibility in Section 4. These topics must be addressed if the processing rules are to be considered complete. The “minbits” description is  bit confusing, as its name specifies a minimum key size, but the description discusses both min and max key sizes. Also, this variable needs to be augmented with an algorithm ID, so that it is clear to which algorithm the key size applies.

 

Section 6.3 describes special processing performed by relay agents, above what is described for them as senders and receivers, in the preceding two sections. Because relay agent processing has already been discussed in 6.1 and 6.2, the additional text here seems confusing to me. The closing paragraph is especially confusing to me, but maybe DHCPv6 experts will find it understandable.

 

The security considerations section states that “… clients should be pre-configured with the DHCPv6 server CGA.” This seems important enough to be “SHOULD” vs. “should.” Similar language is used to describe the need to pre-configure CGAs for relays and servers, and it too needs to be stated more firmly. In both cases the text states that how secure pre-configuration of CGAs is achieved is out of scope. Later in this section the authors suggest that a leaf of faith (LoF) approach to acquisition of these CGAs by clients may be a reasonable alternative to secure distribution of server CGA values. This suggestion ignores the issue of how a key change for a server will be accommodated, or how the addition of a new server would work. Absent a discussion of these issues, the LoF suggestion seems questionable.

 

This section contains a brief discussion of collision attacks against hash functions, and why the current levels of attacks are not a serious concern in this context. Hash functions, per se, do not have a “non-repudiation feature” so I think the text here should be improved. Discussion of the hash function security in the SeND context seems relevant. As noted earlier, the test in 4.2 that talks about why hash functions are adequately secure for this context should move here, and the redundancies should be removed.

 

 

 

 

--------------000601020706070802040904-- From Ted.Lemon@nominum.com Mon Feb 25 09:28:39 2013 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 332C221F9345 for ; Mon, 25 Feb 2013 09:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.709 X-Spam-Level: X-Spam-Status: No, score=-105.709 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdqFC7-GVIFH for ; Mon, 25 Feb 2013 09:28:38 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC1921F9530 for ; Mon, 25 Feb 2013 09:28:35 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUSufPxc2gq9NMCGkHC7/0kCGnrtMtxtg@postini.com; Mon, 25 Feb 2013 09:28:35 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 75D27108040 for ; Mon, 25 Feb 2013 09:28:30 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 54DD3190043; Mon, 25 Feb 2013 09:28:30 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 09:28:30 -0800 From: Ted Lemon To: Stephen Kent Thread-Topic: review of draft-ietf-dhc-secure-dhcpv6-07 Thread-Index: AQHOE1WCnKD+JzTBcUKPhHHlx5tRLJiLWn8A Date: Mon, 25 Feb 2013 17:28:30 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074749F0B9@mbx-01.win.nominum.com> References: <512B5C07.4070602@bbn.com> In-Reply-To: <512B5C07.4070602@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="gb2312" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "" , "" , secdir , =?gb2312?B?U2VhbiBTaGVuIMnyy7g=?= , "" , "" , "" Subject: Re: [secdir] review of draft-ietf-dhc-secure-dhcpv6-07 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, 25 Feb 2013 17:28:39 -0000 V293LCB0aGFua3MgdmVyeSBtdWNoIGZvciB0aGUgdGhvcm91Z2ggcmV2aWV3ISAgIEkgd2lsbCBk ZWZlciB0byB0aGUgYXV0aG9ycyBvbiB3aGF0IHRvIGRvIG5leHQsIGJ1dCBqdXN0IHdhbnRlZCB0 byBleHByZXNzIG15IGFwcHJlY2lhdGlvbiBmb3IgeW91ciB0aG9yb3VnaG5lc3MhDQoNCg== From volz@cisco.com Mon Feb 25 10:53:18 2013 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 0D3ED21E8042 for ; Mon, 25 Feb 2013 10:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.722 X-Spam-Level: X-Spam-Status: No, score=-9.722 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxbynmTQspB9 for ; Mon, 25 Feb 2013 10:53:16 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1E021F934C for ; Mon, 25 Feb 2013 10:53:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=424; q=dns/txt; s=iport; t=1361818396; x=1363027996; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zojgP045hu5luGRUarwrjYBPL4tgjwdxhlTne1Vtq6k=; b=kjSDLeBH3iwgEMjbtW9Fh4GUYFSFukfobHi5PrRLCV4pMCcSwt9+lDbt qQ9CVJGk2QC9OrCNVadR+mUYi/c3t3CWf6feZikw6T73D64xNPFRtnjva 56ncUgAq7Z4W+hITMoxGvRRbesU6VEf9X8QAoAw05y82Wj6Y0PAkkis1U Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAHCyK1GtJV2Y/2dsb2JhbABFhghHuwgNeBZzgh8BAQEDATRFBQsCAQgcKAICMCUCBA4FiA0GkjqafQiSJYEfjTwzBwSCJTZhA5Y9kGWDBw X-IronPort-AV: E=Sophos;i="4.84,736,1355097600"; d="scan'208";a="180736795" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 25 Feb 2013 18:53:05 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1PIr5tF025364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Feb 2013 18:53:05 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 12:53:04 -0600 From: "Bernie Volz (volz)" To: Stephen Kent Thread-Topic: review of draft-ietf-dhc-secure-dhcpv6-07 Thread-Index: AQHOE1WD9Huc28oz3UyHumQn5MMuMJiLOPgA//+zC2g= Date: Mon, 25 Feb 2013 18:53:03 +0000 Message-ID: <8AFC46FD-88D7-40AB-AE67-FE836DB6F109@cisco.com> References: <512B5C07.4070602@bbn.com>, <8D23D4052ABE7A4490E77B1A012B63074749F0B9@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074749F0B9@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "" , Ted Lemon , secdir , =?gb2312?B?U2VhbiBTaGVuIMnyy7g=?= , "" , "" , "" Subject: Re: [secdir] review of draft-ietf-dhc-secure-dhcpv6-07 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, 25 Feb 2013 18:53:18 -0000 WWVzLCBhcyBUZWQgaW5kaWNhdGVkLCB2ZXJ5IHRob3JvdWdoLiBUaGFua3MuIA0KDQotIEJlcm5p ZQ0KDQpPbiBGZWIgMjUsIDIwMTMsIGF0IDEyOjI4IFBNLCAiVGVkIExlbW9uIiA8VGVkLkxlbW9u QG5vbWludW0uY29tPiB3cm90ZToNCg0KPiBXb3csIHRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHRoZSB0 aG9yb3VnaCByZXZpZXchICAgSSB3aWxsIGRlZmVyIHRvIHRoZSBhdXRob3JzIG9uIHdoYXQgdG8g ZG8gbmV4dCwgYnV0IGp1c3Qgd2FudGVkIHRvIGV4cHJlc3MgbXkgYXBwcmVjaWF0aW9uIGZvciB5 b3VyIHRob3JvdWdobmVzcyENCj4gDQo= From jiangsheng@huawei.com Mon Feb 25 19:31:57 2013 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 C0A9B21E8166 for ; Mon, 25 Feb 2013 19:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSA+0Xft4H5M for ; Mon, 25 Feb 2013 19:31:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC2621E80B3 for ; Mon, 25 Feb 2013 19:31:53 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOU29967; Tue, 26 Feb 2013 03:31:52 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 03:31:47 +0000 Received: from SZXEML461-HUB.china.huawei.com (10.82.67.204) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 03:31:48 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.45]) by szxeml461-hub.china.huawei.com ([10.82.67.204]) with mapi id 14.01.0323.007; Tue, 26 Feb 2013 11:31:41 +0800 From: Sheng Jiang To: Stephen Kent , secdir , =?utf-8?B?U2VhbiBTaGVuIOayiOeDgQ==?= , "john_brzozowski@cable.comcast.com" , "ted.lemon@nominum.com" , "volz@cisco.com" , "rdroms.ietf@gmail.com" , "brian@innovationslab.net" Thread-Topic: review of draft-ietf-dhc-secure-dhcpv6-07 Thread-Index: AQHOE1WDIIwIS/pLb0ezT5ZYexAJSZiLcIPw Date: Tue, 26 Feb 2013 03:31:40 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923A00D720@szxeml545-mbx.china.huawei.com> References: <512B5C07.4070602@bbn.com> In-Reply-To: <512B5C07.4070602@bbn.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B923A00D720szxeml545mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [secdir] review of draft-ietf-dhc-secure-dhcpv6-07 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, 26 Feb 2013 03:31:57 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B923A00D720szxeml545mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIFN0ZXBoZW4sDQoNClRoYW5rcyBzbyBtdWNoIGZvciB5b3VyIGRldGFpbGVkIHJldmlldy4g WW91ciBjb21tZW50cyBhcmUgaW1wb3J0YW50IGZvciB1cyB0byBpbXByb3ZlIHRoZSBkcmFmdC4g V2Ugd2lsbCB3b3JrIG9uIHRoYXQgaW4gdGhlIG5leHQgdXBkYXRlLiBNYXliZSBzb21lIHByaXZh dGUgY29tbXVuaWNhdGlvbiB3aWxsIGJlIGZvciB5b3VyIGZ1cnRoZXIgYWR2aWNlcy4NCg0KTWFu eSB0aGFua3MgYW5kIGJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KRnJvbTogU3RlcGhlbiBLZW50 IFttYWlsdG86a2VudEBiYm4uY29tXQ0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAyNSwgMjAxMyA4 OjQyIFBNDQpUbzogc2VjZGlyOyBTaGVuZyBKaWFuZzsgU2VhbiBTaGVuIOayiOeDgTsgam9obl9i cnpvem93c2tpQGNhYmxlLmNvbWNhc3QuY29tOyB0ZWQubGVtb25Abm9taW51bS5jb207IHZvbHpA Y2lzY28uY29tOyByZHJvbXMuaWV0ZkBnbWFpbC5jb207IGJyaWFuQGlubm92YXRpb25zbGFiLm5l dA0KU3ViamVjdDogcmV2aWV3IG9mIGRyYWZ0LWlldGYtZGhjLXNlY3VyZS1kaGNwdjYtMDcNCg0K U0VDRElSIHJldmlldyBvZiBkcmFmdC1pZXRmLWRoYy1zZWN1cmUtZGhjcHY2LTA3DQoNCkkgcmV2 aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdz IG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vz c2VkIGJ5IHRoZSBJRVNHLiAgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBm b3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiAgRG9jdW1lbnQg ZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxp a2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0KVGhpcyBkb2N1bWVudCBwcm9wb3Nl cyB1c2Ugb2YgQ0dBcyB0byBzZWN1cmUgREhDUHY2IHRyYWZmaWMsIHByaW5jaXBhbGx5IHRvIHBy b3ZpZGUgZGF0YSBvcmlnaW4gYXV0aGVudGljYXRpb24gYW5kIGNvbm5lY3Rpb25sZXNzIGludGVn cml0eSBmb3IgbWVzc2FnZXMgdHJhbnNmZXJyZWQgYmV0d2VlbiBhIERIQ1B2NiBzZXJ2ZXIgKG9y IHJlbGF5IGFnZW50KSBhbmQgYSBjbGllbnQuIFRoZXNlIHNlcnZpY2VzIGFyZSBkZXJpdmVkIGZy b20gdGhlIHVzZSBvZiBhIENHQSBieSB0aGUgY29tbXVuaWNhdGluZyBwZWVycy4NCg0KVGhlIGRv Y3VtZW50IGRvZXMgbm90IHByb3ZpZGUgYSB0aG9yb3VnaCBzeXN0ZW0tbGV2ZWwgZGVzY3JpcHRp b24gb2YgaG93IHRoZSBzZWN1cml0eSBtZWNoYW5pc21zIGFyZSB0byBiZSB1c2VkLCBhbmQgaG93 IGNsaWVudHMsIHNlcnZlcnMsIGFuZCByZWxheSBhZ2VudHMgbWlnaHQgbmVlZCB0byBiZSBjb25m aWd1cmVkIGFjY29yZGluZ2x5LiBGb3IgZXhhbXBsZSwgaWYgdGhlIHByaW1hcnkgZm9jdXMgaXMg dGh3YXJ0aW5nIGZha2UgREhDUHY2IHNlcnZlciBhdHRhY2tzLCB0aGVuIGEgY2xpZW50IG1pZ2h0 IG5vdCBuZWVkIHRvIHNpZ25hdHVyZSBhIHF1ZXJ5IGRpcmVjdGVkIHRvIGEgc2VydmVyLiBPbiB0 aGUgb3RoZXIgaGFuZCwgaWYgdGhlIGdvYWwgaXMgdG8gZW5hYmxlIHNlcnZlcnMgdG8gc2VsZWN0 aXZlbHkgcHJvdmlkZSBzZXJ2aWNlIHRvIGNsaWVudHMsIGUuZy4sIGJhc2VkIG9uIGNhY2hlZCBD R0EgdmFsdWVzLCB0aGVuIGEgY2xpZW50IHdvdWxkIG5lZWQgdG8gc2lnbiBhIHF1ZXJ5LiBUaGUg ZG9jdW1lbnQgbmVlZHMgdG8gcHJvdmlkZSBhZGRpdGlvbmFsIGJhY2tncm91bmQgaW4gdGhpcyBy ZWdhcmQsIHRvIGVuYWJsZSByZWFkZXJzIChhbmQgaW1wbGVtZW50ZXJzKSB0byB1bmRlcnN0YW5k IHdoYXQgZmVhdHVyZXMgbmVlZCB0byBiZSBwcmVzZW50IGluIHN5c3RlbSBjb21wb25lbnRzIG1h a2luZyB1c2Ugb2YgdGhlc2Ugc2VjdXJpdHkgbWVjaGFuaXNtcy4gQSBkZXNjcmlwdGlvbiBvZiBs b2NhbCBjb25maWd1cmF0aW9uIHZhcmlhYmxlcyB0aGF0IGNhbiBiZSB1c2VkIHRvIGFjaGlldmUg dGhlIGRlc2lyZWQgc3lzdGVtLWxldmVsIGJlaGF2aW9yIGlzIG5lZWRlZC4NCg0KU2VjdGlvbiAz IHByb3ZpZGVzIGEgdmVyeSBicmllZiBkaXNjdXNzaW9uIG9mIHRoZSB2dWxuZXJhYmlsaXRpZXMg YXNzb2NpYXRlZCB3aXRoIHVuc2VjdXJlZCBESENQdjYsIGFuZCB0aGVuIHJldmlld3MgdGhlIHNl Y3VyaXR5IG1lY2hhbmlzbXMgb2ZmZXJlZCBpbiBSRkMgMzMxNS4gSXQgbm90ZXMgdGhhdCB0aGUg c3ltbWV0cmljIGtleSBtYW5hZ2VtZW50IGFwcHJvYWNoIG9mZmVyZWQgaW4gMzMxNSBpcyBkaWZm aWN1bHQgdG8gbWFuYWdlLCBhIGNvbmNsdXNpb24gd2l0aCB3aGljaCBJIGNvbmN1ci4gSG93ZXZl ciwgdGhlIGF1dGhvcnMgb3ZlcnN0YXRlIHRoZSBzaW1wbGljaXR5IG9mIHRoZWlyIHByb3Bvc2Vk IGFwcHJvYWNoLCBkZWZlcnJpbmcgdG8gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rp b24gYSBkaXNjdXNzaW9uIG9mIHB1YmxpYyBrZXkgbWFuYWdlbWVudC4NCg0KVGhpcyBzZWN0aW9u IGFsc28gbm90ZXMgdGhhdCAzMzE1IHN1Z2dlc3RzIHVzZSBvZiBJUHNlYyB0byBzZWN1cmUgY29t bXVuaWNhdGlvbnMgYmV0d2VlbiBzZXJ2ZXJzIGFuZCByZWxheSBhZ2VudHMgKG9yIGJldHdlZW4g cmVsYXkgYWdlbnRzKSwgYnV0IGRpc21pc3NlcyB0aGF0IGFwcHJvYWNoIGR1ZSB0byBjb21wbGV4 aXR5LiBJIGFtIGxlc3Mgc3ltcGF0aGV0aWMgdG8gdGhpcyBzdGF0ZW1lbnQuIElQc2VjIGlzIGFs cmVhZHkgaW1wbGVtZW50ZWQgaW4gYWxsIG1ham9yIG9wZXJhdGluZyBzeXN0ZW1zLCBzbyBhbiBh cmd1bWVudCBhYm91dCBpdHMgY29tcGxleGl0eSwgcmVsZXZhbnQgdG8gYSBzZXQgb2YgcHJvcG9z ZWQgbmV3IG1lY2hhbmlzbXMsIGlzIG5vdCBlc3BlY2lhbGx5IHJlbGV2YW50LiBQZXJoYXBzIHRo ZSBhdXRob3JzIGludGVuZCB0byBhcmd1ZSB0aGF0IG1hbmFnZW1lbnQgb2YgSVBzZWMgZm9yIHRo aXMgYXBwbGljYXRpb24gaXMgbW9yZSBjb21wbGV4IHRoYW4gdGhlaXIgcHJvcG9zZWQgc29sdXRp b24uIElmIHNvLCBJIHN1Z2dlc3QgdGhhdCB0aGUgdGV4dCBpbiBidWxsZXQg4oCcY+KAnSBvZiBT ZWN0aW9uIDMgYmUgcmV2aXNlZC4NCg0KDQpTZWN0aW9uIDQgZGVzY3JpYmVzIHRoZSBwcm9wb3Nl ZCBtZWNoYW5pc20uIFRoZSBzZWN0aW9uIHN0YXRlcyB0aGUgYXNzdW1wdGlvbnMgdGhhdCB1bmRl cmxpZSB1c2Ugb2YgQ0dBcyBpbiB0aGlzIGNvbnRleHQsIGJ1dCBpdCBkb2VzIHNvIGluIGEgY29u ZnVzaW5nIG1hbm5lci4gVGhlIHVzZSBvZiBDR0FzIHByb3ZpZGVzIGludHJpbnNpYyBhdXRoZW50 aWNhdGlvbiBvZiB0aGUgc2VuZGVyIG9mIGEgc2lnbmVkIG1lc3NhZ2UsIGluIHRlcm1zIG9mIHRo ZSBJUHY2IGFkZHJlc3Mgb2YgdGhlIHNlbmRlci4gRm9yIERIQ1B2NiBjbGllbnRzLCB0aGlzIG1h eSBiZSBhbGwgdGhhdCBpcyByZXF1aXJlZCwgYnV0IHRoZSB0ZXh0IGRvZXMgbm90IG1ha2UgdGhh dCBhcmd1bWVudC4gRm9yIERIQ1B2NiBzZXJ2ZXJzLCBjbGllbnRzIChhbmQgcmVsYXkgYWdlbnRz KSBzaW1wbGUgYWRkcmVzcyBhdXRoZW50aWNhdGlvbiBkb2VzIG5vdCBzdWZmaWNlOyBhIGNsaWVu dCAob3IgYSByZWxheSBhZ2VudCkgbmVlZHMgdG8ga25vdyB0aGF0IHRoZSBzZW5kZXIgb2YgYSBt ZXNzYWdlIGlzIGF1dGhvcml6ZWQgdG8gYWN0IGFzIGEgc2VydmVyIChvciByZWxheSBhZ2VudCku IFRoZSB0ZXh0IGlzIG5vdCBhdCBhbGwgY2xlYXIgb24gdGhpcyBwb2ludCwgaS5lLiwgaXQgZmFp bHMgdG8gc3RhdGUgZm9yIHdoaWNoIGVudGl0aWVzIGl0IGlzIG5lY2Vzc2FyeSB0byBwcmUtY29u ZmlndXJlIENHQSBwYXJhbWV0ZXJzLCB0byBlbmFibGUgbWVhbmluZ2Z1bCBhdXRoZW50aWNhdGlv biAoYW5kIGF1dGhvcml6YXRpb24pLg0KDQoNCg0KVGhlIHRleHQgaGVyZSBzdGF0ZXMgYW4gZXhj ZXB0aW9uIHRvIHRoZSBuZWVkIGZvciBwcmUtY29uZmlndXJhdGlvbiBzYXlpbmcgIHRoYXQgYW4g ZW50aXR5IGNvdWxkIGhhdmUg4oCcIOKApiByZWNvcmRlZCBbdGhlIHBhcmFtZXRlcnNdIGZyb20g cHJldmlvdXMgY29tbXVuaWNhdGlvbnMu4oCdIFRoaXMgbGVhcCBvZiBmYWl0aCAoTG9GKSBrZXkg bWFuYWdlbWVudCBhcHByb2FjaCBpcyBkaXNjdXNzZWQgYWdhaW4gb25seSBpbiBTZWN0aW9uIDcu IFRoZSBkaXNjdXNzaW9uIHRoZXJlIGlzIHN1cGVyZmljaWFsLiBNb3JlIHRleHQgaXMgbmVlZGVk IHRvIGV4cGxhaW4gd2hlbiBMb0YgbWF5IGJlIHZpZXdlZCBhcyBhcHByb3ByaWF0ZSwgYW5kIHRv IGFkZHJlc3MgaXNzdWVzIHN1Y2ggYXMgaG93IGEgY2xpZW50IHRoYXQgYWNxdWlyZWQgYSBzZXJ2 ZXLigJlzIENHQSB3b3VsZCB0cmFuc2l0aW9uIHRvIGEgbmV3IHNlcnZlciBDR0EsIHNlY3VyZWx5 Lg0KDQoNCg0KDQoNClNlY3Rpb24gNCBlbmRzIGJ5IG5vdGluZyB0aGF0IHRoZSDigJxhdXRoZW50 aWNhdGlvbiBvcHRpb25z4oCdIChwcmVzdW1hYmx5IHRoZSBzaWduYXR1cmUgb3B0aW9uKSBjYW4g YmUgdXNlZCB0byBjb3VudGVyIHJlcGxheSBhdHRhY2tzLiBUaGlzIGlzIG5vdCBxdWl0ZSBhY2N1 cmF0ZSwgaS5lLiwgaXQgaXMgdGhlIGludGVncml0eSBhc3BlY3Qgb2YgdGhlIHNpZ25hdHVyZSB0 aGF0IHByb3ZpZGVzIGEgYmFzaXMgZm9yIGFudGktcmVwbGF5IG1lY2hhbmlzbXMsIHZzLiB0aGUg YXV0aGVudGljYXRpb24gIGFzcGVjdC4gTW9yZSB3b3JyaXNvbWUgaXMgdGhhdCBmYWN0IHRoYXQg dGhlcmUgaXMgbm8gbGF0ZXIgbWVudGlvbiBvZiBhbnRpLXJlcGx5IGluIHRoZSBkb2N1bWVudC4g VGhlIGF1dGhvcnMgbmVlZCB0byBhZGQgdGV4dCBkaXNjdXNzaW5nIGFudGktcmVwbGF5IGluIHRo aXMgY29udGV4dC4NCg0KDQoNClNlY3Rpb24gNC4yIGRpc2N1c3NlcyBhbGdvcml0aG0gYWdpbGl0 eSwgYnV0IGRvZXMgc28gb25seSBmb3IgaGFzaCBhbGdvcml0aG1zLiBUaGlzIHNlY3Rpb24gbmVl ZHMgdG8gYmUgZXhwYW5kZWQgdG8gZGlzY3VzcyBzaWduYXR1cmUgYWxnb3JpdGhtIGFnaWxpdHkg YXMgd2VsbC4gQWxzbywgdGhlIHRleHQgaGVyZSBzdGF0ZXMgdGhhdCDigJxtYWlubHkgdW5pbGF0 ZXJhbCBub3RpZmljYXRpb27igJ0gaXMgdGhlIG1lYW5zIGJ5IHdoaWNoIGFuIGFsZ29yaXRobSBj aGFuZ2UgaXMgbWFkZSBrbm93biB0byBhIHBlZXIgY29tbXVuaWNhbnQsIGJ1dCB0aGF0IG5vdCBh bGwgc2VuZGVycyBpbiBhIG5ldHdvcmsgbmVlZCB0byB0cmFuc2l0aW9uIHRvIGEgbmV3IGFsZ29y aXRobSBhdCB0aGUgc2FtZSB0aW1lLiBUaGlzIHNlY3Rpb24gbmVlZHMgdG8gZGVzY3JpYmUgaG93 IGFuIG9yZGVybHkgdHJhbnNpdGlvbiB0byBhIG5ldyBhbGdvcml0aG0gY2FuIGJlIGVmZmVjdGVk IGluIGEgbmV0d29yay4gRm9yIGV4YW1wbGUsIG9uZSBtaWdodCBhZGQgYW4gb3B0aW9uIHRoYXQg YSBzZW5kZXIgY291bGQgaW5jbHVkZSBpbiBhIG1lc3NhZ2UsIGluZGljYXRpbmcgYSBwcmVmZXJy ZWQgbGlzdCBvZiBhbGdvcml0aG1zIChzaWduYXR1cmUgYW5kIGhhcykgdGhhdCBpdCBzdXBwb3J0 cy4gVGhpcyB3b3VsZCBlbmFibGUgYSBzZXJ2ZXIgdG8ga25vdyB3aGV0aGVyIGNsaWVudHMgYXJl IHByZXBhcmVkIHRvIHRyYW5zaXRpb24gdG8gYSBuZXcgYWxnb3JpdGhtLg0KDQoNCg0KTXVjaCBv ZiB0aGUgdGV4dCBpbiA0LjIgc2hvdWxkIGJlIG1vdmVkIHRvIHRoZSBTZWN1cml0eSBDb25zaWRl cmF0aW9ucyBzZWN0aW9uLCBhcyBpdCBpcyBtb3RpdmF0aW9uYWwgbWF0ZXJpYWwgbm90IGRlc2Ny aWJpbmcgdGhlIHdvcmtpbmcgb2YgdGhlIHByb3RvY29sLg0KDQoNCg0KU2VjdGlvbiA1IGRlc2Ny aWJlcyB0aGUgZW5oYW5jZW1lbnRzIHRvIERIQ1B2NiB0byBzdXBwb3J0IHRoZSBwcm9wb3NlZCBz ZWN1cml0eSBmZWF0dXJlcy4gU2VjdGlvbiA1LjEgZGVmaW5lcyBhbiBvcHRpb24gdG8gdHJhbnNm ZXIgYSBDR0EgcGFyYW1ldGVycyAoYXMgcHJlIFJGQyAzOTcyKS4gVGhpcyBpcyBhIHNpbXBsZSBv cHRpb24gYW5kIEkgZGlkbuKAmXQgc2VlIGFueSBwcm9ibGVtcyB3aXRoIHRoZSBkZXNjcmlwdGlv biBwcm92aWRlZC4NCg0KDQoNClNlY3Rpb24gNS4yIGRlZmluZXMgYSBzaWduYXR1cmUgb3B0aW9u LiBUaGVyZSBpcyBhIHRpbWVzdGFtcCBoZXJlLCB3aGljaCBpcyBwcmVzZW50IHRvIGhlbHAg4oCc cmVkdWNlIHRoZSBkYW5nZXIgb2YgcmVwbGF5IGF0dGFja3Mu4oCdIEhvd2V2ZXIsIHRoZSBwcm9j ZXNzaW5nIHJ1bGVzIGZvciBhIHJlY2VpdmVyIChTZWN0aW9uIDYuMikgbWFrZSBubyBtZW50aW9u IG9mIHRoaXMgdGltZXN0YW1wLiBUaGlzIG1pc21hdGNoIG5lZWRzIHRvIGJlIGZpeGVkLiBUaGUg ZGVzY3JpcHRpb24gb2Ygd2hhdCBkYXRhIGlzIHByb3RlY3RlZCBieSB0aGUgc2lnbmF0dXJlIGlz IGEgYml0IGNvbXBsZXggdG8gZm9sbG93LiBBIGRpYWdyYW0gaXMgbmVlZGVkLiBBIHBhZGRpbmcg ZmllbGQgaXMgZGVmaW5lZCwgYnV0IHRoZXJlIGlzIG5vIG1lbnRpb24gb2Ygd2hhdCBwYWRkaW5n IGJpdHMgYXJlIHRvIGJlIHVzZWQuDQoNCg0KDQpTZWN0aW9uIDUuMyBkZWZpbmVzIGEgc2lnbmF0 dXJlIG9wdGlvbiBmb3IgcmVsYXllZCByZXBsaWVzLiBJdCBpcyB1c2VkIHRvIGVuYWJsZSBlbmNh cHN1bGF0aW9uIG9mIGEgcmVwbHkgdGhhdCBwYXNzZXMgdGhyb3VnaCBvbmUgb3IgbW9yZSByZWxh eSBhZ2VudHMsIHNvIHRoYXQgdGhlcmUgYXJlIHNlcGFyYXRlIHNpZ25hdHVyZXMgZm9yIGVhY2gg YWdlbnQgYW5kIGZvciB0aGUgdGFyZ2V0IGNsaWVudC4gVGhlIGRlc2NyaXB0aW9uIGhlcmUgaXMg bm90IGNsZWFyIHRvIG1lLCBlc3BlY2lhbGx5IGlmIHRoZXJlIGlzIG1vcmUgdGhhbiBvbmUgcmVs YXkgYWdlbnQNCg0KDQoNClNlY3Rpb24gNS40IGRlc2NyaWJlcyBhbiBvcHRpb24gdGhhdCBjYXJy aWVzIHRoZSBJUHY2IGFkZHJlc3Mgb2YgYSBzZXJ2ZXIsIHByZXNlcnZpbmcgaXQgZm9yIGF1dGhl bnRpY2F0aW9uIHdoZW4gYSByZXBseSBpcyByZWxheWVkIHRocm91Z2ggYW4gYWdlbnQuIFRoaXMg aXMgYSBzaW1wbGUgb3B0aW9uLCBhbmQgaXRzIGRlc2NyaXB0aW9uIHNlZW1zIGZhaXJseSBjbGVh ci4NCg0KDQoNClNlY3Rpb25zIDYuMSBhbmQgNi4yIHByb3ZpZGVzIHByb2Nlc3NpbmcgcnVsZXMg Zm9yIHNlbmRlcnMgYW5kIHJlY2VpdmVycywgcmVzcGVjdGl2ZWx5LiBUaGlzIGlzIGEgdmVyeSBn b29kIHN0cnVjdHVyZSwgYnV0LCBhcyBub3RlZCBhYm92ZSwgc29tZSBkZXRhaWxzIGFyZSBtaXNz aW5nLCBlLmcuLCB0aGVyZSBpcyBubyBtZW50aW9uIG9mIHRpbWVzdGFtcCB1c2UuIChJZiB0aW1l c3RhbXAgcHJvY2Vzc2luZyBydWxlcyBhcmUgZGVmaW5lZCBlbHNld2hlcmUsIGUuZy4sIDM1MTUs IHRoZW4gdGhpcyB0ZXh0IHNob3VsZCBpbmNsdWRlIHRoZSByZWxldmFudCBjaXRlLiBUaGUgZGVz Y3JpcHRpb24gb2Ygd2hlbiB0aGUgQ0dBLCBTaWduYXR1cmUgYW5kIERVSUQgb3B0aW9ucyBNVVNU IGFuZCBNVVNUIE5PVCBiZSB1c2VkIGlzIHN1ZmZpY2llbnRseSBjb21wbGV4IHRoYXQgYSB0YWJs ZSBuZWVkcyBiZSBpbmNsdWRlZC4gVGhlcmUgaXMgYSByZWZlcmVuY2UgdG8gYW4gQXV0aGVudGlj YXRpb24gT3B0aW9uIG5lYXIgdGhlIGJvdHRvbSBvZiBwYWdlIDExLCBidXQgbm9uZSBpcyBkZWZp bmVkIGluIHRoaXMgZG9jdW1lbnQuDQoNCg0KDQpUaGUgb3BlbmluZyBkaXNjdXNzaW9uIGZvciBT ZWN0aW9uICA2LjIgaXMgY29uZnVzaW5nIHdoZW4gaXQgZGlzY3Vzc2VzIGhvdyBhIFNlY3VyZSBE SENQdjYg4oCcZW5hYmxlZOKAnSByZWNlaXZlciBtaWdodCwgb3IgbWlnaHQgbm90LCBkaXNjYXJk IG1lc3NhZ2VzIHRoYXQgb21pdCB0aGUgQ0dBIGFuZCBTaWduYXR1cmUgb3B0aW9ucy4gVGhlIGF1 dGhvcnMgbWF5IG5lZWQgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBhIHJlY2VpdmVyIHRoYXQgaXMg U2VjdXJlIERIQ1B2NiDigJxjYXBhYmxl4oCdIHZzLiDigJxlbmFibGVk4oCdIHRvIGNsYXJpZnkg d2hhdCB0aGV5IG1lYW4uIE1heWJlIHRoZSBwdXJwb3J0ZWQgc291cmNlIGFkZHJlc3Mgb2YgdGhl IHNlbmRlciBwbGF5cyBhIHJvbGwgaGVyZSBhcyB3ZWxsLiBEaXNjYXJkaW5nIGEgcGFja2V0IGZv ciB3aGljaCB0aGUgcmVxdWlyZWQgb3B0aW9ucyBhcmUgYWJzZW50IGlzIGEgU0hPVUxELCBoZXJl LiBCdXQsIG5lYXIgdGhlIGJvdHRvbSBvZiBwYWdlIDEyLCB0aGVyZSBpcyB0ZXh0IHRoYXQgc2F5 cyBhIHBhY2tldCB0aGF0IGRvZXMgbm90IHBhc3MgYWxsIG9mIHRoZSBjaGVja3MgTVVTVCBiZSBk aXNjYXJkZWQuIFRoZXNlIHR3byBzdGF0ZW1lbnQgbmVlZCB0byBiZSByZWNvbmNpbGVkLiBUaGVy ZSBpcyBubyBkaXNjdXNzaW9uIG9mIGhvdyBhIHJlY2VpdmVyIHZlcmlmaWVzIHRoYXQgYSBtZXNz YWdlIGlzIGZyb20gYW4gYXV0aG9yaXplZCBzZXJ2ZXIgb3IgcmVsYXkgYWdlbnQsIGUuZy4sIGJ5 IHJlZmVyZW5jZSB0byBwcmUtY29uZmlndXJlZCBDR0EgZGF0YS4gIFRoZXJlIGlzIG5vIGRpc2N1 c3Npb24gb2Ygd2hlbiBhIHJlY2VpdmVyIHNob3VsZCBjYWNoZSBDR0EgZGF0YSBmb3IgZnV0dXJl IHVzZSwgZGVzcGl0ZSBhbiBhbGx1c2lvbiB0byB0aGlzIHBvc3NpYmlsaXR5IGluIFNlY3Rpb24g NC4gVGhlc2UgdG9waWNzIG11c3QgYmUgYWRkcmVzc2VkIGlmIHRoZSBwcm9jZXNzaW5nIHJ1bGVz IGFyZSB0byBiZSBjb25zaWRlcmVkIGNvbXBsZXRlLiBUaGUg4oCcbWluYml0c+KAnSBkZXNjcmlw dGlvbiBpcyAgYml0IGNvbmZ1c2luZywgYXMgaXRzIG5hbWUgc3BlY2lmaWVzIGEgbWluaW11bSBr ZXkgc2l6ZSwgYnV0IHRoZSBkZXNjcmlwdGlvbiBkaXNjdXNzZXMgYm90aCBtaW4gYW5kIG1heCBr ZXkgc2l6ZXMuIEFsc28sIHRoaXMgdmFyaWFibGUgbmVlZHMgdG8gYmUgYXVnbWVudGVkIHdpdGgg YW4gYWxnb3JpdGhtIElELCBzbyB0aGF0IGl0IGlzIGNsZWFyIHRvIHdoaWNoIGFsZ29yaXRobSB0 aGUga2V5IHNpemUgYXBwbGllcy4NCg0KDQoNClNlY3Rpb24gNi4zIGRlc2NyaWJlcyBzcGVjaWFs IHByb2Nlc3NpbmcgcGVyZm9ybWVkIGJ5IHJlbGF5IGFnZW50cywgYWJvdmUgd2hhdCBpcyBkZXNj cmliZWQgZm9yIHRoZW0gYXMgc2VuZGVycyBhbmQgcmVjZWl2ZXJzLCBpbiB0aGUgcHJlY2VkaW5n IHR3byBzZWN0aW9ucy4gQmVjYXVzZSByZWxheSBhZ2VudCBwcm9jZXNzaW5nIGhhcyBhbHJlYWR5 IGJlZW4gZGlzY3Vzc2VkIGluIDYuMSBhbmQgNi4yLCB0aGUgYWRkaXRpb25hbCB0ZXh0IGhlcmUg c2VlbXMgY29uZnVzaW5nIHRvIG1lLiBUaGUgY2xvc2luZyBwYXJhZ3JhcGggaXMgZXNwZWNpYWxs eSBjb25mdXNpbmcgdG8gbWUsIGJ1dCBtYXliZSBESENQdjYgZXhwZXJ0cyB3aWxsIGZpbmQgaXQg dW5kZXJzdGFuZGFibGUuDQoNCg0KDQpUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlv biBzdGF0ZXMgdGhhdCDigJzigKYgY2xpZW50cyBzaG91bGQgYmUgcHJlLWNvbmZpZ3VyZWQgd2l0 aCB0aGUgREhDUHY2IHNlcnZlciBDR0Eu4oCdIFRoaXMgc2VlbXMgaW1wb3J0YW50IGVub3VnaCB0 byBiZSDigJxTSE9VTETigJ0gdnMuIOKAnHNob3VsZC7igJ0gU2ltaWxhciBsYW5ndWFnZSBpcyB1 c2VkIHRvIGRlc2NyaWJlIHRoZSBuZWVkIHRvIHByZS1jb25maWd1cmUgQ0dBcyBmb3IgcmVsYXlz IGFuZCBzZXJ2ZXJzLCBhbmQgaXQgdG9vIG5lZWRzIHRvIGJlIHN0YXRlZCBtb3JlIGZpcm1seS4g SW4gYm90aCBjYXNlcyB0aGUgdGV4dCBzdGF0ZXMgdGhhdCBob3cgc2VjdXJlIHByZS1jb25maWd1 cmF0aW9uIG9mIENHQXMgaXMgYWNoaWV2ZWQgaXMgb3V0IG9mIHNjb3BlLiBMYXRlciBpbiB0aGlz IHNlY3Rpb24gdGhlIGF1dGhvcnMgc3VnZ2VzdCB0aGF0IGEgbGVhZiBvZiBmYWl0aCAoTG9GKSBh cHByb2FjaCB0byBhY3F1aXNpdGlvbiBvZiB0aGVzZSBDR0FzIGJ5IGNsaWVudHMgbWF5IGJlIGEg cmVhc29uYWJsZSBhbHRlcm5hdGl2ZSB0byBzZWN1cmUgZGlzdHJpYnV0aW9uIG9mIHNlcnZlciBD R0EgdmFsdWVzLiBUaGlzIHN1Z2dlc3Rpb24gaWdub3JlcyB0aGUgaXNzdWUgb2YgaG93IGEga2V5 IGNoYW5nZSBmb3IgYSBzZXJ2ZXIgd2lsbCBiZSBhY2NvbW1vZGF0ZWQsIG9yIGhvdyB0aGUgYWRk aXRpb24gb2YgYSBuZXcgc2VydmVyIHdvdWxkIHdvcmsuIEFic2VudCBhIGRpc2N1c3Npb24gb2Yg dGhlc2UgaXNzdWVzLCB0aGUgTG9GIHN1Z2dlc3Rpb24gc2VlbXMgcXVlc3Rpb25hYmxlLg0KDQoN Cg0KVGhpcyBzZWN0aW9uIGNvbnRhaW5zIGEgYnJpZWYgZGlzY3Vzc2lvbiBvZiBjb2xsaXNpb24g YXR0YWNrcyBhZ2FpbnN0IGhhc2ggZnVuY3Rpb25zLCBhbmQgd2h5IHRoZSBjdXJyZW50IGxldmVs cyBvZiBhdHRhY2tzIGFyZSBub3QgYSBzZXJpb3VzIGNvbmNlcm4gaW4gdGhpcyBjb250ZXh0LiBI YXNoIGZ1bmN0aW9ucywgcGVyIHNlLCBkbyBub3QgaGF2ZSBhIOKAnG5vbi1yZXB1ZGlhdGlvbiBm ZWF0dXJl4oCdIHNvIEkgdGhpbmsgdGhlIHRleHQgaGVyZSBzaG91bGQgYmUgaW1wcm92ZWQuIERp c2N1c3Npb24gb2YgdGhlIGhhc2ggZnVuY3Rpb24gc2VjdXJpdHkgaW4gdGhlIFNlTkQgY29udGV4 dCBzZWVtcyByZWxldmFudC4gQXMgbm90ZWQgZWFybGllciwgdGhlIHRlc3QgaW4gNC4yIHRoYXQg dGFsa3MgYWJvdXQgd2h5IGhhc2ggZnVuY3Rpb25zIGFyZSBhZGVxdWF0ZWx5IHNlY3VyZSBmb3Ig dGhpcyBjb250ZXh0IHNob3VsZCBtb3ZlIGhlcmUsIGFuZCB0aGUgcmVkdW5kYW5jaWVzIHNob3Vs ZCBiZSByZW1vdmVkLg0KDQoNCg0KDQoNCg0KDQoNCg== --_000_5D36713D8A4E7348A7E10DF7437A4B923A00D720szxeml545mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDb3VyaWVyOw0KCXBhbm9zZS0xOjIgNyA0IDkgMiAyIDUgMiA0IDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEg MTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEg MSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm IjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pysIENoYXIiOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJ Zm9udC1mYW1pbHk6Q291cmllcjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkNoYXINCgl7bXNvLXN0 eWxlLW5hbWU6Iue6r+aWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms657qv5paH5pysOw0KCWZvbnQtZmFtaWx5OuWui+S9kzsNCgljb2xvcjpibGFj azt9DQpwLlBsYWluVGV4dCwgbGkuUGxhaW5UZXh0LCBkaXYuUGxhaW5UZXh0DQoJe21zby1zdHls ZS1uYW1lOiJQbGFpbiBUZXh0IjsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7 fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7 DQoJZm9udC1mYW1pbHk6Q291cmllcjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSwg U3RlcGhlbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIHNvIG11 Y2ggZm9yIHlvdXIgZGV0YWlsZWQgcmV2aWV3LiBZb3VyIGNvbW1lbnRzIGFyZSBpbXBvcnRhbnQg Zm9yIHVzIHRvIGltcHJvdmUgdGhlIGRyYWZ0LiBXZSB3aWxsIHdvcmsgb24gdGhhdCBpbiB0aGUg bmV4dCB1cGRhdGUuIE1heWJlDQogc29tZSBwcml2YXRlIGNvbW11bmljYXRpb24gd2lsbCBiZSBm b3IgeW91ciBmdXJ0aGVyIGFkdmljZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPk1hbnkgdGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlNoZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0 ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBTdGVwaGVuIEtlbnQgW21haWx0bzprZW50QGJibi5jb21d DQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBGZWJydWFyeSAyNSwgMjAxMyA4OjQyIFBNPGJy Pg0KPGI+VG86PC9iPiBzZWNkaXI7IFNoZW5nIEppYW5nOyBTZWFuIFNoZW4gPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjp3aW5kb3d0 ZXh0Ij7msojng4E8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOndpbmRvd3RleHQiPjsgam9obl9icnpvem93c2tpQGNhYmxlLmNvbWNhc3QuY29tOyB0 ZWQubGVtb25Abm9taW51bS5jb207DQogdm9sekBjaXNjby5jb207IHJkcm9tcy5pZXRmQGdtYWls LmNvbTsgYnJpYW5AaW5ub3ZhdGlvbnNsYWIubmV0PGJyPg0KPGI+U3ViamVjdDo8L2I+IHJldmll dyBvZiBkcmFmdC1pZXRmLWRoYy1zZWN1cmUtZGhjcHY2LTA3PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3Vy aWVyIj5TRUNESVIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZGhjLXNlY3VyZS1kaGNwdjYtMDc8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkNvdXJpZXIiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+SSByZXZpZXdl ZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25n b2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZw0KIHByb2Nlc3Nl ZCBieSB0aGUgSUVTRy4mbmJzcDsgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmls eSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiZuYnNwOyBE b2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRz IGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6Q291cmllciI+VGhpcyBkb2N1bWVudCBwcm9wb3NlcyB1c2Ugb2YgQ0dBcyB0byBzZWN1 cmUgREhDUHY2IHRyYWZmaWMsIHByaW5jaXBhbGx5IHRvIHByb3ZpZGUgZGF0YSBvcmlnaW4gYXV0 aGVudGljYXRpb24gYW5kDQogY29ubmVjdGlvbmxlc3MgaW50ZWdyaXR5IGZvciBtZXNzYWdlcyB0 cmFuc2ZlcnJlZCBiZXR3ZWVuIGEgREhDUHY2IHNlcnZlciAob3IgcmVsYXkgYWdlbnQpIGFuZCBh IGNsaWVudC4gVGhlc2Ugc2VydmljZXMgYXJlIGRlcml2ZWQgZnJvbSB0aGUgdXNlIG9mIGEgQ0dB IGJ5IHRoZSBjb21tdW5pY2F0aW5nIHBlZXJzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpDb3VyaWVyIj5UaGUgZG9jdW1lbnQgZG9lcyBub3QgcHJvdmlkZSBhIHRo b3JvdWdoIHN5c3RlbS1sZXZlbCBkZXNjcmlwdGlvbiBvZiBob3cgdGhlIHNlY3VyaXR5IG1lY2hh bmlzbXMgYXJlIHRvIGJlIHVzZWQsDQogYW5kIGhvdyBjbGllbnRzLCBzZXJ2ZXJzLCBhbmQgcmVs YXkgYWdlbnRzIG1pZ2h0IG5lZWQgdG8gYmUgY29uZmlndXJlZCBhY2NvcmRpbmdseS4gRm9yIGV4 YW1wbGUsIGlmIHRoZSBwcmltYXJ5IGZvY3VzIGlzIHRod2FydGluZyBmYWtlIERIQ1B2NiBzZXJ2 ZXIgYXR0YWNrcywgdGhlbiBhIGNsaWVudCBtaWdodCBub3QgbmVlZCB0byBzaWduYXR1cmUgYSBx dWVyeSBkaXJlY3RlZCB0byBhIHNlcnZlci4gT24gdGhlIG90aGVyIGhhbmQsIGlmIHRoZQ0KIGdv YWwgaXMgdG8gZW5hYmxlIHNlcnZlcnMgdG8gc2VsZWN0aXZlbHkgcHJvdmlkZSBzZXJ2aWNlIHRv IGNsaWVudHMsIGUuZy4sIGJhc2VkIG9uIGNhY2hlZCBDR0EgdmFsdWVzLCB0aGVuIGEgY2xpZW50 IHdvdWxkIG5lZWQgdG8gc2lnbiBhIHF1ZXJ5LiBUaGUgZG9jdW1lbnQgbmVlZHMgdG8gcHJvdmlk ZSBhZGRpdGlvbmFsIGJhY2tncm91bmQgaW4gdGhpcyByZWdhcmQsIHRvIGVuYWJsZSByZWFkZXJz IChhbmQgaW1wbGVtZW50ZXJzKSB0byB1bmRlcnN0YW5kDQogd2hhdCBmZWF0dXJlcyBuZWVkIHRv IGJlIHByZXNlbnQgaW4gc3lzdGVtIGNvbXBvbmVudHMgbWFraW5nIHVzZSBvZiB0aGVzZSBzZWN1 cml0eSBtZWNoYW5pc21zLiBBIGRlc2NyaXB0aW9uIG9mIGxvY2FsIGNvbmZpZ3VyYXRpb24gdmFy aWFibGVzIHRoYXQgY2FuIGJlIHVzZWQgdG8gYWNoaWV2ZSB0aGUgZGVzaXJlZCBzeXN0ZW0tbGV2 ZWwgYmVoYXZpb3IgaXMgbmVlZGVkLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpDb3VyaWVyIj5TZWN0aW9uIDMgcHJvdmlkZXMgYSB2ZXJ5IGJyaWVmIGRpc2N1c3Np b24gb2YgdGhlIHZ1bG5lcmFiaWxpdGllcyBhc3NvY2lhdGVkIHdpdGggdW5zZWN1cmVkIERIQ1B2 NiwgYW5kIHRoZW4gcmV2aWV3cw0KIHRoZSBzZWN1cml0eSBtZWNoYW5pc21zIG9mZmVyZWQgaW4g UkZDIDMzMTUuIEl0IG5vdGVzIHRoYXQgdGhlIHN5bW1ldHJpYyBrZXkgbWFuYWdlbWVudCBhcHBy b2FjaCBvZmZlcmVkIGluIDMzMTUgaXMgZGlmZmljdWx0IHRvIG1hbmFnZSwgYSBjb25jbHVzaW9u IHdpdGggd2hpY2ggSSBjb25jdXIuIEhvd2V2ZXIsIHRoZSBhdXRob3JzIG92ZXJzdGF0ZSB0aGUg c2ltcGxpY2l0eSBvZiB0aGVpciBwcm9wb3NlZCBhcHByb2FjaCwgZGVmZXJyaW5nIHRvDQogdGhl IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gYSBkaXNjdXNzaW9uIG9mIHB1YmxpYyBr ZXkgbWFuYWdlbWVudC4gPC9zcGFuPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6Q291cmllciI+VGhpcyBzZWN0aW9uIGFsc28gbm90ZXMgdGhhdCAzMzE1IHN1Z2dlc3RzIHVz ZSBvZiBJUHNlYyB0byBzZWN1cmUgY29tbXVuaWNhdGlvbnMgYmV0d2VlbiBzZXJ2ZXJzIGFuZCBy ZWxheSBhZ2VudHMNCiAob3IgYmV0d2VlbiByZWxheSBhZ2VudHMpLCBidXQgZGlzbWlzc2VzIHRo YXQgYXBwcm9hY2ggZHVlIHRvIGNvbXBsZXhpdHkuIEkgYW0gbGVzcyBzeW1wYXRoZXRpYyB0byB0 aGlzIHN0YXRlbWVudC4gSVBzZWMgaXMgYWxyZWFkeSBpbXBsZW1lbnRlZCBpbiBhbGwgbWFqb3Ig b3BlcmF0aW5nIHN5c3RlbXMsIHNvIGFuIGFyZ3VtZW50IGFib3V0IGl0cyBjb21wbGV4aXR5LCBy ZWxldmFudCB0byBhIHNldCBvZiBwcm9wb3NlZCBuZXcgbWVjaGFuaXNtcywNCiBpcyBub3QgZXNw ZWNpYWxseSByZWxldmFudC4gUGVyaGFwcyB0aGUgYXV0aG9ycyBpbnRlbmQgdG8gYXJndWUgdGhh dCBtYW5hZ2VtZW50IG9mIElQc2VjIGZvciB0aGlzIGFwcGxpY2F0aW9uIGlzIG1vcmUgY29tcGxl eCB0aGFuIHRoZWlyIHByb3Bvc2VkIHNvbHV0aW9uLiBJZiBzbywgSSBzdWdnZXN0IHRoYXQgdGhl IHRleHQgaW4gYnVsbGV0IOKAnGPigJ0gb2YgU2VjdGlvbiAzIGJlIHJldmlzZWQuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpDb3VyaWVyIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+U2VjdGlvbiA0IGRlc2NyaWJlcyB0aGUgcHJvcG9zZWQg bWVjaGFuaXNtLiBUaGUgc2VjdGlvbiBzdGF0ZXMgdGhlIGFzc3VtcHRpb25zIHRoYXQgdW5kZXJs aWUgdXNlIG9mIENHQXMgaW4gdGhpcyBjb250ZXh0LCBidXQgaXQgZG9lcyBzbyBpbiBhIGNvbmZ1 c2luZyBtYW5uZXIuIFRoZSB1c2Ugb2YgQ0dBcyBwcm92aWRlcyBpbnRyaW5zaWMNCiBhdXRoZW50 aWNhdGlvbiBvZiB0aGUgc2VuZGVyIG9mIGEgc2lnbmVkIG1lc3NhZ2UsIGluIHRlcm1zIG9mIHRo ZSBJUHY2IGFkZHJlc3Mgb2YgdGhlIHNlbmRlci4gRm9yIERIQ1B2NiBjbGllbnRzLCB0aGlzIG1h eSBiZSBhbGwgdGhhdCBpcyByZXF1aXJlZCwgYnV0IHRoZSB0ZXh0IGRvZXMgbm90IG1ha2UgdGhh dCBhcmd1bWVudC4gRm9yIERIQ1B2NiBzZXJ2ZXJzLCBjbGllbnRzIChhbmQgcmVsYXkgYWdlbnRz KSBzaW1wbGUgYWRkcmVzcyBhdXRoZW50aWNhdGlvbg0KIGRvZXMgbm90IHN1ZmZpY2U7IGEgY2xp ZW50IChvciBhIHJlbGF5IGFnZW50KSBuZWVkcyB0byBrbm93IHRoYXQgdGhlIHNlbmRlciBvZiBh IG1lc3NhZ2UgaXMgYXV0aG9yaXplZCB0byBhY3QgYXMgYSBzZXJ2ZXIgKG9yIHJlbGF5IGFnZW50 KS4gVGhlIHRleHQgaXMgbm90IGF0IGFsbCBjbGVhciBvbiB0aGlzIHBvaW50LCBpLmUuLCBpdCBm YWlscyB0byBzdGF0ZSBmb3Igd2hpY2ggZW50aXRpZXMgaXQgaXMgbmVjZXNzYXJ5IHRvIHByZS1j b25maWd1cmUNCiBDR0EgcGFyYW1ldGVycywgdG8gZW5hYmxlIG1lYW5pbmdmdWwgYXV0aGVudGlj YXRpb24gKGFuZCBhdXRob3JpemF0aW9uKS4gPC9zcGFuPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRoZSB0ZXh0IGhlcmUg c3RhdGVzIGFuIGV4Y2VwdGlvbiB0byB0aGUgbmVlZCBmb3IgcHJlLWNvbmZpZ3VyYXRpb24gc2F5 aW5nJm5ic3A7IHRoYXQgYW4gZW50aXR5IGNvdWxkIGhhdmUg4oCcIOKApiByZWNvcmRlZCBbdGhl IHBhcmFtZXRlcnNdIGZyb20gcHJldmlvdXMgY29tbXVuaWNhdGlvbnMu4oCdIFRoaXMgbGVhcCBv ZiBmYWl0aCAoTG9GKSBrZXkNCiBtYW5hZ2VtZW50IGFwcHJvYWNoIGlzIGRpc2N1c3NlZCBhZ2Fp biBvbmx5IGluIFNlY3Rpb24gNy4gVGhlIGRpc2N1c3Npb24gdGhlcmUgaXMgc3VwZXJmaWNpYWwu IE1vcmUgdGV4dCBpcyBuZWVkZWQgdG8gZXhwbGFpbiB3aGVuIExvRiBtYXkgYmUgdmlld2VkIGFz IGFwcHJvcHJpYXRlLCBhbmQgdG8gYWRkcmVzcyBpc3N1ZXMgc3VjaCBhcyBob3cgYSBjbGllbnQg dGhhdCBhY3F1aXJlZCBhIHNlcnZlcuKAmXMgQ0dBIHdvdWxkIHRyYW5zaXRpb24gdG8NCiBhIG5l dyBzZXJ2ZXIgQ0dBLCBzZWN1cmVseS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5TZWN0aW9uIDQg ZW5kcyBieSBub3RpbmcgdGhhdCB0aGUg4oCcYXV0aGVudGljYXRpb24gb3B0aW9uc+KAnSAocHJl c3VtYWJseSB0aGUgc2lnbmF0dXJlIG9wdGlvbikgY2FuIGJlIHVzZWQgdG8gY291bnRlciByZXBs YXkgYXR0YWNrcy4gVGhpcyBpcyBub3QgcXVpdGUgYWNjdXJhdGUsIGkuZS4sIGl0IGlzIHRoZSBp bnRlZ3JpdHkgYXNwZWN0DQogb2YgdGhlIHNpZ25hdHVyZSB0aGF0IHByb3ZpZGVzIGEgYmFzaXMg Zm9yIGFudGktcmVwbGF5IG1lY2hhbmlzbXMsIHZzLiB0aGUgYXV0aGVudGljYXRpb24mbmJzcDsg YXNwZWN0LiBNb3JlIHdvcnJpc29tZSBpcyB0aGF0IGZhY3QgdGhhdCB0aGVyZSBpcyBubyBsYXRl ciBtZW50aW9uIG9mIGFudGktcmVwbHkgaW4gdGhlIGRvY3VtZW50LiBUaGUgYXV0aG9ycyBuZWVk IHRvIGFkZCB0ZXh0IGRpc2N1c3NpbmcgYW50aS1yZXBsYXkgaW4gdGhpcyBjb250ZXh0Ljwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+U2VjdGlvbiA0LjIgZGlzY3Vzc2VzIGFsZ29yaXRobSBhZ2lsaXR5LCBidXQgZG9l cyBzbyBvbmx5IGZvciBoYXNoIGFsZ29yaXRobXMuIFRoaXMgc2VjdGlvbiBuZWVkcyB0byBiZSBl eHBhbmRlZCB0byBkaXNjdXNzIHNpZ25hdHVyZSBhbGdvcml0aG0gYWdpbGl0eSBhcyB3ZWxsLiBB bHNvLCB0aGUgdGV4dCBoZXJlIHN0YXRlcyB0aGF0DQog4oCcbWFpbmx5IHVuaWxhdGVyYWwgbm90 aWZpY2F0aW9u4oCdIGlzIHRoZSBtZWFucyBieSB3aGljaCBhbiBhbGdvcml0aG0gY2hhbmdlIGlz IG1hZGUga25vd24gdG8gYSBwZWVyIGNvbW11bmljYW50LCBidXQgdGhhdCBub3QgYWxsIHNlbmRl cnMgaW4gYSBuZXR3b3JrIG5lZWQgdG8gdHJhbnNpdGlvbiB0byBhIG5ldyBhbGdvcml0aG0gYXQg dGhlIHNhbWUgdGltZS4gVGhpcyBzZWN0aW9uIG5lZWRzIHRvIGRlc2NyaWJlIGhvdyBhbiBvcmRl cmx5IHRyYW5zaXRpb24NCiB0byBhIG5ldyBhbGdvcml0aG0gY2FuIGJlIGVmZmVjdGVkIGluIGEg bmV0d29yay4gRm9yIGV4YW1wbGUsIG9uZSBtaWdodCBhZGQgYW4gb3B0aW9uIHRoYXQgYSBzZW5k ZXIgY291bGQgaW5jbHVkZSBpbiBhIG1lc3NhZ2UsIGluZGljYXRpbmcgYSBwcmVmZXJyZWQgbGlz dCBvZiBhbGdvcml0aG1zIChzaWduYXR1cmUgYW5kIGhhcykgdGhhdCBpdCBzdXBwb3J0cy4gVGhp cyB3b3VsZCBlbmFibGUgYSBzZXJ2ZXIgdG8ga25vdyB3aGV0aGVyIGNsaWVudHMNCiBhcmUgcHJl cGFyZWQgdG8gdHJhbnNpdGlvbiB0byBhIG5ldyBhbGdvcml0aG0uPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5NdWNo IG9mIHRoZSB0ZXh0IGluIDQuMiBzaG91bGQgYmUgbW92ZWQgdG8gdGhlIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zIHNlY3Rpb24sIGFzIGl0IGlzIG1vdGl2YXRpb25hbCBtYXRlcmlhbCBub3QgZGVz Y3JpYmluZyB0aGUgd29ya2luZyBvZiB0aGUgcHJvdG9jb2wuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5TZWN0aW9u IDUgZGVzY3JpYmVzIHRoZSBlbmhhbmNlbWVudHMgdG8gREhDUHY2IHRvIHN1cHBvcnQgdGhlIHBy b3Bvc2VkIHNlY3VyaXR5IGZlYXR1cmVzLiBTZWN0aW9uIDUuMSBkZWZpbmVzIGFuIG9wdGlvbiB0 byB0cmFuc2ZlciBhIENHQSBwYXJhbWV0ZXJzIChhcyBwcmUgUkZDIDM5NzIpLiBUaGlzIGlzIGEg c2ltcGxlIG9wdGlvbg0KIGFuZCBJIGRpZG7igJl0IHNlZSBhbnkgcHJvYmxlbXMgd2l0aCB0aGUg ZGVzY3JpcHRpb24gcHJvdmlkZWQuIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+U2VjdGlvbiA1LjIgZGVmaW5lcyBh IHNpZ25hdHVyZSBvcHRpb24uIFRoZXJlIGlzIGEgdGltZXN0YW1wIGhlcmUsIHdoaWNoIGlzIHBy ZXNlbnQgdG8gaGVscCDigJxyZWR1Y2UgdGhlIGRhbmdlciBvZiByZXBsYXkgYXR0YWNrcy7igJ0g SG93ZXZlciwgdGhlIHByb2Nlc3NpbmcgcnVsZXMgZm9yIGEgcmVjZWl2ZXIgKFNlY3Rpb24gNi4y KQ0KIG1ha2Ugbm8gbWVudGlvbiBvZiB0aGlzIHRpbWVzdGFtcC4gVGhpcyBtaXNtYXRjaCBuZWVk cyB0byBiZSBmaXhlZC4gVGhlIGRlc2NyaXB0aW9uIG9mIHdoYXQgZGF0YSBpcyBwcm90ZWN0ZWQg YnkgdGhlIHNpZ25hdHVyZSBpcyBhIGJpdCBjb21wbGV4IHRvIGZvbGxvdy4gQSBkaWFncmFtIGlz IG5lZWRlZC4gQSBwYWRkaW5nIGZpZWxkIGlzIGRlZmluZWQsIGJ1dCB0aGVyZSBpcyBubyBtZW50 aW9uIG9mIHdoYXQgcGFkZGluZyBiaXRzIGFyZSB0bw0KIGJlIHVzZWQuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5T ZWN0aW9uIDUuMyBkZWZpbmVzIGEgc2lnbmF0dXJlIG9wdGlvbiBmb3IgcmVsYXllZCByZXBsaWVz LiBJdCBpcyB1c2VkIHRvIGVuYWJsZSBlbmNhcHN1bGF0aW9uIG9mIGEgcmVwbHkgdGhhdCBwYXNz ZXMgdGhyb3VnaCBvbmUgb3IgbW9yZSByZWxheSBhZ2VudHMsIHNvIHRoYXQgdGhlcmUgYXJlIHNl cGFyYXRlIHNpZ25hdHVyZXMNCiBmb3IgZWFjaCBhZ2VudCBhbmQgZm9yIHRoZSB0YXJnZXQgY2xp ZW50LiBUaGUgZGVzY3JpcHRpb24gaGVyZSBpcyBub3QgY2xlYXIgdG8gbWUsIGVzcGVjaWFsbHkg aWYgdGhlcmUgaXMgbW9yZSB0aGFuIG9uZSByZWxheSBhZ2VudA0KPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5TZWN0 aW9uIDUuNCBkZXNjcmliZXMgYW4gb3B0aW9uIHRoYXQgY2FycmllcyB0aGUgSVB2NiBhZGRyZXNz IG9mIGEgc2VydmVyLCBwcmVzZXJ2aW5nIGl0IGZvciBhdXRoZW50aWNhdGlvbiB3aGVuIGEgcmVw bHkgaXMgcmVsYXllZCB0aHJvdWdoIGFuIGFnZW50LiBUaGlzIGlzIGEgc2ltcGxlIG9wdGlvbiwg YW5kIGl0cyBkZXNjcmlwdGlvbg0KIHNlZW1zIGZhaXJseSBjbGVhci48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlNl Y3Rpb25zIDYuMSBhbmQgNi4yIHByb3ZpZGVzIHByb2Nlc3NpbmcgcnVsZXMgZm9yIHNlbmRlcnMg YW5kIHJlY2VpdmVycywgcmVzcGVjdGl2ZWx5LiBUaGlzIGlzIGEgdmVyeSBnb29kIHN0cnVjdHVy ZSwgYnV0LCBhcyBub3RlZCBhYm92ZSwgc29tZSBkZXRhaWxzIGFyZSBtaXNzaW5nLCBlLmcuLCB0 aGVyZSBpcyBubyBtZW50aW9uDQogb2YgdGltZXN0YW1wIHVzZS4gKElmIHRpbWVzdGFtcCBwcm9j ZXNzaW5nIHJ1bGVzIGFyZSBkZWZpbmVkIGVsc2V3aGVyZSwgZS5nLiwgMzUxNSwgdGhlbiB0aGlz IHRleHQgc2hvdWxkIGluY2x1ZGUgdGhlIHJlbGV2YW50IGNpdGUuIFRoZSBkZXNjcmlwdGlvbiBv ZiB3aGVuIHRoZSBDR0EsIFNpZ25hdHVyZSBhbmQgRFVJRCBvcHRpb25zIE1VU1QgYW5kIE1VU1Qg Tk9UIGJlIHVzZWQgaXMgc3VmZmljaWVudGx5IGNvbXBsZXggdGhhdCBhIHRhYmxlDQogbmVlZHMg YmUgaW5jbHVkZWQuIFRoZXJlIGlzIGEgcmVmZXJlbmNlIHRvIGFuIEF1dGhlbnRpY2F0aW9uIE9w dGlvbiBuZWFyIHRoZSBib3R0b20gb2YgcGFnZSAxMSwgYnV0IG5vbmUgaXMgZGVmaW5lZCBpbiB0 aGlzIGRvY3VtZW50Lg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5UaGUgb3BlbmluZyBkaXNjdXNzaW9uIGZvciBT ZWN0aW9uJm5ic3A7IDYuMiBpcyBjb25mdXNpbmcgd2hlbiBpdCBkaXNjdXNzZXMgaG93IGEgU2Vj dXJlIERIQ1B2NiDigJxlbmFibGVk4oCdIHJlY2VpdmVyIG1pZ2h0LCBvciBtaWdodCBub3QsIGRp c2NhcmQgbWVzc2FnZXMgdGhhdCBvbWl0IHRoZSBDR0EgYW5kIFNpZ25hdHVyZSBvcHRpb25zLg0K IFRoZSBhdXRob3JzIG1heSBuZWVkIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gYSByZWNlaXZlciB0 aGF0IGlzIFNlY3VyZSBESENQdjYg4oCcY2FwYWJsZeKAnSB2cy4g4oCcZW5hYmxlZOKAnSB0byBj bGFyaWZ5IHdoYXQgdGhleSBtZWFuLiBNYXliZSB0aGUgcHVycG9ydGVkIHNvdXJjZSBhZGRyZXNz IG9mIHRoZSBzZW5kZXIgcGxheXMgYSByb2xsIGhlcmUgYXMgd2VsbC4gRGlzY2FyZGluZyBhIHBh Y2tldCBmb3Igd2hpY2ggdGhlIHJlcXVpcmVkIG9wdGlvbnMgYXJlDQogYWJzZW50IGlzIGEgU0hP VUxELCBoZXJlLiBCdXQsIG5lYXIgdGhlIGJvdHRvbSBvZiBwYWdlIDEyLCB0aGVyZSBpcyB0ZXh0 IHRoYXQgc2F5cyBhIHBhY2tldCB0aGF0IGRvZXMgbm90IHBhc3MgYWxsIG9mIHRoZSBjaGVja3Mg TVVTVCBiZSBkaXNjYXJkZWQuIFRoZXNlIHR3byBzdGF0ZW1lbnQgbmVlZCB0byBiZSByZWNvbmNp bGVkLiBUaGVyZSBpcyBubyBkaXNjdXNzaW9uIG9mIGhvdyBhIHJlY2VpdmVyIHZlcmlmaWVzIHRo YXQgYSBtZXNzYWdlDQogaXMgZnJvbSBhbiBhdXRob3JpemVkIHNlcnZlciBvciByZWxheSBhZ2Vu dCwgZS5nLiwgYnkgcmVmZXJlbmNlIHRvIHByZS1jb25maWd1cmVkIENHQSBkYXRhLiZuYnNwOyBU aGVyZSBpcyBubyBkaXNjdXNzaW9uIG9mIHdoZW4gYSByZWNlaXZlciBzaG91bGQgY2FjaGUgQ0dB IGRhdGEgZm9yIGZ1dHVyZSB1c2UsIGRlc3BpdGUgYW4gYWxsdXNpb24gdG8gdGhpcyBwb3NzaWJp bGl0eSBpbiBTZWN0aW9uIDQuIFRoZXNlIHRvcGljcyBtdXN0IGJlIGFkZHJlc3NlZA0KIGlmIHRo ZSBwcm9jZXNzaW5nIHJ1bGVzIGFyZSB0byBiZSBjb25zaWRlcmVkIGNvbXBsZXRlLiBUaGUg4oCc bWluYml0c+KAnSBkZXNjcmlwdGlvbiBpcyZuYnNwOyBiaXQgY29uZnVzaW5nLCBhcyBpdHMgbmFt ZSBzcGVjaWZpZXMgYSBtaW5pbXVtIGtleSBzaXplLCBidXQgdGhlIGRlc2NyaXB0aW9uIGRpc2N1 c3NlcyBib3RoIG1pbiBhbmQgbWF4IGtleSBzaXplcy4gQWxzbywgdGhpcyB2YXJpYWJsZSBuZWVk cyB0byBiZSBhdWdtZW50ZWQgd2l0aCBhbiBhbGdvcml0aG0NCiBJRCwgc28gdGhhdCBpdCBpcyBj bGVhciB0byB3aGljaCBhbGdvcml0aG0gdGhlIGtleSBzaXplIGFwcGxpZXMuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij5TZWN0aW9uIDYuMyBkZXNjcmliZXMgc3BlY2lhbCBwcm9jZXNzaW5nIHBlcmZvcm1lZCBieSBy ZWxheSBhZ2VudHMsIGFib3ZlIHdoYXQgaXMgZGVzY3JpYmVkIGZvciB0aGVtIGFzIHNlbmRlcnMg YW5kIHJlY2VpdmVycywgaW4gdGhlIHByZWNlZGluZyB0d28gc2VjdGlvbnMuIEJlY2F1c2UgcmVs YXkgYWdlbnQgcHJvY2Vzc2luZw0KIGhhcyBhbHJlYWR5IGJlZW4gZGlzY3Vzc2VkIGluIDYuMSBh bmQgNi4yLCB0aGUgYWRkaXRpb25hbCB0ZXh0IGhlcmUgc2VlbXMgY29uZnVzaW5nIHRvIG1lLiBU aGUgY2xvc2luZyBwYXJhZ3JhcGggaXMgZXNwZWNpYWxseSBjb25mdXNpbmcgdG8gbWUsIGJ1dCBt YXliZSBESENQdjYgZXhwZXJ0cyB3aWxsIGZpbmQgaXQgdW5kZXJzdGFuZGFibGUuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij5UaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBzdGF0ZXMgdGhhdCDigJzi gKYgY2xpZW50cyBzaG91bGQgYmUgcHJlLWNvbmZpZ3VyZWQgd2l0aCB0aGUgREhDUHY2IHNlcnZl ciBDR0Eu4oCdIFRoaXMgc2VlbXMgaW1wb3J0YW50IGVub3VnaCB0byBiZSDigJxTSE9VTETigJ0g dnMuIOKAnHNob3VsZC7igJ0gU2ltaWxhciBsYW5ndWFnZSBpcw0KIHVzZWQgdG8gZGVzY3JpYmUg dGhlIG5lZWQgdG8gcHJlLWNvbmZpZ3VyZSBDR0FzIGZvciByZWxheXMgYW5kIHNlcnZlcnMsIGFu ZCBpdCB0b28gbmVlZHMgdG8gYmUgc3RhdGVkIG1vcmUgZmlybWx5LiBJbiBib3RoIGNhc2VzIHRo ZSB0ZXh0IHN0YXRlcyB0aGF0IGhvdyBzZWN1cmUgcHJlLWNvbmZpZ3VyYXRpb24gb2YgQ0dBcyBp cyBhY2hpZXZlZCBpcyBvdXQgb2Ygc2NvcGUuIExhdGVyIGluIHRoaXMgc2VjdGlvbiB0aGUgYXV0 aG9ycyBzdWdnZXN0DQogdGhhdCBhIGxlYWYgb2YgZmFpdGggKExvRikgYXBwcm9hY2ggdG8gYWNx dWlzaXRpb24gb2YgdGhlc2UgQ0dBcyBieSBjbGllbnRzIG1heSBiZSBhIHJlYXNvbmFibGUgYWx0 ZXJuYXRpdmUgdG8gc2VjdXJlIGRpc3RyaWJ1dGlvbiBvZiBzZXJ2ZXIgQ0dBIHZhbHVlcy4gVGhp cyBzdWdnZXN0aW9uIGlnbm9yZXMgdGhlIGlzc3VlIG9mIGhvdyBhIGtleSBjaGFuZ2UgZm9yIGEg c2VydmVyIHdpbGwgYmUgYWNjb21tb2RhdGVkLCBvciBob3cgdGhlIGFkZGl0aW9uDQogb2YgYSBu ZXcgc2VydmVyIHdvdWxkIHdvcmsuIEFic2VudCBhIGRpc2N1c3Npb24gb2YgdGhlc2UgaXNzdWVz LCB0aGUgTG9GIHN1Z2dlc3Rpb24gc2VlbXMgcXVlc3Rpb25hYmxlLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VGhp cyBzZWN0aW9uIGNvbnRhaW5zIGEgYnJpZWYgZGlzY3Vzc2lvbiBvZiBjb2xsaXNpb24gYXR0YWNr cyBhZ2FpbnN0IGhhc2ggZnVuY3Rpb25zLCBhbmQgd2h5IHRoZSBjdXJyZW50IGxldmVscyBvZiBh dHRhY2tzIGFyZSBub3QgYSBzZXJpb3VzIGNvbmNlcm4gaW4gdGhpcyBjb250ZXh0LiBIYXNoIGZ1 bmN0aW9ucywgcGVyIHNlLA0KIGRvIG5vdCBoYXZlIGEg4oCcbm9uLXJlcHVkaWF0aW9uIGZlYXR1 cmXigJ0gc28gSSB0aGluayB0aGUgdGV4dCBoZXJlIHNob3VsZCBiZSBpbXByb3ZlZC4gRGlzY3Vz c2lvbiBvZiB0aGUgaGFzaCBmdW5jdGlvbiBzZWN1cml0eSBpbiB0aGUgU2VORCBjb250ZXh0IHNl ZW1zIHJlbGV2YW50LiBBcyBub3RlZCBlYXJsaWVyLCB0aGUgdGVzdCBpbiA0LjIgdGhhdCB0YWxr cyBhYm91dCB3aHkgaGFzaCBmdW5jdGlvbnMgYXJlIGFkZXF1YXRlbHkgc2VjdXJlIGZvcg0KIHRo aXMgY29udGV4dCBzaG91bGQgbW92ZSBoZXJlLCBhbmQgdGhlIHJlZHVuZGFuY2llcyBzaG91bGQg YmUgcmVtb3ZlZC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5D36713D8A4E7348A7E10DF7437A4B923A00D720szxeml545mbxchi_-- From charliek@microsoft.com Wed Feb 27 11:12:48 2013 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 CA7A521F8A67; Wed, 27 Feb 2013 11:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.533 X-Spam-Level: ** X-Spam-Status: No, score=2.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nc-rYTHM1SA0; Wed, 27 Feb 2013 11:12:48 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id AC2AE21F8942; Wed, 27 Feb 2013 11:12:47 -0800 (PST) Received: from BY2FFO11FD016.protection.gbl (10.1.15.204) by BY2FFO11HUB035.protection.gbl (10.1.14.119) with Microsoft SMTP Server (TLS) id 15.0.620.12; Wed, 27 Feb 2013 19:12:38 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD016.mail.protection.outlook.com (10.1.14.148) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Wed, 27 Feb 2013 19:12:38 +0000 Received: from co1outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 27 Feb 2013 19:12:12 +0000 Received: from mail39-co1-R.bigfish.com (10.243.78.229) by CO1EHSOBE025.bigfish.com (10.243.66.88) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Feb 2013 19:11:03 +0000 Received: from mail39-co1 (localhost [127.0.0.1]) by mail39-co1-R.bigfish.com (Postfix) with ESMTP id 91D5810019B; Wed, 27 Feb 2013 19:11:03 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 4 X-BigFish: PS4(zzzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275bhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h17ej9a9j1155h) Received-SPF: softfail (mail39-co1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=charliek@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BL2PR03MB592; H:BL2PR03MB592.namprd03.prod.outlook.com; LANG:en; Received: from mail39-co1 (localhost.localdomain [127.0.0.1]) by mail39-co1 (MessageSwitch) id 1361992261628026_4437; Wed, 27 Feb 2013 19:11:01 +0000 (UTC) Received: from CO1EHSMHS012.bigfish.com (unknown [10.243.78.238]) by mail39-co1.bigfish.com (Postfix) with ESMTP id 945ADE0075; Wed, 27 Feb 2013 19:11:01 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS012.bigfish.com (10.243.66.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Feb 2013 19:10:58 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.275.5; Wed, 27 Feb 2013 19:10:56 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) by BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) with Microsoft SMTP Server (TLS) id 15.0.620.20; Wed, 27 Feb 2013 19:10:54 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com ([169.254.11.203]) by BL2PR03MB592.namprd03.prod.outlook.com ([169.254.11.166]) with mapi id 15.00.0620.020; Wed, 27 Feb 2013 19:10:54 +0000 From: Charlie Kaufman To: "secdir@ietf.org" Thread-Topic: Secdir review of draft-ietf-appsawg-acct-uri-03 Thread-Index: Ac4VHepHeEHRvHE8QZSlPLGrtEMclw== Date: Wed, 27 Feb 2013 19:10:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:e0:1012:7105:ef48:3323:af2b] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PR03MB592.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(56816002)(16676001)(4396001)(56776001)(53806001)(54356001)(54316002)(5343635001)(77982001)(51856001)(76482001)(23726001)(33646001)(46406002)(47736001)(63696002)(47976001)(80022001)(59766001)(6806001)(74662001)(65816001)(47446002)(20776003)(46102001)(49866001)(74502001)(47776003)(79102001)(50986001)(44976002)(31966008)(50466001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB035; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0770F75EA9 Cc: "draft-ietf-appsawg-acct-uri.all@tools.ietf.org" , "iesg@ietf.org" Subject: [secdir] Secdir review of draft-ietf-appsawg-acct-uri-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 19:12:49 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like any= other last call comments. The fact that this document only defines a syntax and does not define uses = for it implies that the security implications are minimal. This document specifies a new URI format for specifying names of accounts. = The syntax looks like: acct:johnsmith@example.com The chosen syntax is apparently already proposed for use in the WebFinger p= rotocol in a separate I-D and one could imagine lots of other uses. This dr= aft does not specify any semantics associated with the account specificatio= n or any means of contacting the entity, though it will likely be a common = practice to have the value be usable as an email address to reach the named= entity. This draft specifies that any protocols using this new URI format = must specify the associated semantics. The Security Considerations notes th= is and says that therefore any security considerations must therefore be de= scribed by the protocol using this syntax. My only quibble is that the spec does not specify any algorithm by which tw= o acct URIs can be compared for equality. Perhaps the world has evolved to = the point where everyone accepts that as being impossible. The part after t= he @ is a DNS host, subject to IDN rules, while the part before may contain= many ASCII characters and %-encoded UTF8. I believe that makes this differ= ent from what is allowed in the name portion of an email address in many su= btle cases. Case-blind comparisons are probably intended but are not specif= ied. Having an "almost canonical" way to specify an account identifier has = the potential of introducing security problems, but they may be unavoidable= . --Charlie From kivinen@iki.fi Thu Feb 28 02:17:34 2013 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 A8FDA21F8ABC for ; Thu, 28 Feb 2013 02:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQcIs+R-oOyd for ; Thu, 28 Feb 2013 02:17:34 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id C493F21F8A96 for ; Thu, 28 Feb 2013 02:17:33 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r1SAHS95004818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Feb 2013 12:17:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r1SAHQEf025291; Thu, 28 Feb 2013 12:17:26 +0200 (EET) 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: <20783.11957.855153.395928@fireball.kivinen.iki.fi> Date: Thu, 28 Feb 2013 12:17:25 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min 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, 28 Feb 2013 10:17:34 -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 2013-02-28 Reviewer LC end Draft Alan DeKok T 2013-02-28 draft-eastlake-additional-xmlsec-uris-09 Jeffrey Hutzelman T 2013-02-27 draft-ietf-geopriv-flow-identity-01 Simon Josefsson T 2013-02-26 draft-ietf-tcpm-proportional-rate-reduction-04 Last calls and special requests: Rob Austein 2013-03-06 draft-arkko-iesg-crossarea-03 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-06 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Scott Kelly 2013-03-08 draft-ietf-intarea-nat-reveal-analysis-05 Stephen Kent 2013-03-11 draft-ietf-manet-olsrv2-metrics-rationale-02 Tero Kivinen 2013-03-07 draft-ietf-tsvwg-byte-pkt-congest-09 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-09 Warren Kumari 2013-03-26 draft-merkle-ikev2-ke-brainpool-03 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Eric Rescorla 2013-01-24 draft-ietf-ospf-ospfv3-iid-registry-update-02 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-04 Nico Williams - draft-ietf-httpbis-p5-range-22 Glen Zorn 2013-02-11 draft-ietf-mpls-tp-use-cases-and-design-06 -- kivinen@iki.fi