From touch@isi.edu Tue Feb 1 11:14:02 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C874F3A6FF8; Tue, 1 Feb 2011 11:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.591 X-Spam-Level: X-Spam-Status: No, score=-104.591 tagged_above=-999 required=5 tests=[AWL=2.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXT-oWVcJ3EX; Tue, 1 Feb 2011 11:14:02 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 07D113A6FE2; Tue, 1 Feb 2011 11:14:01 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p11JGmYY020737 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 1 Feb 2011 11:16:48 -0800 (PST) Message-ID: <4D485C20.6080800@isi.edu> Date: Tue, 01 Feb 2011 11:16:48 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Murphy, Sandra" References: <5ABE30CE099A524CBF95C715D37BCACC03A28634@nemo.columbia.ads.sparta.com> In-Reply-To: <5ABE30CE099A524CBF95C715D37BCACC03A28634@nemo.columbia.ads.sparta.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: draft-ietf-tsvwg-iana-ports.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-tsvwg-iana-ports-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 19:14:02 -0000 Hi, Sandy, On 2/1/2011 11:07 AM, Murphy, Sandra wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. ... > There is a required format for communication of a request to the IANA, I > presume by email. I did not see any mention of the email address to > which the request should be sent (RFC5226 also doesn’t seem to mention it). It's a web form. The doc refers to that in Sec 2: Information about the assignment procedures for the port registry has existed in three locations: the forms for requesting port number assignments on the IANA web site [SYSFORM][USRFORM], an introductory text section in the file listing the port number assignments themselves (known as the port numbers registry) [PORTREG], and two brief sections of the IANA Allocation Guidelines [RFC2780]. I.e., communication is initiated through the forms. > The procedure requires that the same previous Assignee (or Contact) make > any subsequent request about a port/name assignment, where the email > address is provided in the request. Security question: how does the IANA > know that it is communicating with the same Assignee/Contact? There’s no > recommendation for security of that communication. Can you clarify what that would mean? I am not aware of any IETF process that requires presenting credentials beyond an email address. > In the IANA section there is a paragraph: > > IANA is instructed to create a new service name entry in the service > name and port number registry [PORTREG] for any entry in the > "Protocol and Service Names" registry [PROTSERVREG] that does not > already have one assigned. > > Are there no guidelines for creating the new service name? See Sec 8.1. The new assignment procedure allows for service names to be requested without port numbers Joe From Sandra.Murphy@cobham.com Tue Feb 1 11:04:23 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D4953A6F35; Tue, 1 Feb 2011 11:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5wurdpdwzFF; Tue, 1 Feb 2011 11:04:18 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id AA1A13A6DF4; Tue, 1 Feb 2011 11:04:17 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p11J7Z2b014080; Tue, 1 Feb 2011 13:07:35 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p11J7Yfl003306; Tue, 1 Feb 2011 13:07:35 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC243.487C2A50" Date: Tue, 1 Feb 2011 14:07:33 -0500 Message-ID: <5ABE30CE099A524CBF95C715D37BCACC03A28634@nemo.columbia.ads.sparta.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of draft-ietf-tsvwg-iana-ports-09 Thread-Index: AcvCQ0gVV0ZB3J8UQJyiy3Xcw8Z4nQ== From: "Murphy, Sandra" To: , , X-Mailman-Approved-At: Tue, 01 Feb 2011 13:38:55 -0800 Cc: "Murphy, Sandra" Subject: [secdir] review of draft-ietf-tsvwg-iana-ports-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 19:04:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC243.487C2A50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. =20 The draft draft-ietf-tsvwg-iana-ports-09 consolidates the procedures scattered over several RFC for the assignment of service names and ports for transport protocols. It establishes definitions and specifications where they were previously missing (like syntax for service names). It provides a single reference for assignment procedures going forward and establishes procedures for port/name de-assignment, reuse, revocation, etc., and a description of the required and optional fields that must be provided in any request. =20 I did NOT review the referenced documents and did not therefore consider differences between this procedure and previously employed procedures. =20 There is a required format for communication of a request to the IANA, I presume by email. I did not see any mention of the email address to which the request should be sent (RFC5226 also doesn't seem to mention it). =20 The procedure requires that the same previous Assignee (or Contact) make any subsequent request about a port/name assignment, where the email address is provided in the request. Security question: how does the IANA know that it is communicating with the same Assignee/Contact? There's no recommendation for security of that communication. =20 In the IANA section there is a paragraph: =20 =20 IANA is instructed to create a new service name entry in the service name and port number registry [PORTREG] for any entry in the "Protocol and Service Names" registry [PROTSERVREG] that does not already have one assigned. =20 Are there no guidelines for creating the new service name? =20 =20 --Sandy Murphy ------_=_NextPart_001_01CBC243.487C2A50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed = this document as part of the security directorate's ongoing effort to review = all IETF documents being processed by the

IESG.  These = comments were written primarily for the benefit of the security area = directors.  Document editors and WG chairs should treat

these comments just like any other last call comments.

 

The draft draft-ietf-tsvwg-iana-ports-09 = consolidates the procedures scattered over several RFC for the assignment of service = names and ports for transport protocols.  It establishes definitions and specifications where they were previously missing (like syntax for = service names).  It provides a single reference for assignment procedures = going forward and establishes procedures for port/name de-assignment, reuse, revocation, etc., and a description of the required and optional fields = that must be provided in any request.

 

I did NOT review the referenced documents and = did not therefore consider differences between this procedure and previously employed procedures.

 

There is a required format for communication = of a request to the IANA, I presume by email.  I did not see any mention = of the email address to which the request should be sent (RFC5226 also = doesn’t seem to mention it).

 

The procedure requires that the same previous Assignee (or Contact) make any subsequent request about a port/name = assignment, where the email address is provided in the request.  Security = question: how does the IANA know that it is communicating with the same = Assignee/Contact?  There’s no recommendation for security of that = communication.

 

In the IANA section there is a = paragraph:

 

 
   IANA is instructed to create a =
new service name entry in the =
service
   name and port number registry =
[PORTREG] for any entry in the
   "Protocol and Service =
Names" registry [PROTSERVREG] that does =
not
   already have one =
assigned.

 

Are there no guidelines for creating the new = service name? 

 

--Sandy Murphy

------_=_NextPart_001_01CBC243.487C2A50-- From weiler+secdir@watson.org Tue Feb 1 13:44:02 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776153A687A for ; Tue, 1 Feb 2011 13:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6h27xtWJ8wt for ; Tue, 1 Feb 2011 13:44:01 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 81E593A6ABE for ; Tue, 1 Feb 2011 13:44:01 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p11LlJup039329 for ; Tue, 1 Feb 2011 16:47:19 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p11LlIC8039325 for ; Tue, 1 Feb 2011 16:47:18 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 1 Feb 2011 16:47:18 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 01 Feb 2011 16:47:19 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 21:44:02 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Larry Zhu is next in the rotation. For telechat 2011-02-03 Derek Atkins T 2011-01-18 draft-groves-sakke-00 Barry Leiba T 2011-01-31 draft-ietf-ccamp-mpls-tp-cp-framework-05 Russ Mundy T 2011-01-25 draft-ietf-speermint-architecture-17 Sandy Murphy T 2011-01-03 draft-turner-sha0-sha1-seccon-03 For telechat 2011-02-17 Radia Perlman T 2011-02-08 draft-mraihi-mutual-oath-hotp-variants-12 Eric Rescorla T 2011-02-08 draft-mraihi-totp-timebased-07 For telechat 2011-03-03 Julien Laganier T 2011-02-11 draft-holsten-about-uri-scheme-06 Magnus Nystrom T 2011-02-23 draft-meadors-multiple-attachments-ediint-10 Tom Yu T 2011-02-22 draft-josefsson-rc4-test-vectors-02 Last calls and special requests: Reviewer LC end Draft Dave Cridland 2011-01-18 draft-ietf-isis-purge-tlv-05 Alan DeKok 2011-01-18 draft-ietf-isis-reg-purge-00 Love Hornquist-Astrand 2011-02-01 draft-yevstifeyev-tn3270-uri-14 David McGrew - draft-ietf-ecrit-framework-12 David McGrew 2011-02-01 draft-ietf-intarea-shared-addressing-issues-02 Russ Mundy 2011-01-04 draft-cardona-cablelabs-urn-05 Eric Rescorla 2011-01-07 draft-ietf-pce-inter-layer-req-15 Vincent Roca 2011-02-07 draft-reed-urn-dgiwg-02 Joe Salowey 2011-02-08 draft-turner-akf-algs-update-02 Stefan Santesson 2011-02-08 draft-turner-ekpct-algs-update-02 Yaron Sheffer 2011-02-01 draft-ietf-ccamp-rwa-wson-framework-10 Tina TSOU 2011-02-07 draft-ietf-netconf-4741bis-07 Carl Wallace 2011-02-22 draft-herzog-setkey-03 Sam Weiler 2011-02-14 draft-ietf-hokey-ldn-discovery-06 Brian Weis 2011-02-28 draft-herzog-static-ecdh-04 Nico Williams 2011-01-14 draft-yevstifeyev-http-headers-not-recognized-11 Nico Williams 2011-02-09 draft-ietf-rmt-bb-fec-raptorq-04 Kurt Zeilenga 2011-02-10 draft-ietf-shim6-multihome-shim-api-15 Larry Zhu 2010-09-30 draft-lundberg-app-tei-xml-06 From derek@ihtfp.com Tue Feb 1 15:18:05 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C05A3A6C7E; Tue, 1 Feb 2011 15:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIS8uks-60vi; Tue, 1 Feb 2011 15:18:04 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by core3.amsl.com (Postfix) with ESMTP id 501693A688F; Tue, 1 Feb 2011 15:18:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id BED3A260302; Tue, 1 Feb 2011 18:21:21 -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 07454-08; Tue, 1 Feb 2011 18:21:17 -0500 (EST) Received: from pgpdev.ihtfp.org (IHTFP-DHCP-100.IHTFP.ORG [192.168.248.100]) (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 9A82E260232; Tue, 1 Feb 2011 18:21:17 -0500 (EST) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.4/8.14.3/Submit) id p11NLC9u027162; Tue, 1 Feb 2011 18:21:12 -0500 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Tue, 01 Feb 2011 18:21:12 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: Michael.Groves@cesg.gsi.gov.uk Subject: [secdir] sec-dir review of draft-groves-sakke-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 23:18:05 -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. In this document the Sakai-Kasahara Identifier-Based Encryption algorithm (SAKKE) is described. This uses Identifier-Based Encryption to exchange a shared secret from a Sender to a Receiver. This review does not analyze the security of the SAKKE cryptographic algorithm. The security considerations section does the same. I see no security issues with this document. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From CWallace@cygnacom.com Wed Feb 2 07:45:30 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67B283A6CD9; Wed, 2 Feb 2011 07:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4hq66Ut1g0y; Wed, 2 Feb 2011 07:45:22 -0800 (PST) Received: from mail98.messagelabs.com (mail98.messagelabs.com [216.82.242.67]) by core3.amsl.com (Postfix) with SMTP id 4866B3A6C25; Wed, 2 Feb 2011 07:45:22 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-10.tower-98.messagelabs.com!1296661720!18069845!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [65.242.48.8] Received: (qmail 4059 invoked from network); 2 Feb 2011 15:48:41 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.8) by server-10.tower-98.messagelabs.com with SMTP; 2 Feb 2011 15:48:41 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC2F0.A99CDAAE" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 2 Feb 2011 10:48:40 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-herzog-setkey-03 Thread-Index: AcvC1VmAgHpGX6/+RKKYmcKaGRRTKA== From: "Carl Wallace" To: , Cc: rkh@ll.mit.edu, jherzog@ll.mit.edu Subject: [secdir] secdir review of draft-herzog-setkey-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 15:45:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC2F0.A99CDAAE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. =20 The draft-herzog-setkey-03 I-D defines an attribute for use with the symmetric key package structure defined in RFC 6031. =20 I have a number of questions and concerns about this draft. The primary issue is a lack of discussion of who processes the attribute, how the processing is performed and the effects of the processing. Some of my questions would probably be cleared up if the processing rules for the attribute were clear. For example, without understanding the processing of the participant-sets, it is not clear why something simple like a key usage value cannot be used to simply denote that the holder of the key may only use the key in an active or passive way. Below are a list of questions, comments and nits more or less in the order they appear in the document. =20 In the last paragraph of section 1.1, it would be helpful to define "participant-set" before noting that one may be partitioned. =20 =20 On page 3, s/Becuase/Because/ =20 On page 5, s/Futher/Further/ =20 On page 5, s/Heirarchy/Hierarchy/ =20 What grammar is being referenced in the last paragraph of section 1.2? As noted below, including the attribute syntax may be helpful. =20 In section 2, why are the union, intersection and setdiff represented in the attribute value instead of being calculated by the key source with the results of the calculation included in the attribute value? =20 =20 In section 2, must each of union, intersection and setdiff have a terminal SetKeyParticipantSet value that contains community, groupID or explicit? If so, it may be easier to move community and groupID into SetMember and define the union, intersection and setdiff fields to be SEQUENCEs of SetMembers. =20 =20 In section 2, why SHOULD NOT appear in sKeyAttrs instead of MUST NOT? When is it OK to use for a specific key? Would this attribute be appropriate as an unprotected attribute in an RFC 6032 structure? =20 The last sentence of the second paragraph below the ASN.1 in section 2 states that a member SHOULD be considered active if it appears in both lists. What does this mean? If the participant is acting as a passive participant, must it be considered as active because it appears in both lists or is passive a subset of active by definition? =20 =20 In section 2, the bullet that describes the union field refers to empty and non-empty sets. The syntax does not permit an empty SetKeyParticipantSet value. If the expectation is that each SetKeyParticipantSet member in the union be evaluated first, that should be clearly stated. Same comment applies to the intersection and setdiff fields. This sort of evaluation seems like it could get fairly complicated. =20 The bullets describing the community and groupID fields indicate that the values SHOULD represent unchanging sets of participants. Earlier the draft defines sets as immutable. Should these SHOULDs be MUSTs? Are there any security considerations specific to using groups with variable membership? =20 Section 2 implies that a participant is evaluated relative to the contents of a setkey attribute. Where does the participant value come from? Does it identify a specific entity, a group or both? =20 =20 Is the freeform field intended to carry text? If so why not use UTF8String instead of OCTET STRING? There's probably a language tag issue to be had in here somewhere too:-) =20 In the last paragraph on page 8, does locations mean fields within an attribute instance? If so, providing examples of these locations might be helpful. This might also benefit the first paragraph after the bullets on page 9. =20 =20 The last sentence of section 2 should be preceded by a restatement of the definition of an attribute (or a reference to the structure) to provide some context for the single value requirement. =20 =20 The IANA considerations are inconsistent with the liberal use of extensibility markers and text calling out possible future modifications, i.e., it seems probable that there will be future actions for IANA. =20 =20 The security considerations section will probably need some augmentation to address effects of processing rules. The current security considerations should state what types of protections are required for this attribute, if any. =20 =20 On page 9, /Housely/Housley/ ------_=_NextPart_001_01CBC2F0.A99CDAAE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

The = draft-herzog-setkey-03 I-D defines an attribute for use with the = symmetric key package structure defined in RFC 6031.

 

I have = a number of questions and concerns about this draft.  The primary = issue is a lack of discussion of who processes the attribute, how the = processing is performed and the effects of the processing.  Some of = my questions would probably be cleared up if the processing rules for = the attribute were clear.  For example, without understanding the = processing of the participant-sets, it is not clear why something simple = like a key usage value cannot be used to simply denote that the holder = of the key may only use the key in an active or passive way.  Below = are a list of questions, comments and nits more or less in the order = they appear in the document.

 

In the = last paragraph of section 1.1, it would be helpful to define = “participant-set” before noting that one may be = partitioned. 

 

On = page 3, s/Becuase/Because/

 

On = page 5, s/Futher/Further/

 

On = page 5, s/Heirarchy/Hierarchy/

 

What = grammar is being referenced in the last paragraph of section 1.2?  = As noted below, including the attribute syntax may be = helpful.

 

In section 2, why are the union, intersection and = setdiff represented in the attribute value instead of being calculated = by the key source with the results of the calculation included in the = attribute value? 

 

In section = 2, must each of union, intersection and setdiff have a terminal = SetKeyParticipantSet value that contains community, groupID or = explicit?  If so, it may be easier to move community and groupID = into SetMember and define the union, intersection and setdiff fields to = be SEQUENCEs of SetMembers. 

 

In section = 2, why SHOULD NOT appear in sKeyAttrs instead of MUST NOT?  When is = it OK to use for a specific key?  Would this attribute be = appropriate as an unprotected attribute in an RFC 6032 = structure?

 

The last sentence of the second paragraph below the = ASN.1 in section 2 states that a member SHOULD be considered active if = it appears in both lists.  What does this mean?  If the = participant is acting as a passive participant, must it be considered as = active because it appears in both lists or is passive a subset of active = by definition? 

 

In section = 2, the bullet that describes the union field refers to empty and = non-empty sets.  The syntax does not permit an empty = SetKeyParticipantSet value.  If the expectation is that each = SetKeyParticipantSet member in the union be evaluated first, that should = be clearly stated.  Same comment applies to the intersection and = setdiff fields.  This sort of evaluation seems like it could get = fairly complicated.

 

The bullets = describing the community and groupID fields indicate that the values = SHOULD represent unchanging sets of participants.  Earlier the = draft defines sets as immutable.  Should these SHOULDs be = MUSTs?  Are there any security considerations specific to using = groups with variable membership?

 

Section 2 = implies that a participant is evaluated relative to the contents of a = setkey attribute.  Where does the participant value come = from?  Does it identify a specific entity, a group or both?  =

 

Is the freeform field intended to carry text?  If = so why not use UTF8String instead of OCTET STRING?  There’s = probably a language tag issue to be had in here somewhere = too:-)

 

In the last paragraph on page 8, does locations mean = fields within an attribute instance?  If so, providing examples of = these locations might be helpful.  This might also benefit the = first paragraph after the bullets on page 9. 

 

The last = sentence of section 2 should be preceded by a restatement of the = definition of an attribute (or a reference to the structure) to provide = some context for the single value requirement. 

 

The IANA = considerations are inconsistent with the liberal use of extensibility = markers and text calling out possible future modifications, i.e., it = seems probable that there will be future actions for IANA.  =

 

The security considerations section will probably need = some augmentation to address effects of processing rules.  The = current security considerations should state what types of protections = are required for this attribute, if any. 

 

On page 9, = /Housely/Housley/

------_=_NextPart_001_01CBC2F0.A99CDAAE-- From barryleiba@gmail.com Wed Feb 2 13:34:29 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91DB13A6DD9; Wed, 2 Feb 2011 13:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.864 X-Spam-Level: X-Spam-Status: No, score=-102.864 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BY8kNGGXFg1; Wed, 2 Feb 2011 13:34:28 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 95C373A6D79; Wed, 2 Feb 2011 13:34:28 -0800 (PST) Received: by iyi42 with SMTP id 42so426551iyi.31 for ; Wed, 02 Feb 2011 13:37:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=3kyQdEA9Yyvv9WlqUDOvR+JOquSLuhn8020o+FmSF50=; b=DojnwYAyoaeB9ygOXONN2Zz59sl3lzFWb/9Da/Wz7+y8FlVPW008+VT/deqyT/nKRe UQSabPHgbesAoauEBfA/4GtQH1ObyyivXTVBhZL5aljcqOa4w2eEo2uq5szfJ1ri6lVN Ft4E+9gUNAiP36mrN36Zu0brQ9yR/OnNwullE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=E79TZsnfBfXr6Cc/EOdA5Zgcwi+YBe21rSiQhjP/rCVXvHGKjLfgDXqfNN77bAQ9dw Lec4bM2EdyMijR2G1vRWawdmVKn+0dvZfxPI+JorNniTOQ5usOk9dttMl3kqr/dpjfqJ xHKqWWSw/3HYGzr1fmtuY7IRAaUDz72S5dufw= MIME-Version: 1.0 Received: by 10.231.208.8 with SMTP id ga8mr10642993ibb.1.1296682668931; Wed, 02 Feb 2011 13:37:48 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.231.34.13 with HTTP; Wed, 2 Feb 2011 13:37:48 -0800 (PST) Date: Wed, 2 Feb 2011 16:37:48 -0500 X-Google-Sender-Auth: 0dzHPrKPHrlvb6E5GoRoCiYmq0w Message-ID: From: Barry Leiba To: draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org, secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: IESG Subject: [secdir] secdir review of draft-ietf-ccamp-mpls-tp-cp-framework-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 21:34:29 -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. In particular, I don't know a lot about MPLS, whatever "TP"s and "G"s and "PWE"s are attached to it. I've tried to read this from a security point of view only. The GenART review has given an excellent editorial look at the document, so I won't try to repeat that. I have only one concern, from the security viewpoint, and I'm not sure how much of a concern it is. Sections 2.1 to 2.3 list more than 130 requirements for the MPLS-TP control plane. Section 2.4, "Security Requirements", then says this: There are no specific MPLS-TP control plane security requirements. The existing framework for MPLS and GMPLS security is documented in [RFC5920] and that document applies equally to MPLS-TP. I have no way to tell whether, perhaps, some of those 130+ functional requirements ought to be generating some security requirements beyond what's in RFC 5920. For example, requirement 14, just to pick one: 14. The MPLS-TP control plane must support the logical separation of the control plane from the management and data plane [RFC5654, requirement 15]. Note that this implies that the addresses used in the control plane are independent from the addresses used in the management and data planes. Is it possible that requiring logical separation of the control plane from the management and data planes might also introduce a security requirement with respect to that separation? Perhaps the working group and the joint effort have already considered this for each requirement, and all is well. I can't tell: there are far too many requirements and variables here, and my knowledge of MPLS is far too slight. I just think it's important to bring up this point, and whenever I see discussion of out-of-band controls, I wonder about the security implications. The security considerations section (6) points out that this document is showing how other specifications provide the means to meet the requirements listed here, and that those specifications have (and possible future extension specifications will have) security considerations sections that properly cover the issues. I think that's correct; my concern is only about whether any security requirements might have been overlooked, which might necessitate an unanticipated adaptation in order to use, say, GMPLS to satisfy functional requirements here. Barry From lberger@labn.net Wed Feb 2 14:28:21 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28DE03A6C8A for ; Wed, 2 Feb 2011 14:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.16 X-Spam-Level: X-Spam-Status: No, score=-102.16 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AggpO-P0gVVp for ; Wed, 2 Feb 2011 14:28:20 -0800 (PST) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id F3AEC3A6BA9 for ; Wed, 2 Feb 2011 14:28:19 -0800 (PST) Received: (qmail 15350 invoked by uid 0); 2 Feb 2011 22:31:40 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 2 Feb 2011 22:31:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=c15LsLSo9gDzoWxoKpRkgg8lnccNk3Tsi2k+bXNSy1HakmKZy2wLOj4oeNAQaI+zqT7CHTPnpB+rFISZX5vDlq4HOfP4pnnLAQpmNqYHXFjovZd95Yk20FeEDomgOBL9; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PklEi-0001ET-9a; Wed, 02 Feb 2011 15:31:40 -0700 Message-ID: <4D49DB50.7020702@labn.net> Date: Wed, 02 Feb 2011 17:31:44 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: IESG , draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-ccamp-mpls-tp-cp-framework-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 22:28:21 -0000 Barry, Thank you for your review and comments. It's hard to respond to your general comments as they are just general concerns. My feeling is that this is just a framework and any specific protocol definitions will take place in new documents and, as such, will contain their own security considerations sections. I'm not sure there's much else we can do in this document to address the general comments. As your specific example/comment on separation. This is already an existing capability in GMPLS. So there's nothing really new here other than that TP requires GMPLS vs classic MPLS control plane. Please let me/us know if you think there's something else that should be done. Lou On 2/2/2011 4:37 PM, Barry Leiba 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. > > In particular, I don't know a lot about MPLS, whatever "TP"s and "G"s > and "PWE"s are attached to it. I've tried to read this from a > security point of view only. The GenART review has given an excellent > editorial look at the document, so I won't try to repeat that. > > I have only one concern, from the security viewpoint, and I'm not sure > how much of a concern it is. > Sections 2.1 to 2.3 list more than 130 requirements for the MPLS-TP > control plane. Section 2.4, "Security Requirements", then says this: > > There are no specific MPLS-TP control plane security requirements. > The existing framework for MPLS and GMPLS security is documented in > [RFC5920] and that document applies equally to MPLS-TP. > > I have no way to tell whether, perhaps, some of those 130+ functional > requirements ought to be generating some security requirements beyond > what's in RFC 5920. For example, requirement 14, just to pick one: > > 14. The MPLS-TP control plane must support the logical separation > of the control plane from the management and data plane > [RFC5654, requirement 15]. Note that this implies that the > addresses used in the control plane are independent from the > addresses used in the management and data planes. > > Is it possible that requiring logical separation of the control plane > from the management and data planes might also introduce a security > requirement with respect to that separation? Perhaps the working > group and the joint effort have already considered this for each > requirement, and all is well. > > I can't tell: there are far too many requirements and variables here, > and my knowledge of MPLS is far too slight. I just think it's > important to bring up this point, and whenever I see discussion of > out-of-band controls, I wonder about the security implications. > > The security considerations section (6) points out that this document > is showing how other specifications provide the means to meet the > requirements listed here, and that those specifications have (and > possible future extension specifications will have) security > considerations sections that properly cover the issues. I think > that's correct; my concern is only about whether any security > requirements might have been overlooked, which might necessitate an > unanticipated adaptation in order to use, say, GMPLS to satisfy > functional requirements here. > > Barry > > > > From barryleiba@gmail.com Wed Feb 2 15:23:54 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781B63A6C80; Wed, 2 Feb 2011 15:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.865 X-Spam-Level: X-Spam-Status: No, score=-102.865 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9+crU-Bj1nl; Wed, 2 Feb 2011 15:23:53 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 36F333A6BC2; Wed, 2 Feb 2011 15:23:53 -0800 (PST) Received: by iwc10 with SMTP id 10so541239iwc.31 for ; Wed, 02 Feb 2011 15:27:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KVuCdSiSiqrNSNuN9ux+jxe2hrYRjwMahEjE36H4ll8=; b=tkg5LeqFj0ieS8jFdIXRgAMGnEW7UCqLpAFfHE6a4dzkKtzZ3KpVJYPfkr/SoPDMXf sfAgHaIMERJOvotj6zFLlvigonwSFq0QEdUDrU74t0mUxWceR2XmrKb8X1AsJ5e928Sa WCZinsyLcAFIwCX4AF/7eoUpbTVNUZs1FBauc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=fuJ0ndhcb72Lrys9RHzPBhZYoVugaq5ho6sS5jtpdri31xdT1LwsBr0Z5zpbp+o0BX dfI+8TDJuALtJdVgB9LHnMI2Mz+k9nh0IyO1bJmio8NPECg2cJD+MtU5T7dy//3RpK4r m0vpo58p6kQDgpBOAyqpZTJCpIowj1TcRctH0= MIME-Version: 1.0 Received: by 10.231.12.131 with SMTP id x3mr10732320ibx.76.1296689233705; Wed, 02 Feb 2011 15:27:13 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.231.34.13 with HTTP; Wed, 2 Feb 2011 15:27:13 -0800 (PST) In-Reply-To: <4D49DB50.7020702@labn.net> References: <4D49DB50.7020702@labn.net> Date: Wed, 2 Feb 2011 18:27:13 -0500 X-Google-Sender-Auth: -Ha1s25NFDXTCd5tz1SHufGov4M Message-ID: From: Barry Leiba To: Lou Berger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IESG , draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-ccamp-mpls-tp-cp-framework-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 23:23:54 -0000 Hi, Lou. > It's hard to respond to your > general comments as they are just general concerns. Yes, indeed, and I don't necessarily expect anything. I wish I knew more about MPLS, for the purpose of giving this review. >=A0My feeling is that this > is just a framework and any specific protocol definitions will take place= in > new documents and, as such, will contain their own security consideration= s Absolutely. That's why I tried to be clear that my question isn't about the security considerations section (which I think is correct as it is), but about the security *requirements*. If, as you folks developed the 130+ functional requirements, you thought about whether they generated new security requirements that might not have been there before, and decided that they didn't, then that's fine. If you just said, "OK, any security requirements? No, none that we can think of," then you might have missed something by not thinking enough about the requirements in that light. But, again, I just wanted to raise the issue and ask what sort of thought was put into it; I don't necessarily expect any specific response. Barry > On 2/2/2011 4:37 PM, Barry Leiba 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. >> >> In particular, I don't know a lot about MPLS, whatever "TP"s and "G"s >> and "PWE"s are attached to it. =A0I've tried to read this from a >> security point of view only. =A0The GenART review has given an excellent >> editorial look at the document, so I won't try to repeat that. >> >> I have only one concern, from the security viewpoint, and I'm not sure >> how much of a concern it is. >> Sections 2.1 to 2.3 list more than 130 requirements for the MPLS-TP >> control plane. =A0Section 2.4, "Security Requirements", then says this: >> >> =A0 =A0There are no specific MPLS-TP control plane security requirements= . >> =A0 =A0The existing framework for MPLS and GMPLS security is documented = in >> =A0 =A0[RFC5920] and that document applies equally to MPLS-TP. >> >> I have no way to tell whether, perhaps, some of those 130+ functional >> requirements ought to be generating some security requirements beyond >> what's in RFC 5920. =A0For example, requirement 14, just to pick one: >> >> =A0 =A0 =A014. The MPLS-TP control plane must support the logical separa= tion >> =A0 =A0 =A0 =A0 =A0of the control plane from the management and data pla= ne >> =A0 =A0 =A0 =A0 =A0[RFC5654, requirement 15]. Note that this implies tha= t the >> =A0 =A0 =A0 =A0 =A0addresses used in the control plane are independent f= rom the >> =A0 =A0 =A0 =A0 =A0addresses used in the management and data planes. >> >> Is it possible that requiring logical separation of the control plane >> from the management and data planes might also introduce a security >> requirement with respect to that separation? =A0Perhaps the working >> group and the joint effort have already considered this for each >> requirement, and all is well. >> >> I can't tell: there are far too many requirements and variables here, >> and my knowledge of MPLS is far too slight. =A0I just think it's >> important to bring up this point, and whenever I see discussion of >> out-of-band controls, I wonder about the security implications. >> >> The security considerations section (6) points out that this document >> is showing how other specifications provide the means to meet the >> requirements listed here, and that those specifications have (and >> possible future extension specifications will have) security >> considerations sections that properly cover the issues. =A0I think >> that's correct; my concern is only about whether any security >> requirements might have been overlooked, which might necessitate an >> unanticipated adaptation in order to use, say, GMPLS to satisfy >> functional requirements here. >> >> Barry >> From mundy@sparta.com Wed Feb 2 16:03:06 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722593A6DB1; Wed, 2 Feb 2011 16:03: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BT7B1eHZfNI; Wed, 2 Feb 2011 16:03:04 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 7AAD73A6CA1; Wed, 2 Feb 2011 16:03:03 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p1306OWR004000; Wed, 2 Feb 2011 18:06:24 -0600 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p1306NLk025265; Wed, 2 Feb 2011 18:06:23 -0600 Received: from hobbes.columbia.ads.sparta.com ([157.185.80.174]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 19:06:23 -0500 From: Russ Mundy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Feb 2011 19:06:22 -0500 Message-Id: To: secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 03 Feb 2011 00:06:23.0408 (UTC) FILETIME=[315DEB00:01CBC336] Cc: draft-ietf-speermint-architecture-all@tools.ietf.org, iesg@ietf.org, Russ Mundy Subject: [secdir] secdir Review of draft-ietf-speermint-architecture-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 00:03:06 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. Since this review is for the architecture document, I needed to refer to = the other drafts and RFCs from the WG to complete this review and I want = to compliment the speermint WG for producing a cohesive set of = documents. A perhaps minor criticism is that the architecture document seems to = have a narrower technology focus than other documents that are normative = references, e.g., voipthreats, usecases, requirements. Particularly = after trying to determine the basic intent of the Security = Considerations section (9), it appears as though this architecture = document is focused on just the interconnection between two SIP Service = Providers (SSP) while some of the normative references provide much more = of an end-to-end description of the technology. Since this document has = "architecture" in it's name but a somewhat narrower technology scope = than some of it's normative references, it would seem to be useful to = clearly state this in the introduction (or elsewhere) in the document. Security Considerations specific comments: I do have concerns with the = specifics of the Security Considerations section, in particular, I don't = really understand the basic intent of what the two main paragraphs are = trying to say. - The basic meaning of when encryption should be used in the first = paragraph is awkward and not clear (perhaps it's a compromise wording = from the WG but that won't matter later) - I can read the wording = several different ways which would result in very different inferences = about when cryptography should actually be used, e.g.,: - - "cryptographic-based security" should be used for all cases unless = the connection is protected by physical security; - - if there is not physical security between the peering providers, the = use of "cryptographic-based security" is suggested/recommended; - - use of "cryptographic-based security" is optional in all situations; - - intended use of "cryptographic-based security" is different than any = of the above. Suggested solution: It seems to me like there should be some specific = references to the appropriate sections of the voipthreats & requirements = documents - this should not be a problem since they are normative = references and will need to be published more or less at the same time. - The second paragraph of the section seems to be saying that the WG = believes that additional methods of peering need to be standardized = (which seems fine) but it's rather unclear what the "maintain a = consistent approach" is supposed to be consistent with especially since = the security requirements of the previous paragraph are unclear. Suggested solution: If clear and reasonably specific requirements can be = identified for the previous paragraph then it seems like these (or = equivalent requirements) can be applied to future standards for peering. Other (basically editorial) Comments: - In Section 4, the term "Session Border Controller" is not defined in = RFC5486 or this document - it seems like a definition should be = included. - In Section 4, the first three bullet points would have "function = function" if the acronyms were spelled out - this might be okay but some = people view it as incorrect. - In the fourth bullet of Section 4, it's not clear what "can = communicate" means - is this a restrictive statement, does it mean that = only the left-most function can initiate an exchange or something else = altogether. It seems like a clarification is in order. - In Section 5.1.2.2, the term "carrier-of-record" is used. The term is = not defined or used elsewhere and seems to be important to the proper = functioning of the procedure. A clarification would seem to be in = order. - In Section 5.1.3.2, IPSec is mentioned in the originating procedures. = There is no corresponding mention in the target procedures section which = seems to be an omission that should be corrected. =20 Russ Mundy From jari.arkko@piuha.net Fri Feb 4 04:22:03 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEE643A6956 for ; Fri, 4 Feb 2011 04:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTMxS1XS0ubb for ; Fri, 4 Feb 2011 04:22:01 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 22D773A6916 for ; Fri, 4 Feb 2011 04:22:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 679972CC3C; Fri, 4 Feb 2011 14:25:25 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7+zi-aLk7W2; Fri, 4 Feb 2011 14:25:25 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 07A232CC2D; Fri, 4 Feb 2011 14:25:25 +0200 (EET) Message-ID: <4D4BF034.9020901@piuha.net> Date: Fri, 04 Feb 2011 14:25:24 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Stephen Kent References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ralph Droms , lars.eggert@nokia.com, secdir@ietf.org Subject: Re: [secdir] review of draft-arkko-dual-stack-extra-lite-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 12:22:03 -0000 Stephen, Thank you for your review. > The security considerations section is but one sentence: "This > practices outlined in this document do not affect the security > properties of address translation." I think this needs to be expanded > upon :. The authors should cite at least one RFC that deals with NAT > and has sustentative security considerations section. If they can't > find a suitable RFC (2993 is the obvious candidate, but it is outdated > in several of its references and comments) then they at least describe > why they believe that this proposal introduces no new security > implications. I have updated the Internet Draft today, and added some material on this as well. Look at http://tools.ietf.org/html/draft-arkko-dual-stack-extra-lite for the diffs. Jari From weiler+secdir@watson.org Mon Feb 7 03:36:16 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB9BF3A6DDF for ; Mon, 7 Feb 2011 03:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ikzs7OK+oQc for ; Mon, 7 Feb 2011 03:36:16 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id EE0ED3A6DD5 for ; Mon, 7 Feb 2011 03:36:15 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p17BaISs063321 for ; Mon, 7 Feb 2011 06:36:18 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p17BaHjv063317 for ; Mon, 7 Feb 2011 06:36:18 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 7 Feb 2011 06:36:17 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 07 Feb 2011 06:36:18 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 07 Feb 2011 11:36:17 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Alan DeKok is next in the rotation. For telechat 2011-02-17 Reviewer LC end Draft Radia Perlman T 2011-02-08 draft-mraihi-mutual-oath-hotp-variants-12 Eric Rescorla T 2011-01-07 draft-ietf-pce-inter-layer-req-15 Eric Rescorla T 2011-02-08 draft-mraihi-totp-timebased-07 For telechat 2011-03-03 Richard Barnes T 2011-03-02 draft-mrw-nat66-07 Julien Laganier T 2011-02-11 draft-holsten-about-uri-scheme-06 Magnus Nystrom T 2011-02-23 draft-meadors-multiple-attachments-ediint-10 Tom Yu T 2011-02-22 draft-josefsson-rc4-test-vectors-02 Last calls and special requests: Rob Austein 2011-02-16 draft-ietf-netconf-rfc4742bis-06 Dave Cridland - draft-ietf-sidr-arch-11 Dave Cridland 2011-01-18 draft-ietf-isis-purge-tlv-05 Alan DeKok 2011-01-18 draft-ietf-isis-reg-purge-00 Love Hornquist-Astrand 2011-02-01 draft-yevstifeyev-tn3270-uri-15 David McGrew - draft-ietf-ecrit-framework-12 David McGrew 2011-02-01 draft-ietf-intarea-shared-addressing-issues-02 Russ Mundy 2011-01-04 draft-cardona-cablelabs-urn-05 Vincent Roca 2011-02-07 draft-reed-urn-dgiwg-02 Joe Salowey 2011-02-08 draft-turner-akf-algs-update-02 Stefan Santesson 2011-02-08 draft-turner-ekpct-algs-update-02 Yaron Sheffer 2011-02-01 draft-ietf-ccamp-rwa-wson-framework-10 Tina TSOU 2011-02-07 draft-ietf-netconf-4741bis-07 Sam Weiler 2011-02-16 draft-ietf-hokey-ldn-discovery-06 Brian Weis 2011-03-02 draft-herzog-static-ecdh-04 Nico Williams 2011-01-14 draft-yevstifeyev-http-headers-not-recognized-11 Nico Williams 2011-02-09 draft-ietf-rmt-bb-fec-raptorq-04 Larry Zhu 2010-09-30 draft-lundberg-app-tei-xml-06 Glen Zorn 2011-02-10 draft-ietf-shim6-multihome-shim-api-15 From yoshihiro.ohba@toshiba.co.jp Mon Feb 7 16:24:59 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623093A6C8B; Mon, 7 Feb 2011 16:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kP89SUzaSHxK; Mon, 7 Feb 2011 16:24:58 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id 4304D3A6B0A; Mon, 7 Feb 2011 16:24:58 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id p180OoNn004793; Tue, 8 Feb 2011 09:24:50 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id p180Oojm018519; Tue, 8 Feb 2011 09:24:50 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id KAA18517; Tue, 8 Feb 2011 09:24:50 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id p180OotB006363; Tue, 8 Feb 2011 09:24:50 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p180OnFN001418; Tue, 8 Feb 2011 09:24:49 +0900 (JST) Received: from [133.199.75.42] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LG9006F0VTBBL80@mail.po.toshiba.co.jp>; Tue, 08 Feb 2011 09:24:49 +0900 (JST) Date: Tue, 08 Feb 2011 09:24:41 +0900 From: Yoshihiro Ohba To: "'Margaret Wasserman'" , Ralph Droms Message-id: <4D508D49.30208@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 Cc: secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org, Rafa Marin Lopez , pana@ietf.org Subject: [secdir] Fwd: New Version Notification for draft-ohba-pana-relay-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 00:24:59 -0000 We have updated pana-relay draft, incorporating all received comments and associated discussions. Thanks, Yoshihiro Ohba -------- Original Message -------- Subject: New Version Notification for draft-ohba-pana-relay-03 Date: Thu, 03 Feb 2011 23:13:23 -0800 (PST) From: IETF I-D Submission Tool To: yoshihiro.ohba@toshiba.co.jp CC: paduffy@cisco.com, samitac2@gmail.com, robert.cragie@gridmerge.com, alper.yegin@yegin.org A new version of I-D, draft-ohba-pana-relay-03.txt has been successfully submitted by Yoshihiro Ohba and posted to the IETF repository. Filename: draft-ohba-pana-relay Revision: 03 Title: Protocol for Carrying Authentication for Network Access (PANA) Relay Element Creation_date: 2011-02-04 WG ID: Independent Submission Number_of_pages: 12 Abstract: This document specifies Protocol for carrying Authentication for Network Access (PANA) Relay Element functionality which enables PANA messaging between a PANA Client (PaC) and a PANA Authentication Agent (PAA) where the two nodes cannot reach each other by means of regular IP routing. The IETF Secretariat. From tena@huawei.com Mon Feb 7 18:05:02 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD6E3A7008; Mon, 7 Feb 2011 18:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6uNdBVg-UJ6; Mon, 7 Feb 2011 18:05:01 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 585FB3A7007; Mon, 7 Feb 2011 18:05:01 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGA009ZM0GHR5@usaga02-in.huawei.com>; Mon, 07 Feb 2011 18:05:06 -0800 (PST) Received: from TingZousc1 ([10.193.34.106]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGA0082F0GHMN@usaga02-in.huawei.com>; Mon, 07 Feb 2011 18:05:05 -0800 (PST) Date: Mon, 07 Feb 2011 18:05:05 -0800 From: Tina Tsou To: secdir@ietf.org Message-id: <00dc01cbc734$9ab8cbe0$d02a63a0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvHNJologxQ/mhUTsec0i/teATXiw== Cc: ietf@ietf.org, iesg@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Subject: [secdir] Review of draft-ietf-netconf-4741bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 02:05:02 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. It is well written, so only some editorial comments are below. #1 " 2.2. Authentication, Integrity, and Confidentiality ... 2.3. Authentication ... " Perhaps the Titles of 2.2 and 2.3 can harmonize better to explain why there are two "authentications" here. #2 " 6.2. Subtree Filter Components A subtree filter is comprised of XML elements and their XML attributes. There are five types of components that may be present in a subtree filter: o Namespace Selection o Attribute Match Expressions o Containment Nodes o Selection Nodes o Content Match Nodes ... " If a figure could be provided to describe the relationship among these 5 components and when it becomes what, it would be very helpful for readers to understand more easily. #3 " 6.2.3. Containment Nodes Nodes that contain child elements within a subtree filter are called "containment nodes". I would say "Child Elements Nodes" or "Child Nodes" might be a little bit more of straight forward than "Containment Nodes". #4 " 7.2. ... Parameters: ... merge: The configuration data in the parameter is merged with the configuration at the corresponding level in the target datastore. This is the default behavior. ... " Has the parameter been introduced before? Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From bertietf@bwijnen.net Tue Feb 8 02:06:09 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388623A70D0; Tue, 8 Feb 2011 02:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.442 X-Spam-Level: X-Spam-Status: No, score=-100.442 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr7eIFDXTogL; Tue, 8 Feb 2011 02:06:08 -0800 (PST) Received: from relay.versatel.net (beverwijk.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id DE3363A70CE; Tue, 8 Feb 2011 02:06:07 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1PmkSZ-0007PZ-5r; Tue, 08 Feb 2011 11:06:11 +0100 Message-ID: <8361477078854CCF9EBF9CDA8CEAF44A@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Tina Tsou" , References: <00dc01cbc734$9ab8cbe0$d02a63a0$@com> In-Reply-To: <00dc01cbc734$9ab8cbe0$d02a63a0$@com> Date: Tue, 8 Feb 2011 11:06:06 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18263 Cc: Netconf , iesg@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Subject: Re: [secdir] Review of draft-ietf-netconf-4741bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 10:06:09 -0000 Tina, thanks for your review and comments All comments together are being considered by the editors and possibly will result in a new revision. We'll keep you updated. But I believe you are also on our netconf wg mailing list, so you'll see it there too. Bert Wijnen Document Shepherd ----- Original Message ----- From: "Tina Tsou" To: Cc: ; ; Sent: Tuesday, February 08, 2011 3:05 AM Subject: Review of draft-ietf-netconf-4741bis-07 >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. > > It is well written, so only some editorial comments are below. > > #1 > " > 2.2. Authentication, Integrity, and Confidentiality > ... > 2.3. Authentication > ... > " > > Perhaps the Titles of 2.2 and 2.3 can harmonize better to explain why there > are two "authentications" here. > > #2 > " > 6.2. Subtree Filter Components > > A subtree filter is comprised of XML elements and their XML > attributes. There are five types of components that may be present > in a subtree filter: > > o Namespace Selection > > o Attribute Match Expressions > > o Containment Nodes > > o Selection Nodes > > o Content Match Nodes > ... > " > > If a figure could be provided to describe the relationship among these 5 > components and when it becomes what, it would be very helpful for readers to > understand more easily. > > #3 > " > 6.2.3. Containment Nodes > > Nodes that contain child elements within a subtree filter are called > "containment nodes". > > I would say "Child Elements Nodes" or "Child Nodes" might be a little bit > more of straight forward than "Containment Nodes". > > > #4 > " > 7.2. > ... > Parameters: > ... > merge: The configuration data in the parameter is > merged with the configuration at the corresponding level in > the target datastore. This is the default behavior. > ... > " > Has the parameter been introduced before? > > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > > From new-work-bounces@ietf.org Mon Feb 7 15:20:06 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73D503A6FCA; Mon, 7 Feb 2011 15:20:06 -0800 (PST) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C41A33A6FC9 for ; Mon, 7 Feb 2011 15:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jetwR8skXcH for ; Mon, 7 Feb 2011 15:20:03 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id EE05B3A6FB6 for ; Mon, 7 Feb 2011 15:20:02 -0800 (PST) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1PmaNK-0000Pp-TU; Mon, 07 Feb 2011 18:20:07 -0500 Message-Id: <7833151C-619A-4BB6-AE6D-6897DACFA7A7@w3.org> From: Ian Jacobs To: new-work@ietf.org Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 7 Feb 2011 17:20:06 -0600 X-Mailer: Apple Mail (2.936) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 08 Feb 2011 08:11:18 -0800 Subject: [secdir] [new-work] Proposed W3C XML Activity (until 2011-03-07) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:20:07 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the XML Activity [0] (see the W3C Process Document description of Activity Proposals [1]). The proposal is publicly available: http://www.w3.org/XML/2010/10/ As part of ensuring that the community is aware of proposed work at W3C, this proposal and the charters linked from it are public during the Advisory Committee review period. W3C invites public comments through 2011-03-07 on the proposal. 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 Liam Quin, XML Activity Lead . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/XML/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From jsalowey@cisco.com Tue Feb 8 10:39:04 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50BC03A6816; Tue, 8 Feb 2011 10:39:04 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv4cd1oq2tMc; Tue, 8 Feb 2011 10:39:03 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 2F0F93A67E1; Tue, 8 Feb 2011 10:39:02 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJQcUU2rR7Hu/2dsb2JhbAClN3OhHJs5hVoEhHuGb4Mu Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 08 Feb 2011 18:39:09 +0000 Received: from [10.33.248.224] ([10.33.248.224]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p18Id90I018585; Tue, 8 Feb 2011 18:39:09 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Feb 2011 10:40:12 -0800 Message-Id: To: secdir@ietf.org, The IESG , draft-turner-akf-algs-update.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [secdir] Secdir review of draft-turner-akf-algs-update-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:39:04 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document is a standards track document describing the conventions = for using some ECC algorithms in CMS. It is probably the shortest draft = I've reviewed. It does not define new functionality so its security = considerations reference other documents. This seems appropriate. I = have no concerns about the document. =20 Joe= From rbarnes@bbn.com Tue Feb 8 21:47:52 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9181E3A68F5; Tue, 8 Feb 2011 21:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.499 X-Spam-Level: X-Spam-Status: No, score=-101.499 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, J_BACKHAIR_15=1, J_CHICKENPOX_43=0.6, J_CHICKENPOX_66=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+J7psrLUaAO; Tue, 8 Feb 2011 21:47:51 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 329A53A6903; Tue, 8 Feb 2011 21:47:51 -0800 (PST) Received: from [128.89.252.189] (port=50599 helo=[10.71.1.98]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pn2uF-000MNY-Hu; Wed, 09 Feb 2011 00:47:59 -0500 From: Richard L. Barnes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Feb 2011 21:47:56 -0800 Message-Id: To: secdir@ietf.org, The IESG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: draft-mrw-nat66@tools.ietf.org Subject: [secdir] secdir review of draft-mrw-nat66-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 05:47:52 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. This document defines a mechanism for stateless translation of IPv6 = addresses in packets from one prefix to another, which affects only the = IP layer (neither transport-layer ports nor checksums are affected). = Overall, the document is well and clearly written, and does a good job = of discussing the trade-offs involved in adding NAT to a network.=20 =46rom a security perspective, the document correctly documents most = major security impacts. They note that running with NAT66 provides no = more protection than running an un-NATted network, and that while = limiting NAT to the IP layer interacts well with most security = protocols, it will break things that protect the IP header (like AH). The one major security comment I have is that it would also be helpful = for this document to discuss how NAT66 interacts with IP-address based = access control lists, in particular, the SPD and PAD in IPsec. Other general, non-security comments follow. Major: The description of the mapping algorithm is a little bit unclear. = For example, I didn't realize that the algorithm leaves the low-order = bits of the address unchanged. In addition, the current algorithm is = only applicable for prefix lengths that are a multiple of 16. I would = suggest the following modified algorithm: " o The NAT is configured with an interior and exterior prefix, each one the same length, n_pre bits. o The NAT computes the number of "residual bits" to the next 16-bit boundary: n_res =3D 16 - (n_pre % 16) o The NAT computes the checksum of the two prefixes, padded with 0 to a multiple of 16 bits. o The NAT swaps the low-order n_pre bits of the checksum with the remaining bits to compute the "patch bytes" - hi_patch =3D sum >> n_res; - lo_patch =3D sum ^ (hi_patch << n_res); - patch =3D (lo_patch << 16-n_res) ^ hi_patch; o The NAT computes a "difference address" in the following steps o The base difference address is the XOR of the two prefixes o The patch bytes are appended to the end of the difference address o The difference address is padded with 0 to 128 bits o In summary: diff =3D preA ^ preB ^ (patch << (addr_len - n_pre - = 16)) o When the NAT receives a packet with an address matching either = prefix, it maps the address to the other prefix by XORing the address with=20 the difference address " Because I'm writing this on a long flight with nothing much else to do, = I went ahead and wrote an sample implementation of this algorithm. C = code is pasted below. =20 Major: What is the point of Section 9? Why are you concerned about = protecting 0xFFFF values in the IID? If you just want to prevent = translation of anycast identifiers, it seems like it would be more = effective to just special-case them. Minor: The document says that ALGs may be necessary for applications to = work through NAT66. The consensus in the RAI/APP community actually = seems to be that host-based NAT traversal mechanisms are more effective = than ALGs. It would be helpful to have an informative references to ICE = and/or ICE-TCP (I apologize, I don't have the RFC numbers on hand). Minor: It could be helpful to add a note about how traffic gets to the = NAT66 in the first place. In the case where the NAT66 is a gateway to = the Internet, this is pretty obvious, but the network-to-network case is = less clear. =20 Minor: The document says that parallel NATs can be use different = prefixes; it might be helpful to comment briefly what the impact of this = change would be -- in particular, it would pin routing of certain = packets through a particular NAT, possibly leading to inefficient = routing. Nit: In Section 8, it's not clear what the reference "as described = above" refers to. -----BEGIN nat66.c----- #include #include #include #include #define ADDR_LEN_32 4 struct inaddr6 { uint32_t bytes[ADDR_LEN_32]; }; /** * Compute the IP checksum over an address structure */ uint16_t inaddr6_checksum(struct inaddr6 *addr) { uint16_t sum =3D 0x0000; size_t i; for (i=3D0; ibytes[i]) % (1<<16); sum ^=3D (addr->bytes[i]) >> 16; } return sum; } /** * Compute the XOR of two addresses */ struct inaddr6 inaddr6_xor(struct inaddr6 *addr1, struct inaddr6 *addr2) = { struct inaddr6 xor; size_t i; for (i=3D0; ibytes[i] ^ addr2->bytes[i]; } return xor; } /** * Place a uint16_t somewhere within an address (overwriting the * current value at that position). Positions start at 0. */ void inaddr6_place(struct inaddr6 *addr, uint16_t val, size_t bitpos) { assert(bitpos <=3D 112); size_t uint_pos =3D bitpos >> 5; size_t in_uint_pos =3D bitpos % (1<<5); uint32_t bigval, mask; if (in_uint_pos <=3D 16) { bigval =3D (uint32_t) val; mask =3D (0xFFFFFFFF >> (32-in_uint_pos)) << (32-in_uint_pos); addr->bytes[uint_pos] &=3D mask; addr->bytes[uint_pos] ^=3D (bigval << (16-in_uint_pos)); } else { bigval =3D ((uint32_t) val) >> (in_uint_pos - 16); mask =3D (0xFFFFFFFF >> (in_uint_pos - 16)) << (in_uint_pos - = 16); addr->bytes[uint_pos] &=3D mask; addr->bytes[uint_pos] ^=3D bigval; bigval =3D ((uint32_t) val) % (1<<(in_uint_pos-16)) << (48 - = in_uint_pos); mask =3D (0xFFFFFFFF >> (32 - in_uint_pos)); addr->bytes[uint_pos+1] &=3D mask; addr->bytes[uint_pos+1] ^=3D bigval; } } /** * Pretty-print an IPv6 address */ char *inaddr6_string(struct inaddr6 *addr) { char *saddr; asprintf( &saddr, "%04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x", addr->bytes[0] >> 16, addr->bytes[0] % (1<<16), addr->bytes[1] >> 16, addr->bytes[1] % (1<<16), addr->bytes[2] >> 16, addr->bytes[2] % (1<<16), addr->bytes[3] >> 16, addr->bytes[3] % (1<<16) ); return saddr; } /** * Compute the patch necessary to correct for a given checksum, * with a given number of "residual bits". The number of residual * bits is the distance from the end of the prefix to the next * 16-bit boundary. Basically this function swaps the part of the=20 * checksum that overlaps the prefix with that which doesn't. */ uint16_t nat66_patch(uint16_t sum, uint16_t n_res) { uint16_t hi_patch =3D sum >> n_res; uint16_t lo_patch =3D sum ^ (hi_patch << n_res); uint16_t patch =3D (lo_patch << (16-n_res)) ^ hi_patch; return patch; } int main(int ac, char **av) { // Inputs: 2001:db8:0100::/40, fd01:0203:0400::/40 struct inaddr6 preA =3D { 0x20010db8, 0x01000000, 0x00000000, = 0x00000000 }; struct inaddr6 preB =3D { 0xfd010203, 0x04000000, 0x00000000, = 0x00000000 }; size_t n_pre =3D 40; // Prepare the NAT delta size_t n_res =3D 16 - (n_pre % 16); struct inaddr6 rawdiff =3D inaddr6_xor(&preA, &preB); uint16_t patch =3D nat66_patch( inaddr6_checksum(&rawdiff), n_res ); struct inaddr6 diff =3D rawdiff; inaddr6_place( &diff, patch, n_pre ); // Test on a sample address: 2001:db8:0100::1234 struct inaddr6 addrA =3D { 0x20010db8, 0x01000000, 0x00000000, = 0x00001234 }; struct inaddr6 addrB =3D inaddr6_xor( &addrA, &rawdiff ); struct inaddr6 addrC =3D inaddr6_xor( &addrA, &diff ); // Display results printf("Original address: %s [%04x]\n", inaddr6_string(&addrA), = inaddr6_checksum(&addrA)); printf("Unpatched address: %s [%04x]\n", inaddr6_string(&addrB), = inaddr6_checksum(&addrB)); printf("Patched address: %s [%04x]\n", inaddr6_string(&addrC), = inaddr6_checksum(&addrC)); } -----END nat66.c-----= From vincent.roca@inrialpes.fr Thu Feb 10 12:00:21 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 667543A6A7F; Thu, 10 Feb 2011 12:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.205 X-Spam-Level: X-Spam-Status: No, score=-10.205 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmrYZTx93MHy; Thu, 10 Feb 2011 12:00:19 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id AFE323A6A64; Thu, 10 Feb 2011 12:00:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,451,1291590000"; d="scan'208";a="99669915" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO macbook-de-roca.local) ([82.236.155.50]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 10 Feb 2011 21:00:30 +0100 Message-ID: <4D541191.6040208@inrialpes.fr> Date: Thu, 10 Feb 2011 17:25:53 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IESG References: <4C976675.2060302@inrialpes.fr> In-Reply-To: <4C976675.2060302@inrialpes.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-fecframe-framework.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-fecframe-framework-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 20:00:21 -0000 All, The goal of this email is to clarify the situation WRT my SecDir review of this document, back in September. All my comments have been addressed in the new version -12. A very constructive discussion took place on the FECFRAME mailing list in Nov-Dec. Additional considerations, not listed in my review, have been raised during the discussion and included in version -12. If you go through the -12 version, you'll see I'm now a co-author of this I-D (I'm an active contributor to this WG which explains why this is so). Some of you may consider there's now a conflict of interest... Cheers, Vincent 0n 20/09/10 15:49, Vincent Roca wrote: > Mark, 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 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. > > (NB: to make it clear, I've been randomly selected to review > this document, I didn't ask) > > > Main comments: > -------------- > > 1) As a general comment, having a sound, detailed security > section in this FECFRAME framework document is critical > since this document is referred by all the WG documents > and all of them inherit the framework recommendations. > From this point of view, the current security discussion > is not satisfying IMHO. > > If we further compare this FECFRAME/framework section > to the similar section in the ALC, Flute and NORM RFC > (those RMT protocols share some similarities in terms > of security requirements), we see major difference in > terms of completeness of the discussion. > > 2) There is no "Minimum security requirement". More > precisely this document does not identify a mandatory > to implement (but not necessarily to use) security > configuration. I think this also applies here. > IPsec/ESP is usually a good solution for that... > > > Additional comments: > -------------------- > > I'm okay with the first two paragraphs. Then: > > 3) I'd like to see a discussion which differentiates the > various security requirements of interest: > - security WRT the data flow itself, which essentially > concerns the content provider; > - security WRT the FECFRAME system, which essentially > concerns the sending and receiving hosts; > - security WRT the network, in the sense "additional > risks that the use of FECFRAME may create for the > network", which of course concerns all the hosts; > The goal of this section is not to solve all these issues > but to highlight the risks, the gradation in the risks, > and to give some directions on how to mitigate them (or > solve them if feasible). > > 4) paragraph 3 has been largely improved compared to > previous versions, however I still find the discussion > confusing. > > So I suggest another organization: > - if integrity protection is required, using it above > FECFRAME, at the ADU level, is operational since all > corrupted ADUs are finally detected as such. But of > course there are limits (e.g. DoS as already > explained). > - if integrity protection is required, using it below > FECFRAME has the advantage of reducing DoS risks. > This is therefore RECOMMENDED. > - however when applied below FECFRAME, this integrity > service will not necessarily be end-to-end (depends > on how FECFRAME is used, end-to-end or not). Whether > it's appropriate or not depends on whether one can > tell where the security threats are (which is > use-case dependent). > > BTW: use the "ADU"/"ADU flow" rather than "source > packets" to be in-line with the agreed terminology. > > > 5) paragraph 4: I don't like the discussion here. > The same comment on resource waste can be made with > non encrypted flows. Concerning the second comment of > this paragraph, it's clear that giving a copy of > plaintext repair packets to non authorized receivers > will lead to problems, but is it so different than > giving a copy of plaintext source packets? When we > say that confidentiality protection is applied after > FEC encoding, this is for instance within IPsec, i.e. > all source/repair FEC packets are encrypted. That's > the assumption (paragraph 2). > > I suggest to change this discussion as follows: > - when ADU flows with different security requirements > need to be FEC protected jointly, then each flow MAY > be processed appropriately before entering FECFRAME > e.g. to encrypt it. > (Note that this is not a MUST. E.g. there are situations > where the only insecure domain is the one over which > FECFRAME operates => this situation may be addressed > with IPsec/ESP, for the whole flow) > - it is then REQUIRED that the FECFRAME aggregate flow > be in line with the maximum security requirements of > the individual ADU flows. E.g. if DoS protection is > required, since the use of FECFRAME must not add any > additional threat, an integrity protection must be > provided below FECFRAME. > - generally speaking it is often RECOMMENDED to avoid > FEC protecting flows with largely different security > requirements. > > > 6) A note should be added to highlight the fact that > attacks targeting the congestion control building block > (when applicable) may severely damage the network. A > pointer to section 8 should be added. > > > 7) It should be noted that certain security transforms > will add some latency to the ADU flow delivery. This > latency may need to be considered when dealing with > real-time flows. > > NB: I don't think ciphering is an issue, but TESLA > authentication/integrity will probably not be > appropriate! There are other similar examples. > > > Regards, > > Vincent From turners@ieca.com Mon Feb 14 09:23:05 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F6093A6D4D for ; Mon, 14 Feb 2011 09:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0uUVmpj-hk9 for ; Mon, 14 Feb 2011 09:23:04 -0800 (PST) Received: from nm2-vm0.bullet.mail.ac4.yahoo.com (nm2-vm0.bullet.mail.ac4.yahoo.com [98.139.52.66]) by core3.amsl.com (Postfix) with SMTP id 7C5D33A69A6 for ; Mon, 14 Feb 2011 09:23:04 -0800 (PST) Received: from [98.139.52.197] by nm2.bullet.mail.ac4.yahoo.com with NNFMP; 14 Feb 2011 17:23:25 -0000 Received: from [98.139.52.157] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 14 Feb 2011 17:23:25 -0000 Received: from [127.0.0.1] by omp1040.mail.ac4.yahoo.com with NNFMP; 14 Feb 2011 17:23:25 -0000 X-Yahoo-Newman-Id: 99096.93285.bm@omp1040.mail.ac4.yahoo.com Received: (qmail 79574 invoked from network); 14 Feb 2011 17:23:24 -0000 Received: from thunderfish.local (turners@96.231.127.49 with plain) by smtp115.biz.mail.re2.yahoo.com with SMTP; 14 Feb 2011 09:23:24 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: pMQz3i4VM1nnQZv.hqrxcb5OMByIhIm2cAdvb3d92ysvRdt jjwammwNp8WgEUKztMzav4CuspdeZA8O6Ifzv4xFdpsIH9DfP9iuWqpN1Hqg .uGJ7fbP2fPpQgACppXea6sN3Ut9FZHiVq9Iqu0K2g1hqjlW1bBHylR9ITIG W08Qx4A5bW0E_TzxYMxbIWbg8Ln3jOE8uaJmYVZHLdvw8cJ4._8j20fTmVW2 EaF7DHz1wZVv2OH7.6pXjxdLdUMUDIe7LTHKBZt9S_AjfD2WYAVvsQw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D59650C.70401@ieca.com> Date: Mon, 14 Feb 2011 12:23:24 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] IETF 80 Security Directorate Lunch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 17:23:05 -0000 All, I've requested a room for Tuesday at 11:30 for our normal Security Directorate Lunch. As soon as I get a room assigned, I'll let you know. spt From gjshep@gmail.com Thu Feb 10 12:23:14 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421353A6833; Thu, 10 Feb 2011 12:23:14 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cvEXiIVgBDm; Thu, 10 Feb 2011 12:23:12 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 31BCA3A6838; Thu, 10 Feb 2011 12:23:11 -0800 (PST) Received: by bwz12 with SMTP id 12so2719591bwz.31 for ; Thu, 10 Feb 2011 12:23:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XlDy21OXgVXaBAMQp8/czeO2b3ck8vR0EXV00UNMBJs=; b=q5iCSoBg8BS2NerY3/sg5FxhEjGSOKTnPOakcaHLdL539QJg3p07mHcyfYk+I9KKf9 pI6nKTPSCkT6TFs6A/2uZprT97ZymBFti0iInHdvDgcxR79k2UuzWnQ2x2s0IEUyEONj WRL+LHQblGBy+JmVAvXDsdz6GR9RaTGkNLphE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=XyoPD8+xcBs4Gf4ATGxekmgm6kI2uLTtICZw56YrF1sbC7dqxHA5UMxcWX2dEzZdQq +jQH27OWDBVW5N5rq1sAI3Sm4DulHLMgjLZ5XOm94vOJYmFcFLZXakGkCBjhVXI3zWME 15yXNJMHYf8bnRtgt84TBeq1Dgne0eOKcxOz0= MIME-Version: 1.0 Received: by 10.204.49.208 with SMTP id w16mr3110301bkf.166.1297369403346; Thu, 10 Feb 2011 12:23:23 -0800 (PST) Received: by 10.204.15.72 with HTTP; Thu, 10 Feb 2011 12:23:23 -0800 (PST) In-Reply-To: <4D541191.6040208@inrialpes.fr> References: <4C976675.2060302@inrialpes.fr> <4D541191.6040208@inrialpes.fr> Date: Thu, 10 Feb 2011 12:23:23 -0800 Message-ID: From: Greg Shepherd To: Vincent Roca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 14 Feb 2011 09:37:42 -0800 Cc: draft-ietf-fecframe-framework.all@tools.ietf.org, IESG , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-fecframe-framework-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 20:23:14 -0000 Vincent, I see no conflict and I greatly appreciate your continued contribution to the WG. We are (were) so close to completion up until Dec. I was hoping to have the framework draft in the editors queue by Prague. Thanks, Greg On Thu, Feb 10, 2011 at 8:25 AM, Vincent Roca w= rote: > All, > > > > The goal of this email is to clarify the situation WRT my SecDir > review of this document, back in September. > > All my comments have been addressed in the new version -12. > A very constructive discussion took place on the FECFRAME mailing > list in Nov-Dec. Additional considerations, not listed in my review, > have been raised during the discussion and included in version -12. > > > > > If you go through the -12 version, you'll see I'm now a co-author > of this I-D (I'm an active contributor to this WG which explains why > this is so). Some of you may consider there's now a conflict of > interest... > > > > Cheers, > > =A0 Vincent > > 0n 20/09/10 15:49, Vincent Roca wrote: >> >> =A0Mark, 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 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. >> >> (NB: to make it clear, I've been randomly selected to review >> =A0this document, I didn't ask) >> >> >> Main comments: >> -------------- >> >> 1) As a general comment, having a sound, detailed security >> =A0 =A0section in this FECFRAME framework document is critical >> =A0 =A0since this document is referred by all the WG documents >> =A0 =A0and all of them inherit the framework recommendations. >> =A0 =A0From this point of view, the current security discussion >> =A0 =A0is not satisfying IMHO. >> >> =A0 =A0If we further compare this FECFRAME/framework section >> =A0 =A0to the similar section in the ALC, Flute and NORM RFC >> =A0 =A0(those RMT protocols share some similarities in terms >> =A0 =A0of security requirements), we see major difference in >> =A0 =A0terms of completeness of the discussion. >> >> 2) There is no "Minimum security requirement". More >> =A0 =A0precisely this document does not identify a mandatory >> =A0 =A0to implement (but not necessarily to use) security >> =A0 =A0configuration. I think this also applies here. >> =A0 =A0IPsec/ESP is usually a good solution for that... >> >> >> Additional comments: >> -------------------- >> >> I'm okay with the first two paragraphs. Then: >> >> 3) I'd like to see a discussion which differentiates the >> =A0 =A0various security requirements of interest: >> =A0 =A0 - security WRT the data flow itself, which essentially >> =A0 =A0 =A0 concerns the content provider; >> =A0 =A0 - security WRT the FECFRAME system, which essentially >> =A0 =A0 =A0 concerns the sending and receiving hosts; >> =A0 =A0 - security WRT the network, in the sense "additional >> =A0 =A0 =A0 risks that the use of FECFRAME may create for the >> =A0 =A0 =A0 network", which of course concerns all the hosts; >> =A0 The goal of this section is not to solve all these issues >> =A0 but to highlight the risks, the gradation in the risks, >> =A0 and to give some directions on how to mitigate them (or >> =A0 solve them if feasible). >> >> 4) paragraph 3 has been largely improved compared to >> =A0 =A0previous versions, however I still find the discussion >> =A0 =A0confusing. >> >> =A0 =A0So I suggest another organization: >> =A0 =A0 - if integrity protection is required, using it above >> =A0 =A0 =A0 FECFRAME, at the ADU level, is operational since all >> =A0 =A0 =A0 corrupted ADUs are finally detected as such. But of >> =A0 =A0 =A0 course there are limits (e.g. DoS as already >> =A0 =A0 =A0 explained). >> =A0 =A0 - if integrity protection is required, using it below >> =A0 =A0 =A0 FECFRAME has the advantage of reducing DoS risks. >> =A0 =A0 =A0 This is therefore RECOMMENDED. >> =A0 =A0 - however when applied below FECFRAME, this integrity >> =A0 =A0 =A0 service will not necessarily be end-to-end (depends >> =A0 =A0 =A0 on how FECFRAME is used, end-to-end or not). Whether >> =A0 =A0 =A0 it's appropriate or not depends on whether one can >> =A0 =A0 =A0 tell where the security threats are (which is >> =A0 =A0 =A0 use-case dependent). >> >> =A0 =A0BTW: use the "ADU"/"ADU flow" rather than "source >> =A0 =A0packets" to be in-line with the agreed terminology. >> >> >> 5) paragraph 4: I don't like the discussion here. >> =A0 =A0The same comment on resource waste can be made with >> =A0 =A0non encrypted flows. Concerning the second comment of >> =A0 =A0this paragraph, it's clear that giving a copy of >> =A0 =A0plaintext repair packets to non authorized receivers >> =A0 =A0will lead to problems, but is it so different than >> =A0 =A0giving a copy of plaintext source packets? When we >> =A0 =A0say that confidentiality protection is applied after >> =A0 =A0FEC encoding, this is for instance within IPsec, i.e. >> =A0 =A0all source/repair FEC packets are encrypted. That's >> =A0 =A0the assumption (paragraph 2). >> >> =A0 I suggest to change this discussion as follows: >> =A0 - when ADU flows with different security requirements >> =A0 =A0 need to be FEC protected jointly, then each flow MAY >> =A0 =A0 be processed appropriately before entering FECFRAME >> =A0 =A0 e.g. to encrypt it. >> =A0 =A0 (Note that this is not a MUST. E.g. there are situations >> =A0 =A0 where the only insecure domain is the one over which >> =A0 =A0 FECFRAME operates =3D> =A0this situation may be addressed >> =A0 =A0 with IPsec/ESP, for the whole flow) >> =A0 - it is then REQUIRED that the FECFRAME aggregate flow >> =A0 =A0 be in line with the maximum security requirements of >> =A0 =A0 the individual ADU flows. E.g. if DoS protection is >> =A0 =A0 required, since the use of FECFRAME must not add any >> =A0 =A0 additional threat, an integrity protection must be >> =A0 =A0 provided below FECFRAME. >> =A0 - generally speaking it is often RECOMMENDED to avoid >> =A0 =A0 FEC protecting flows with largely different security >> =A0 =A0 requirements. >> >> >> 6) A note should be added to highlight the fact that >> =A0 =A0attacks targeting the congestion control building block >> =A0 =A0(when applicable) may severely damage the network. A >> =A0 =A0pointer to section 8 should be added. >> >> >> 7) It should be noted that certain security transforms >> =A0 =A0will add some latency to the ADU flow delivery. This >> =A0 =A0latency may need to be considered when dealing with >> =A0 =A0real-time flows. >> >> =A0 =A0NB: I don't think ciphering is an issue, but TESLA >> =A0 =A0authentication/integrity will probably not be >> =A0 =A0appropriate! There are other similar examples. >> >> >> Regards, >> >> =A0 =A0Vincent > From weiler@watson.org Tue Feb 15 18:14:08 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140CE3A6C24 for ; Tue, 15 Feb 2011 18:14:08 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4x46dA3YpV3g for ; Tue, 15 Feb 2011 18:14:07 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 1544A3A6B6F for ; Tue, 15 Feb 2011 18:14:06 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p1G2EW8R023447 for ; Tue, 15 Feb 2011 21:14:33 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p1G2EWCE023444 for ; Tue, 15 Feb 2011 21:14:32 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 15 Feb 2011 21:14:32 -0500 (EST) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 15 Feb 2011 21:14:33 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 02:14:08 -0000 Several of today's new assignments are already scheduled for upcoming telechats, so please check all of the lists below. 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 2011-02-17 Reviewer LC end Draft Dave Cridland T 2011-01-18 draft-ietf-isis-purge-tlv-05 Alan DeKok T 2011-02-23 draft-ietf-isis-reg-purge-00 David McGrew T 2011-02-01 draft-ietf-intarea-shared-addressing-issues-03 Eric Rescorla T 2011-01-07 draft-ietf-pce-inter-layer-req-15 Eric Rescorla T 2011-02-08 draft-mraihi-totp-timebased-07 Stefan Santesson T 2011-02-08 draft-turner-ekpct-algs-update-03 Yaron Sheffer T 2011-02-01 draft-ietf-ccamp-rwa-wson-framework-12 For telechat 2011-03-03 Alan DeKok T 2011-03-01 draft-ietf-hip-over-hip-05 Donald Eastlake T 2011-03-01 draft-ietf-6lowpan-usecases-09 Tobias Gondrom T 2011-03-01 draft-ietf-hip-cert-09 Love Hornquist-Astrand T 2011-02-21 draft-ietf-v6ops-v6-in-mobile-networks-03 Julien Laganier T 2011-02-11 draft-holsten-about-uri-scheme-06 Magnus Nystrom T 2011-02-23 draft-meadors-multiple-attachments-ediint-10 Radia Perlman T 2011-02-08 draft-mraihi-mutual-oath-hotp-variants-13 Tom Yu T 2011-02-22 draft-josefsson-rc4-test-vectors-02 For telechat 2011-03-17 Jeffrey Hutzelman T 2011-03-09 draft-zhu-mobility-survey-03 Last calls and special requests: Rob Austein 2011-02-16 draft-ietf-netconf-rfc4742bis-06 Dave Cridland 2011-02-21 draft-ietf-sidr-arch-11 Shawn Emery 2011-02-21 draft-ietf-ecrit-phonebcp-16 Phillip Hallam-Baker 2011-02-28 draft-ietf-morg-multimailbox-search-06 Steve Hanna 2011-02-21 draft-ietf-pwe3-fc-encap-14 Dan Harkins 2011-02-23 draft-ietf-payload-rfc4695-bis-01 Sam Hartman 2011-02-21 draft-ietf-sidr-res-certs-21 Paul Hoffman 2011-02-21 draft-ietf-sidr-cp-16 Love Hornquist-Astrand 2011-02-01 draft-yevstifeyev-tn3270-uri-16 David McGrew - draft-ietf-ecrit-framework-12 Russ Mundy 2011-01-04 draft-cardona-cablelabs-urn-05 Russ Mundy 2011-02-17 draft-ietf-speermint-voipthreats-07 Vincent Roca 2011-02-07 draft-reed-urn-dgiwg-02 Sam Weiler 2011-02-16 draft-ietf-hokey-ldn-discovery-06 Brian Weis 2011-03-02 draft-herzog-static-ecdh-04 Nico Williams 2011-01-14 draft-yevstifeyev-http-headers-not-recognized-11 Nico Williams 2011-02-09 draft-ietf-rmt-bb-fec-raptorq-04 Glen Zorn 2011-02-10 draft-ietf-shim6-multihome-shim-api-16 From new-work-bounces@ietf.org Wed Feb 16 07:54:05 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCC463A6E14; Wed, 16 Feb 2011 07:54:05 -0800 (PST) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C833A6E14 for ; Wed, 16 Feb 2011 07:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.854 X-Spam-Level: X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjKEyL2H7S59 for ; Wed, 16 Feb 2011 07:54:04 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 3C4263A6D21 for ; Wed, 16 Feb 2011 07:54:03 -0800 (PST) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Ppji3-0008SL-U3; Wed, 16 Feb 2011 10:54:32 -0500 Message-Id: <387A35E7-6309-40D8-893B-22804E076B81@w3.org> From: Ian Jacobs To: new-work@ietf.org Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 16 Feb 2011 09:54:30 -0600 X-Mailer: Apple Mail (2.936) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 16 Feb 2011 10:46:11 -0800 Subject: [secdir] [new-work] Proposed Semantic Web Charters: RDF Web Applications; Provenance (until 2011-03-16) 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, 16 Feb 2011 15:54:05 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Semantic Web Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for a new Provenance Working Group: http://www.w3.org/2011/01/prov-wg-charter.html and one for an RDF Web Applications Working Group, formerly the RDFa WG: http://www.w3.org/2011/01/rdfa-wg-charter.html As part of ensuring that the community is aware of proposed work at W3C, these draft charters are public during the Advisory Committee review period. W3C invites public comments through 2011-03-16 on the proposed charters. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Ivan Herman, Semantic Web Activity Lead . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2001/sw/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From jason_livingood@cable.comcast.com Wed Feb 16 13:08:26 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A0A83A6D43; Wed, 16 Feb 2011 13:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.176 X-Spam-Level: X-Spam-Status: No, score=-103.176 tagged_above=-999 required=5 tests=[AWL=-1.442, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPFbXnkf9I9x; Wed, 16 Feb 2011 13:08:24 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id D01653A6CBA; Wed, 16 Feb 2011 13:08:23 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.26123352; Wed, 16 Feb 2011 14:20:09 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Wed, 16 Feb 2011 16:08:44 -0500 From: "Livingood, Jason" To: Gonzalo Camarillo , "draft-ietf-speermint-architecture@tools.ietf.org" , "mundy@sparta.com" , "secdir@ietf.org" , "iesg@ietf.org" , Jari Arkko , Tim Polk Thread-Topic: secdir Review of draft-ietf-speermint-architecture-17 Thread-Index: AQHLw38Ti5wXZyqtvkmusjO+f6n+PZQEtGuA Date: Wed, 16 Feb 2011 21:08:43 +0000 Message-ID: In-Reply-To: <4D4A6BC6.2090505@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.227.141] Content-Type: multipart/alternative; boundary="_000_C97035A116E27jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 17 Feb 2011 08:45:06 -0800 Subject: Re: [secdir] secdir Review of draft-ietf-speermint-architecture-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 21:08:26 -0000 --_000_C97035A116E27jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UnVzcyAtIFRoYW5rcyBmb3IgcGVyZm9ybWluZyBhIHJldmlldyBvZiB0aGlzIGRvY3VtZW50LiBU aGUgY2hhbmdlcyB5b3UgaGF2ZSBzdWdnZXN0ZWQgd2lsbCBiZSBtYWRlIGluIGEgLTE4IHVwZGF0 ZSB3aGVuIEknbSBjbGVhcmVkIHRvIGRvIHNvIGJ5IG15IEFEIChHb256YWxvKS4gUGxlYXNlIHNl ZSBteSByZXNwb25zZXMgaW5saW5lIGJlbG93IHRvIGVhY2ggc3BlY2lmaWMgaXRlbSBmb3IgdGhl IGRldGFpbHMuDQoNClJlZ2FyZHMNCkphc29uDQoNCi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0tLS0NClN1YmplY3Q6IHNlY2RpciBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1zcGVlcm1pbnQt YXJjaGl0ZWN0dXJlLTE3DQpEYXRlOiBUaHUsIDMgRmViIDIwMTEgMDE6MDY6MjIgKzAxMDANCkZy b206IFJ1c3MgTXVuZHkgPG11bmR5QHNwYXJ0YS5jb208bWFpbHRvOm11bmR5QHNwYXJ0YS5jb20+ Pg0KVG86IHNlY2RpckBpZXRmLm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPiA8c2VjZGlyQGll dGYub3JnPG1haWx0bzpzZWNkaXJAaWV0Zi5vcmc+Pg0KQ0M6IGRyYWZ0LWlldGYtc3BlZXJtaW50 LWFyY2hpdGVjdHVyZS1hbGxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtc3BlZXJt aW50LWFyY2hpdGVjdHVyZS1hbGxAdG9vbHMuaWV0Zi5vcmc+DQo8ZHJhZnQtaWV0Zi1zcGVlcm1p bnQtYXJjaGl0ZWN0dXJlLWFsbEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1zcGVl cm1pbnQtYXJjaGl0ZWN0dXJlLWFsbEB0b29scy5pZXRmLm9yZz4+LCBpZXNnQGlldGYub3JnPG1h aWx0bzppZXNnQGlldGYub3JnPg0KPGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+ PiwgUnVzcyBNdW5keSA8bXVuZHlAc3BhcnRhLmNvbTxtYWlsdG86bXVuZHlAc3BhcnRhLmNvbT4+ DQoNCg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJp dHkgZGlyZWN0b3JhdGUncw0Kb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3Vt ZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuDQpUaGVzZSBjb21tZW50cyB3ZXJlIHdy aXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkNCmFyZWEgZGly ZWN0b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNl DQpjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0KU2lu Y2UgdGhpcyByZXZpZXcgaXMgZm9yIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQsIEkgbmVlZGVk IHRvIHJlZmVyIHRvDQp0aGUgb3RoZXIgZHJhZnRzIGFuZCBSRkNzIGZyb20gdGhlIFdHIHRvIGNv bXBsZXRlIHRoaXMgcmV2aWV3IGFuZCBJIHdhbnQNCnRvIGNvbXBsaW1lbnQgdGhlIHNwZWVybWlu dCBXRyBmb3IgcHJvZHVjaW5nIGEgY29oZXNpdmUgc2V0IG9mIGRvY3VtZW50cy4NCg0KQSBwZXJo YXBzIG1pbm9yIGNyaXRpY2lzbSBpcyB0aGF0IHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgc2Vl bXMgdG8NCmhhdmUgYSBuYXJyb3dlciB0ZWNobm9sb2d5IGZvY3VzIHRoYW4gb3RoZXIgZG9jdW1l bnRzIHRoYXQgYXJlIG5vcm1hdGl2ZQ0KcmVmZXJlbmNlcywgZS5nLiwgdm9pcHRocmVhdHMsIHVz ZWNhc2VzLCByZXF1aXJlbWVudHMuICBQYXJ0aWN1bGFybHkNCmFmdGVyIHRyeWluZyB0byBkZXRl cm1pbmUgdGhlIGJhc2ljIGludGVudCBvZiB0aGUgU2VjdXJpdHkNCkNvbnNpZGVyYXRpb25zIHNl Y3Rpb24gKDkpLCBpdCBhcHBlYXJzIGFzIHRob3VnaCB0aGlzIGFyY2hpdGVjdHVyZQ0KZG9jdW1l bnQgaXMgZm9jdXNlZCBvbiBqdXN0IHRoZSBpbnRlcmNvbm5lY3Rpb24gYmV0d2VlbiB0d28gU0lQ IFNlcnZpY2UNClByb3ZpZGVycyAoU1NQKSB3aGlsZSBzb21lIG9mIHRoZSBub3JtYXRpdmUgcmVm ZXJlbmNlcyBwcm92aWRlIG11Y2ggbW9yZQ0Kb2YgYW4gZW5kLXRvLWVuZCBkZXNjcmlwdGlvbiBv ZiB0aGUgdGVjaG5vbG9neS4gU2luY2UgdGhpcyBkb2N1bWVudCBoYXMNCiJhcmNoaXRlY3R1cmUi IGluIGl0J3MgbmFtZSBidXQgYSBzb21ld2hhdCBuYXJyb3dlciB0ZWNobm9sb2d5IHNjb3BlDQp0 aGFuIHNvbWUgb2YgaXQncyBub3JtYXRpdmUgcmVmZXJlbmNlcywgaXQgd291bGQgc2VlbSB0byBi ZSB1c2VmdWwgdG8NCmNsZWFybHkgc3RhdGUgdGhpcyBpbiB0aGUgaW50cm9kdWN0aW9uIChvciBl bHNld2hlcmUpIGluIHRoZSBkb2N1bWVudC4NCg0KU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc3Bl Y2lmaWMgY29tbWVudHM6IEkgZG8gaGF2ZSBjb25jZXJucyB3aXRoIHRoZQ0Kc3BlY2lmaWNzIG9m IHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLCBpbiBwYXJ0aWN1bGFyLCBJIGRv bid0DQpyZWFsbHkgdW5kZXJzdGFuZCB0aGUgYmFzaWMgaW50ZW50IG9mIHdoYXQgdGhlIHR3byBt YWluIHBhcmFncmFwaHMgYXJlDQp0cnlpbmcgdG8gc2F5Lg0KDQotIFRoZSBiYXNpYyBtZWFuaW5n IG9mIHdoZW4gZW5jcnlwdGlvbiBzaG91bGQgYmUgdXNlZCBpbiB0aGUgZmlyc3QNCnBhcmFncmFw aCBpcyBhd2t3YXJkIGFuZCBub3QgY2xlYXIgKHBlcmhhcHMgaXQncyBhIGNvbXByb21pc2Ugd29y ZGluZw0KZnJvbSB0aGUgV0cgYnV0IHRoYXQgd29uJ3QgbWF0dGVyIGxhdGVyKSAtIEkgY2FuIHJl YWQgdGhlIHdvcmRpbmcNCnNldmVyYWwgZGlmZmVyZW50IHdheXMgd2hpY2ggd291bGQgcmVzdWx0 IGluIHZlcnkgZGlmZmVyZW50IGluZmVyZW5jZXMNCmFib3V0IHdoZW4gY3J5cHRvZ3JhcGh5IHNo b3VsZCBhY3R1YWxseSBiZSB1c2VkLCBlLmcuLDoNCg0KLSAtICJjcnlwdG9ncmFwaGljLWJhc2Vk IHNlY3VyaXR5IiBzaG91bGQgYmUgdXNlZCBmb3IgYWxsIGNhc2VzIHVubGVzcw0KdGhlIGNvbm5l Y3Rpb24gaXMgcHJvdGVjdGVkIGJ5IHBoeXNpY2FsIHNlY3VyaXR5Ow0KDQotIC0gaWYgdGhlcmUg aXMgbm90IHBoeXNpY2FsIHNlY3VyaXR5IGJldHdlZW4gdGhlIHBlZXJpbmcgcHJvdmlkZXJzLCB0 aGUNCnVzZSBvZiAiY3J5cHRvZ3JhcGhpYy1iYXNlZCBzZWN1cml0eSIgaXMgc3VnZ2VzdGVkL3Jl Y29tbWVuZGVkOw0KDQotIC0gdXNlIG9mICJjcnlwdG9ncmFwaGljLWJhc2VkIHNlY3VyaXR5IiBp cyBvcHRpb25hbCBpbiBhbGwgc2l0dWF0aW9uczsNCg0KLSAtIGludGVuZGVkIHVzZSBvZiAiY3J5 cHRvZ3JhcGhpYy1iYXNlZCBzZWN1cml0eSIgaXMgZGlmZmVyZW50IHRoYW4gYW55DQpvZiB0aGUg YWJvdmUuDQoNClN1Z2dlc3RlZCBzb2x1dGlvbjogSXQgc2VlbXMgdG8gbWUgbGlrZSB0aGVyZSBz aG91bGQgYmUgc29tZSBzcGVjaWZpYw0KcmVmZXJlbmNlcyB0byB0aGUgYXBwcm9wcmlhdGUgc2Vj dGlvbnMgb2YgdGhlIHZvaXB0aHJlYXRzICYgcmVxdWlyZW1lbnRzDQpkb2N1bWVudHMgLSB0aGlz IHNob3VsZCBub3QgYmUgYSBwcm9ibGVtIHNpbmNlIHRoZXkgYXJlIG5vcm1hdGl2ZQ0KcmVmZXJl bmNlcyBhbmQgd2lsbCBuZWVkIHRvIGJlIHB1Ymxpc2hlZCBtb3JlIG9yIGxlc3MgYXQgdGhlIHNh bWUgdGltZS4NCg0KW0pMXSBJIGNhbiBzZWUgaG93IHRoaXMgaXMgdGhlIGNhc2UuIEJhc2VkIG9u IHlvdXIgZmVlZGJhY2ssIEkgcGxhbiB0byBjaGFuZ2UgaXQgdG8gdGhpczoNCjEwLiAgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMNCg0KVGhlIGxldmVsIChvciB0eXBlcykgb2Ygc2VjdXJpdHkgbWVj aGFuaXNtcyBpbXBsZW1lbnRlZCBiZXR3ZWVuIHBlZXJpbmcgcHJvdmlkZXJzIGlzIGluIHByYWN0 aWNlIGRlcGVuZGVudCB1cG9uIG9uIHRoZSB1bmRlcmx5aW5nIHBoeXNpY2FsIHNlY3VyaXR5IG9m IFNTUCBjb25uZWN0aW9ucy4gVGhpcyBtZWFucywgYXMgbm90ZWQgaW4gU2VjdGlvbiA2LjEuMy4z PGh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL2NnaS1iaW4veG1sMnJmYy5jZ2kjQ28tTG9jYXRpb24+ LCB3aGV0aGVyIHBlZXJpbmcgZXF1aXBtZW50IGlzIGluIGEgc2VjdXJlIGZhY2lsaXR5IG9yIG5v dCBtYXkgYmVhciBvbiBvdGhlciB0eXBlcyBvZiBzZWN1cml0eSBtZWNoYW5pc21zIHdoaWNoIG1h eSBiZSBhcHByb3ByaWF0ZS4gVGh1cywgaWYgdHdvIFNTUHMgcGVlcmVkIGFjcm9zcyBwdWJsaWMg SW50ZXJuZXQgbGlua3MsIHRoZXkgYXJlIGxpa2VseSB0byB1c2UgSVBTZWMgb3IgVExTIHNpbmNl IHRoZSBsaW5rIGJldHdlZW4gdGhlIHR3byBkb21haW5zIHNob3VsZCBiZSBjb25zaWRlcmVkIHVu dHJ1c3RlZC4NCg0KTWFueSBkZXRhaWxlZCBhbmQgaGlnaGx5IHJlbGV2YW50IHNlY3VyaXR5IHJl cXVpcmVtZW50cyBmb3IgU1BFRVJNSU5UIGhhdmUgYmVlbiBkb2N1bWVudGVkIGluIFNlY3Rpb24g NSBvZiBbSeKAkUQuaWV0ZuKAkXNwZWVybWludOKAkXJlcXVpcmVtZW50c108aHR0cDovL3htbC5y ZXNvdXJjZS5vcmcvY2dpLWJpbi94bWwycmZjLmNnaSNJLUQuaWV0Zi1zcGVlcm1pbnQtcmVxdWly ZW1lbnRzPi4gQXMgYSByZXN1bHQsIHRoYXQgZG9jdW1lbnQgc2hvdWxkIGJlIGNvbnNpZGVyZWQg cmVxdWlyZWQgcmVhZGluZy4NCg0KQWRkaXRpb25hbCBhbmQgaW1wb3J0YW50IHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIGhhdmUgYmVlbiBkb2N1bWVudGVkIHNlcGFyYXRlbHkgaW4gW0nigJFELmll dGbigJFzcGVlcm1pbnTigJF2b2lwdGhyZWF0c108aHR0cDovL3htbC5yZXNvdXJjZS5vcmcvY2dp LWJpbi94bWwycmZjLmNnaSNJLUQuaWV0Zi1zcGVlcm1pbnQtdm9pcHRocmVhdHM+LiBUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyB0aGUgbWFueSByZWxldmFudCBzZWN1cml0eSB0aHJlYXRzIHRvIFNQ RUVSTUlOVCwgYXMgd2VsbCB0aGUgcmVsZXZhbnQgY291bnRlcm1lYXN1cmVzIGFuZCBzZWN1cml0 eSBwcm90ZWN0aW9ucyB3aGljaCBhcmUgcmVjb21tZW5kZWQgdG8gY29tYmF0IGFueSBwb3RlbnRp YWwgdGhyZWF0cyBvciBvdGhlciByaXNrcy4gVGhpcyBpbmNsdWRlcyBhIHdpZGUgcmFuZ2Ugb2Yg ZGV0YWlsZWQgdGhyZWF0cyBpbiBTZWN0aW9uIDIgb2YgW0nigJFELmlldGbigJFzcGVlcm1pbnTi gJF2b2lwdGhyZWF0c108aHR0cDovL3htbC5yZXNvdXJjZS5vcmcvY2dpLWJpbi94bWwycmZjLmNn aSNJLUQuaWV0Zi1zcGVlcm1pbnQtdm9pcHRocmVhdHM+LiBJdCBhbHNvIGluY2x1ZGVzIGtleSBy ZXF1aXJlbWVudHMgaW4gU2VjdGlvbiAzLjEgb2ZbSeKAkUQuaWV0ZuKAkXNwZWVybWludOKAkXZv aXB0aHJlYXRzXTxodHRwOi8veG1sLnJlc291cmNlLm9yZy9jZ2ktYmluL3htbDJyZmMuY2dpI0kt RC5pZXRmLXNwZWVybWludC12b2lwdGhyZWF0cz4sIHN1Y2ggYXMgdGhlIHJlcXVpcmVtZW50IGZv ciB0aGUgTFVGIGFuZCBMUkYgdG8gc3VwcG9ydCBtdXR1YWwgYXV0aGVudGljYXRpb24gZm9yIHF1 ZXJpZXMsIGFtb25nIG90aGVyIHJlcXVpcmVtZW50cyB3aGljaCBhcmUgcmVsYXRlZCB0byBbSeKA kUQuaWV0ZuKAkXNwZWVybWludOKAkXJlcXVpcmVtZW50c108aHR0cDovL3htbC5yZXNvdXJjZS5v cmcvY2dpLWJpbi94bWwycmZjLmNnaSNJLUQuaWV0Zi1zcGVlcm1pbnQtcmVxdWlyZW1lbnRzPi4g U2VjdGlvbiAzLjIgb2YgW0nigJFELmlldGbigJFzcGVlcm1pbnTigJF2b2lwdGhyZWF0c108aHR0 cDovL3htbC5yZXNvdXJjZS5vcmcvY2dpLWJpbi94bWwycmZjLmNnaSNJLUQuaWV0Zi1zcGVlcm1p bnQtdm9pcHRocmVhdHM+IGV4cGxhaW5zIGhvdyB0byBtZWV0IHRoZXNlIHNlY3VyaXR5IHJlcXVp cmVtZW50cywgYW5kIHRoZW4gU2VjdGlvbiA0IGV4cGxvcmVzIGEgd2lkZSByYW5nZSBvZiBzdWdn ZXN0ZWQgY291bnRlcm1lYXN1cmVzLg0KDQotIFRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mIHRoZSBz ZWN0aW9uIHNlZW1zIHRvIGJlIHNheWluZyB0aGF0IHRoZSBXRw0KYmVsaWV2ZXMgdGhhdCBhZGRp dGlvbmFsIG1ldGhvZHMgb2YgcGVlcmluZyBuZWVkIHRvIGJlIHN0YW5kYXJkaXplZA0KKHdoaWNo IHNlZW1zIGZpbmUpIGJ1dCBpdCdzIHJhdGhlciB1bmNsZWFyIHdoYXQgdGhlICJtYWludGFpbiBh DQpjb25zaXN0ZW50IGFwcHJvYWNoIiBpcyBzdXBwb3NlZCB0byBiZSBjb25zaXN0ZW50IHdpdGgg ZXNwZWNpYWxseSBzaW5jZQ0KdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBvZiB0aGUgcHJldmlv dXMgcGFyYWdyYXBoIGFyZSB1bmNsZWFyLg0KDQpTdWdnZXN0ZWQgc29sdXRpb246IElmIGNsZWFy IGFuZCByZWFzb25hYmx5IHNwZWNpZmljIHJlcXVpcmVtZW50cyBjYW4gYmUNCmlkZW50aWZpZWQg Zm9yIHRoZSBwcmV2aW91cyBwYXJhZ3JhcGggdGhlbiBpdCBzZWVtcyBsaWtlIHRoZXNlIChvcg0K ZXF1aXZhbGVudCByZXF1aXJlbWVudHMpIGNhbiBiZSBhcHBsaWVkIHRvIGZ1dHVyZSBzdGFuZGFy ZHMgZm9yIHBlZXJpbmcuDQoNCltKTF0gVGhhdCBzZWVtcyB0byBoYXZlIGJlZW4gb2xkIHRleHQg YXJndWluZyBmb3IgYSBzZXBhcmF0ZSBzZWN1cml0eSB0aHJlYXRzIGRvY3VtZW50LCB3aGljaCB3 ZSBub3cgaGF2ZSwgc28gSSByZW1vdmVkIGl0IGFzIHdyaXR0ZW4gYWJvdmUuDQoNCk90aGVyIChi YXNpY2FsbHkgZWRpdG9yaWFsKSBDb21tZW50czoNCg0KLSBJbiBTZWN0aW9uIDQsIHRoZSB0ZXJt ICJTZXNzaW9uIEJvcmRlciBDb250cm9sbGVyIiBpcyBub3QgZGVmaW5lZCBpbg0KUkZDNTQ4NiBv ciB0aGlzIGRvY3VtZW50IC0gaXQgc2VlbXMgbGlrZSBhIGRlZmluaXRpb24gc2hvdWxkIGJlIGlu Y2x1ZGVkLg0KDQpbSkxdIEFub3RoZXIgcmV2aWV3ZXIgbWFkZSB0aGUgc2FtZSBwb2ludCwgc28g d2UgY3JlYXRlZCBhIG5ldyBzZWN0aW9uIDIgb24gdGVybWlub2xvZ3kuIFdlIGFkZHJlc3MgdGhp cyBub3c6DQoNCjIuMS4gIFNlc3Npb24gQm9yZGVyIENvbnRyb2xsZXIgKFNCQykNCkEgU2Vzc2lv biBCb3JkZXIgQ29udHJvbGxlciAoU0JDKSBpcyByZWZlcnJlZCB0byBpbiBTZWN0aW9uIDU8aHR0 cDovL3htbC5yZXNvdXJjZS5vcmcvY2dpLWJpbi94bWwycmZjLmNnaSNSZWxhdGlvbnNoaXBzJTIw QmV0d2VlbiUyMEZ1bmN0aW9ucy9FbGVtZW50cz4uIEFuIFNCQyBjYW4gY29udGFpbiBhIFNpZ25h bGluZyBGdW5jdGlvbiAoU0YpLCBTaWduYWxpbmcgUGF0aCBCb3JkZXIgRWxlbWVudCAoU0JFKSBh bmQgRGF0YSBQYXRoIEJvcmRlciBFbGVtZW50IChEQkUpLCBhbmQgbWF5IHBlcmZvcm0gdGhlIExv b2stVXAgRnVuY3Rpb24gKExVRikgYW5kIExvY2F0aW9uIFJvdXRpbmcgRnVuY3Rpb24gKExSRikg ZnVuY3Rpb25zLCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzPGh0dHA6Ly94bWwucmVzb3VyY2Uu b3JnL2NnaS1iaW4veG1sMnJmYy5jZ2kjUmVmZXJlbmNlJTIwQXJjaGl0ZWN0dXJlPi4gV2hldGhl ciB0aGUgU0JDIHBlcmZvcm1zIG9uZSBvciBtb3JlIG9mIHRoZXNlIGZ1bmN0aW9ucyBpcyBnZW5l cmFsbHkgc3BlYWtpbmcgZGVwZW5kZW50IHVwb24gaG93IGEgU0lQIFNlcnZpY2UgUHJvdmlkZXIg KFNTUCkgY29uZmlndXJlcyBzdWNoIGEgbmV0d29yayBlbGVtZW50LiBJbiBhZGRpdGlvbiwgcmVx dWlyZW1lbnRzIGZvciBhbiBTQkMgY2FuIGJlIGZvdW5kIGluIFtSRkM1ODUzXTxodHRwOi8veG1s LnJlc291cmNlLm9yZy9jZ2ktYmluL3htbDJyZmMuY2dpI1JGQzU4NTM+Lg0KDQotIEluIFNlY3Rp b24gNCwgdGhlIGZpcnN0IHRocmVlIGJ1bGxldCBwb2ludHMgd291bGQgaGF2ZSAiZnVuY3Rpb24N CmZ1bmN0aW9uIiBpZiB0aGUgYWNyb255bXMgd2VyZSBzcGVsbGVkIG91dCAtIHRoaXMgbWlnaHQg YmUgb2theSBidXQgc29tZQ0KcGVvcGxlIHZpZXcgaXQgYXMgaW5jb3JyZWN0Lg0KDQpbSkxdIEFs cmVhZHkgZml4ZWQuIEl0IG5vdyByZWFkczoNCjUuICBSZWxhdGlvbnNoaXBzIEJldHdlZW4gRnVu Y3Rpb25zL0VsZW1lbnRzDQoNClBsZWFzZSBhbHNvIHJlZmVyIHRvIEZpZ3VyZSAxPGh0dHA6Ly94 bWwucmVzb3VyY2Uub3JnL2NnaS1iaW4veG1sMnJmYy5jZ2kjcmVmX2FyYz4uDQoNCiAgKiAgIEFu IFNCRSBjYW4gY29udGFpbiBhIFNpZ25hbGluZyBGdW5jdGlvbiAoU0YpLg0KICAqICAgQW4gU0Yg Y2FuIHBlcmZvcm0gYSBMb29rLVVwIEZ1bmN0aW9uIChMVUYpIGFuZCBMb2NhdGlvbiBSb3V0aW5n IEZ1bmN0aW9uIChMUkYpLg0KICAqICAgQXMgYW4gYWRkaXRpb25hbCBjb25zaWRlcmF0aW9uLCBh IFNlc3Npb24gQm9yZGVyIENvbnRyb2xsZXIsIGNhbiBjb250YWluIGFuIFNGLCBTQkUgYW5kIERC RSwgYW5kIG1heSBhY3QgYXMgYm90aCBhbiBMVUYgYW5kIExSRi4NCiAgKiAgIFRoZSBmb2xsb3dp bmcgZnVuY3Rpb25zIG1heSBjb21tdW5pY2F0ZSBhcyBmb2xsb3dzIGluIGFuIGV4YW1wbGUgU1NQ IG5ldHdvcmssIGRlcGVuZGluZyB1cG9uIHZhcmlvdXMgcmVhbC13b3JsZCBpbXBsZW1lbnRhdGlv bnM6DQogICAgICogICBTRiBtYXkgY29tbXVuaWNhdGUgd2l0aCBMVUYsIExSRiwgU0JFIGFuZCBT Rg0KICAgICAqICAgTFVGIG1heSBjb21tdW5pY2F0ZSB3aXRoIFNGIGFuZCBTQkUNCiAgICAgKiAg IExSRiBtYXkgY29tbXVuaWNhdGUgd2l0aCBTRiBhbmQgU0JFDQoNCi0gSW4gdGhlIGZvdXJ0aCBi dWxsZXQgb2YgU2VjdGlvbiA0LCBpdCdzIG5vdCBjbGVhciB3aGF0ICJjYW4NCmNvbW11bmljYXRl IiBtZWFucyAtIGlzIHRoaXMgYSByZXN0cmljdGl2ZSBzdGF0ZW1lbnQsIGRvZXMgaXQgbWVhbiB0 aGF0DQpvbmx5IHRoZSBsZWZ0LW1vc3QgZnVuY3Rpb24gY2FuIGluaXRpYXRlIGFuIGV4Y2hhbmdl IG9yIHNvbWV0aGluZyBlbHNlDQphbHRvZ2V0aGVyLiAgSXQgc2VlbXMgbGlrZSBhIGNsYXJpZmlj YXRpb24gaXMgaW4gb3JkZXIuDQoNCltKTF0gQ2xhcmlmaWVkIGFib3ZlDQoNCi0gSW4gU2VjdGlv biA1LjEuMi4yLCB0aGUgdGVybSAiY2Fycmllci1vZi1yZWNvcmQiIGlzIHVzZWQuICBUaGUgdGVy bSBpcw0Kbm90IGRlZmluZWQgb3IgdXNlZCBlbHNld2hlcmUgYW5kIHNlZW1zIHRvIGJlIGltcG9y dGFudCB0byB0aGUgcHJvcGVyDQpmdW5jdGlvbmluZyBvZiB0aGUgcHJvY2VkdXJlLiAgQSBjbGFy aWZpY2F0aW9uIHdvdWxkIHNlZW0gdG8gYmUgaW4gb3JkZXIuDQoNCltKTF0gQWdyZWUsIGFuZCB3 ZSBhbHNvIGFkZGVkIHRoaXMgdG8gdGhlIG5ldyB0ZXJtaW5vbG9neSBzZWN0aW9uOg0KMi4yLiAg Q2Fycmllci1vZi1SZWNvcmQNCg0KQSBjYXJyaWVyLW9mLXJlY29yZCwgYXMgdXNlZCBpbiBTZWN0 aW9uIDYuMS4yLjI8aHR0cDovL3htbC5yZXNvdXJjZS5vcmcvY2dpLWJpbi94bWwycmZjLmNnaSNS b3V0aW5nJTIwVGFibGU+LCBpcyBkZWZpbmVkIGluIFtSRkM1MDY3XTxodHRwOi8veG1sLnJlc291 cmNlLm9yZy9jZ2ktYmluL3htbDJyZmMuY2dpI1JGQzUwNjc+LiBUaGF0IGRvY3VtZW50IGRlc2Ny aWJlcyB0aGUgdGVybSB0byByZWZlciB0byB0aGUgZW50aXR5IGhhdmluZyBkaXNjcmV0aW9uIG92 ZXIgdGhlIGRvbWFpbiBhbmQgem9uZSBjb250ZW50IGFuZCBhY3RpbmcgYXMgdGhlIHJlZ2lzdHJh bnQgZm9yIGEgdGVsZXBob25lIG51bWJlciwgYXMgcmVwcmVzZW50ZWQgaW4gRU5VTS4gVGhpcyBj YW4gYmU6DQoNCiAgKiAgIHRoZSBTZXJ2aWNlIFByb3ZpZGVyIHRvIHdoaWNoIHRoZSBFLjE2NCBu dW1iZXIgd2FzIGFsbG9jYXRlZCBmb3IgZW5kIHVzZXIgYXNzaWdubWVudCwgd2hldGhlciBieSB0 aGUgTmF0aW9uYWwgUmVndWxhdG9yeSBBdXRob3JpdHkgKE5SQSkgb3IgdGhlIEludGVybmF0aW9u YWwgVGVsZWNvbW11bmljYXRpb24gVW5pb24gKElUVSksIGZvciBpbnN0YW5jZSwgYSBjb2RlIHVu ZGVyICJJbnRlcm5hdGlvbmFsIE5ldHdvcmtzIiAoKzg4Mikgb3IgIlVuaXZlcnNhbCBQZXJzb25h bCBUZWxlY29tbXVuaWNhdGlvbnMgKFVQVCkiICgrODc4KSBvciwNCiAgKiAgIGlmIHRoZSBudW1i ZXIgaXMgcG9ydGVkLCB0aGUgc2VydmljZSBwcm92aWRlciB0byB3aGljaCB0aGUgbnVtYmVyIHdh cyBwb3J0ZWQsIG9yDQogICogICB3aGVyZSBudW1iZXJzIGFyZSBhc3NpZ25lZCBkaXJlY3RseSB0 byBlbmQgdXNlcnMsIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIHRoYXQgdGhlIGVuZCB1c2VyIG51bWJl ciBhc3NpZ25lZSBoYXMgY2hvc2VuIHRvIHByb3ZpZGUgYSBQdWJsaWMgU3dpdGNoZWQgVGVsZXBo b25lIE5ldHdvcmsvUHVibGljIExhbmQgTW9iaWxlIE5ldHdvcmsgKFBTVE4vIFBMTU4pIHBvaW50 LW9mLWludGVyY29ubmVjdCBmb3IgdGhlIG51bWJlci4NCg0KSXQgaXMgdW5kZXJzdG9vZCB0aGF0 IHRoZSBkZWZpbml0aW9uIG9mIGNhcnJpZXItb2YtcmVjb3JkIHdpdGhpbiBhIGdpdmVuIGp1cmlz ZGljdGlvbiBpcyBzdWJqZWN0IHRvIG1vZGlmaWNhdGlvbiBieSBuYXRpb25hbCBhdXRob3JpdGll cy4NCg0KLSBJbiBTZWN0aW9uIDUuMS4zLjIsIElQU2VjIGlzIG1lbnRpb25lZCBpbiB0aGUgb3Jp Z2luYXRpbmcgcHJvY2VkdXJlcy4NClRoZXJlIGlzIG5vIGNvcnJlc3BvbmRpbmcgbWVudGlvbiBp biB0aGUgdGFyZ2V0IHByb2NlZHVyZXMgc2VjdGlvbg0Kd2hpY2ggc2VlbXMgdG8gYmUgYW4gb21p c3Npb24gdGhhdCBzaG91bGQgYmUgY29ycmVjdGVkLg0KDQpbSkxdIFl1cC4gIFdlIGFkZGVkIGEg bGluZSB0byB0aGUgcmVsZXZhbnQgc2VjdGlvbiB0byBhZGRyZXNzIHRoaXMgYW5kIHJlZmVyIGJh Y2sgdG8gdGhlIElQU2VjIHNlY3Rpb24uDQoNCjYuMi4xLiAgVExTDQoNClRoZSBzZWN0aW9uIGRl ZmluZXMgdGhlIHVzYWdlIG9mIFRMUyBiZXR3ZWVuIHR3byBTU1BzIFtSRkM1MjQ2XTxodHRwOi8v eG1sLnJlc291cmNlLm9yZy9jZ2ktYmluL3htbDJyZmMuY2dpI1JGQzUyNDY+IFtSRkM1NzQ2XTxo dHRwOi8veG1sLnJlc291cmNlLm9yZy9jZ2ktYmluL3htbDJyZmMuY2dpI1JGQzU3NDY+IFtSRkM1 ODc4XTxodHRwOi8veG1sLnJlc291cmNlLm9yZy9jZ2ktYmluL3htbDJyZmMuY2dpI1JGQzU4Nzg+ LiBXaGVuIHRoZSByZWNlaXZpbmcgU1NQIHJlY2VpdmVzIGEgVExTIGNsaWVudCBoZWxsbywgaXQg cmVzcG9uZHMgd2l0aCBpdHMgY2VydGlmaWNhdGUuIFRoZSBUYXJnZXQgU1NQIGNlcnRpZmljYXRl IHNob3VsZCBiZSB2YWxpZCBhbmQgcm9vdGVkIGluIGEgd2VsbC1rbm93biBjZXJ0aWZpY2F0ZSBh dXRob3JpdHkuIFRoZSBwcm9jZWR1cmVzIHRvIGF1dGhlbnRpY2F0ZSB0aGUgU1NQJ3Mgb3JpZ2lu YXRpbmcgZG9tYWluIGFyZSBzcGVjaWZpZWQgaW4gW1JGQzU5MjJdPGh0dHA6Ly94bWwucmVzb3Vy Y2Uub3JnL2NnaS1iaW4veG1sMnJmYy5jZ2kjUkZDNTkyMj4uDQoNClRoZSBTRiBvZiB0aGUgVGFy Z2V0IFNTUCB2ZXJpZmllcyB0aGF0IHRoZSBJZGVudGl0eSBoZWFkZXIgaXMgdmFsaWQsIGNvcnJl c3BvbmRzIHRvIHRoZSBtZXNzYWdlLCBjb3JyZXNwb25kcyB0byB0aGUgSWRlbnRpdHktSW5mbyBo ZWFkZXIsIGFuZCB0aGF0IHRoZSBkb21haW4gaW4gdGhlIEZyb20gaGVhZGVyIGNvcnJlc3BvbmRz IHRvIG9uZSBvZiB0aGUgZG9tYWlucyBpbiB0aGUgVExTIGNsaWVudCBjZXJ0aWZpY2F0ZS4NCg0K QXMgbm90ZWQgYWJvdmUgaW4gU2VjdGlvbiA2LjEuMy4yPGh0dHA6Ly94bWwucmVzb3VyY2Uub3Jn L2NnaS1iaW4veG1sMnJmYy5jZ2kjSVBTZWM+LCBzb21lIGRlcGxveW1lbnRzIG1heSB1dGlsaXpl IElQU2VjIHJhdGhlciB0aGFuIFRMUy4NCg0KDQoNClJ1c3MgTXVuZHkNCg0KDQoNCg0K --_000_C97035A116E27jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: <332185B955AD4E4BB6E37EC3B52EC46F@cable.comcast.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE2cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsg LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxkaXY+DQo8ZGl2PlJ1 c3MgLSBUaGFua3MgZm9yIHBlcmZvcm1pbmcgYSByZXZpZXcgb2YgdGhpcyBkb2N1bWVudC4gVGhl IGNoYW5nZXMgeW91IGhhdmUgc3VnZ2VzdGVkIHdpbGwgYmUgbWFkZSBpbiBhIC0xOCB1cGRhdGUg d2hlbiBJJ20gY2xlYXJlZCB0byBkbyBzbyBieSBteSBBRCAoR29uemFsbykuIFBsZWFzZSBzZWUg bXkgcmVzcG9uc2VzIGlubGluZSBiZWxvdyB0byBlYWNoIHNwZWNpZmljIGl0ZW0gZm9yIHRoZSBk ZXRhaWxzLjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzPC9k aXY+DQo8ZGl2Pkphc29uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9 Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDog I2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2 Pi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS08L2Rpdj4NCjxkaXY+U3ViamVjdDog c2VjZGlyIFJldmlldyBvZiBkcmFmdC1pZXRmLXNwZWVybWludC1hcmNoaXRlY3R1cmUtMTc8L2Rp dj4NCjxkaXY+RGF0ZTogVGh1LCAzIEZlYiAyMDExIDAxOjA2OjIyICYjNDM7MDEwMDwvZGl2Pg0K PGRpdj5Gcm9tOiBSdXNzIE11bmR5ICZsdDs8YSBocmVmPSJtYWlsdG86bXVuZHlAc3BhcnRhLmNv bSI+bXVuZHlAc3BhcnRhLmNvbTwvYT4mZ3Q7PC9kaXY+DQo8ZGl2PlRvOiA8YSBocmVmPSJtYWls dG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWls dG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8L2E+Jmd0OzwvZGl2Pg0KPGRpdj5D QzogPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtc3BlZXJtaW50LWFyY2hpdGVjdHVyZS1hbGxA dG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtc3BlZXJtaW50LWFyY2hpdGVjdHVyZS1hbGxAdG9v bHMuaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2PiZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0 Zi1zcGVlcm1pbnQtYXJjaGl0ZWN0dXJlLWFsbEB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1z cGVlcm1pbnQtYXJjaGl0ZWN0dXJlLWFsbEB0b29scy5pZXRmLm9yZzwvYT4mZ3Q7LA0KPGEgaHJl Zj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciPmllc2dAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2PiZs dDs8YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyI+aWVzZ0BpZXRmLm9yZzwvYT4mZ3Q7LCBS dXNzIE11bmR5ICZsdDs8YSBocmVmPSJtYWlsdG86bXVuZHlAc3BhcnRhLmNvbSI+bXVuZHlAc3Bh cnRhLmNvbTwvYT4mZ3Q7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2Vj dXJpdHkgZGlyZWN0b3JhdGUnczwvZGl2Pg0KPGRpdj5vbmdvaW5nIGVmZm9ydCB0byByZXZpZXcg YWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy48L2Rpdj4NCjxk aXY+VGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQg b2YgdGhlIHNlY3VyaXR5PC9kaXY+DQo8ZGl2PmFyZWEgZGlyZWN0b3JzLiBEb2N1bWVudCBlZGl0 b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlPC9kaXY+DQo8ZGl2PmNvbW1lbnRz IGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+U2luY2UgdGhpcyByZXZpZXcgaXMgZm9yIHRoZSBhcmNoaXRlY3R1cmUg ZG9jdW1lbnQsIEkgbmVlZGVkIHRvIHJlZmVyIHRvPC9kaXY+DQo8ZGl2PnRoZSBvdGhlciBkcmFm dHMgYW5kIFJGQ3MgZnJvbSB0aGUgV0cgdG8gY29tcGxldGUgdGhpcyByZXZpZXcgYW5kIEkgd2Fu dDwvZGl2Pg0KPGRpdj50byBjb21wbGltZW50IHRoZSBzcGVlcm1pbnQgV0cgZm9yIHByb2R1Y2lu ZyBhIGNvaGVzaXZlIHNldCBvZiBkb2N1bWVudHMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5BIHBlcmhhcHMgbWlub3IgY3JpdGljaXNtIGlzIHRoYXQgdGhlIGFyY2hpdGVjdHVyZSBk b2N1bWVudCBzZWVtcyB0bzwvZGl2Pg0KPGRpdj5oYXZlIGEgbmFycm93ZXIgdGVjaG5vbG9neSBm b2N1cyB0aGFuIG90aGVyIGRvY3VtZW50cyB0aGF0IGFyZSBub3JtYXRpdmU8L2Rpdj4NCjxkaXY+ cmVmZXJlbmNlcywgZS5nLiwgdm9pcHRocmVhdHMsIHVzZWNhc2VzLCByZXF1aXJlbWVudHMuJm5i c3A7Jm5ic3A7UGFydGljdWxhcmx5PC9kaXY+DQo8ZGl2PmFmdGVyIHRyeWluZyB0byBkZXRlcm1p bmUgdGhlIGJhc2ljIGludGVudCBvZiB0aGUgU2VjdXJpdHk8L2Rpdj4NCjxkaXY+Q29uc2lkZXJh dGlvbnMgc2VjdGlvbiAoOSksIGl0IGFwcGVhcnMgYXMgdGhvdWdoIHRoaXMgYXJjaGl0ZWN0dXJl PC9kaXY+DQo8ZGl2PmRvY3VtZW50IGlzIGZvY3VzZWQgb24ganVzdCB0aGUgaW50ZXJjb25uZWN0 aW9uIGJldHdlZW4gdHdvIFNJUCBTZXJ2aWNlPC9kaXY+DQo8ZGl2PlByb3ZpZGVycyAoU1NQKSB3 aGlsZSBzb21lIG9mIHRoZSBub3JtYXRpdmUgcmVmZXJlbmNlcyBwcm92aWRlIG11Y2ggbW9yZTwv ZGl2Pg0KPGRpdj5vZiBhbiBlbmQtdG8tZW5kIGRlc2NyaXB0aW9uIG9mIHRoZSB0ZWNobm9sb2d5 LiBTaW5jZSB0aGlzIGRvY3VtZW50IGhhczwvZGl2Pg0KPGRpdj4mcXVvdDthcmNoaXRlY3R1cmUm cXVvdDsgaW4gaXQncyBuYW1lIGJ1dCBhIHNvbWV3aGF0IG5hcnJvd2VyIHRlY2hub2xvZ3kgc2Nv cGU8L2Rpdj4NCjxkaXY+dGhhbiBzb21lIG9mIGl0J3Mgbm9ybWF0aXZlIHJlZmVyZW5jZXMsIGl0 IHdvdWxkIHNlZW0gdG8gYmUgdXNlZnVsIHRvPC9kaXY+DQo8ZGl2PmNsZWFybHkgc3RhdGUgdGhp cyBpbiB0aGUgaW50cm9kdWN0aW9uIChvciBlbHNld2hlcmUpIGluIHRoZSBkb2N1bWVudC48L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNwZWNp ZmljIGNvbW1lbnRzOiBJIGRvIGhhdmUgY29uY2VybnMgd2l0aCB0aGU8L2Rpdj4NCjxkaXY+c3Bl Y2lmaWNzIG9mIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLCBpbiBwYXJ0aWN1 bGFyLCBJIGRvbid0PC9kaXY+DQo8ZGl2PnJlYWxseSB1bmRlcnN0YW5kIHRoZSBiYXNpYyBpbnRl bnQgb2Ygd2hhdCB0aGUgdHdvIG1haW4gcGFyYWdyYXBocyBhcmU8L2Rpdj4NCjxkaXY+dHJ5aW5n IHRvIHNheS48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9P S19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBz b2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+LSBUaGUgYmFzaWMgbWVhbmluZyBvZiB3aGVuIGVuY3J5cHRpb24gc2hvdWxkIGJl IHVzZWQgaW4gdGhlIGZpcnN0PC9kaXY+DQo8ZGl2PnBhcmFncmFwaCBpcyBhd2t3YXJkIGFuZCBu b3QgY2xlYXIgKHBlcmhhcHMgaXQncyBhIGNvbXByb21pc2Ugd29yZGluZzwvZGl2Pg0KPGRpdj5m cm9tIHRoZSBXRyBidXQgdGhhdCB3b24ndCBtYXR0ZXIgbGF0ZXIpIC0gSSBjYW4gcmVhZCB0aGUg d29yZGluZzwvZGl2Pg0KPGRpdj5zZXZlcmFsIGRpZmZlcmVudCB3YXlzIHdoaWNoIHdvdWxkIHJl c3VsdCBpbiB2ZXJ5IGRpZmZlcmVudCBpbmZlcmVuY2VzPC9kaXY+DQo8ZGl2PmFib3V0IHdoZW4g Y3J5cHRvZ3JhcGh5IHNob3VsZCBhY3R1YWxseSBiZSB1c2VkLCBlLmcuLDo8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2Pi0gLSAmcXVvdDtjcnlwdG9ncmFwaGljLWJhc2VkIHNlY3VyaXR5 JnF1b3Q7IHNob3VsZCBiZSB1c2VkIGZvciBhbGwgY2FzZXMgdW5sZXNzPC9kaXY+DQo8ZGl2PnRo ZSBjb25uZWN0aW9uIGlzIHByb3RlY3RlZCBieSBwaHlzaWNhbCBzZWN1cml0eTs8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi0gLSBpZiB0aGVyZSBpcyBub3QgcGh5c2ljYWwgc2VjdXJp dHkgYmV0d2VlbiB0aGUgcGVlcmluZyBwcm92aWRlcnMsIHRoZTwvZGl2Pg0KPGRpdj51c2Ugb2Yg JnF1b3Q7Y3J5cHRvZ3JhcGhpYy1iYXNlZCBzZWN1cml0eSZxdW90OyBpcyBzdWdnZXN0ZWQvcmVj b21tZW5kZWQ7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tIC0gdXNlIG9mICZxdW90 O2NyeXB0b2dyYXBoaWMtYmFzZWQgc2VjdXJpdHkmcXVvdDsgaXMgb3B0aW9uYWwgaW4gYWxsIHNp dHVhdGlvbnM7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tIC0gaW50ZW5kZWQgdXNl IG9mICZxdW90O2NyeXB0b2dyYXBoaWMtYmFzZWQgc2VjdXJpdHkmcXVvdDsgaXMgZGlmZmVyZW50 IHRoYW4gYW55PC9kaXY+DQo8ZGl2Pm9mIHRoZSBhYm92ZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PlN1Z2dlc3RlZCBzb2x1dGlvbjogSXQgc2VlbXMgdG8gbWUgbGlrZSB0aGVyZSBz aG91bGQgYmUgc29tZSBzcGVjaWZpYzwvZGl2Pg0KPGRpdj5yZWZlcmVuY2VzIHRvIHRoZSBhcHBy b3ByaWF0ZSBzZWN0aW9ucyBvZiB0aGUgdm9pcHRocmVhdHMgJmFtcDsgcmVxdWlyZW1lbnRzPC9k aXY+DQo8ZGl2PmRvY3VtZW50cyAtIHRoaXMgc2hvdWxkIG5vdCBiZSBhIHByb2JsZW0gc2luY2Ug dGhleSBhcmUgbm9ybWF0aXZlPC9kaXY+DQo8ZGl2PnJlZmVyZW5jZXMgYW5kIHdpbGwgbmVlZCB0 byBiZSBwdWJsaXNoZWQgbW9yZSBvciBsZXNzIGF0IHRoZSBzYW1lIHRpbWUuPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+W0pMXSBJIGNhbiBzZWUg aG93IHRoaXMgaXMgdGhlIGNhc2UuIEJhc2VkIG9uIHlvdXIgZmVlZGJhY2ssIEkgcGxhbiB0byBj aGFuZ2UgaXQgdG8gdGhpczo8L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNw YW4iIHN0eWxlPSJmb250LXNpemU6IHNtYWxsOyBmb250LWZhbWlseTogdmVyZGFuYSwgY2hhcmNv YWwsIGhlbHZldGljYSwgYXJpYWwsIHNhbnMtc2VyaWY7ICI+DQo8aDMgc3R5bGU9ImZvbnQtZmFt aWx5OiBoZWx2ZXRpY2EsIG1vbmFjbywgJ01TIFNhbnMgU2VyaWYnLCBhcmlhbCwgc2Fucy1zZXJp ZjsgZm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgY29sb3I6IHJnYig1MSwg NTEsIDUxKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7ICI+DQo8c3BhbiBjbGFzcz0i QXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGZvbnQtc2l6ZTogc21hbGw7IGZvbnQtZmFtaWx5OiB2ZXJkYW5hLCBjaGFyY29h bCwgaGVsdmV0aWNhLCBhcmlhbCwgc2Fucy1zZXJpZjsgIj4NCjxoMyBzdHlsZT0iZm9udC1mYW1p bHk6IGhlbHZldGljYSwgbW9uYWNvLCAnTVMgU2FucyBTZXJpZicsIGFyaWFsLCBzYW5zLXNlcmlm OyBmb250LXdlaWdodDogYm9sZDsgZm9udC1zdHlsZTogbm9ybWFsOyBjb2xvcjogcmdiKDUxLCA1 MSwgNTEpOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgIj4NCjxmb250IGNsYXNzPSJB cHBsZS1zdHlsZS1zcGFuIiBjb2xvcj0iIzAwMDAwMCIgZmFjZT0idmVyZGFuYSwgY2hhcmNvYWws IGhlbHZldGljYSwgYXJpYWwsIHNhbnMtc2VyaWYiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1z cGFuIiBzdHlsZT0iZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiBzbWFsbDsiPjxmb250 IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iaGVsdmV0aWNh LG1vbmFjbyxNUyBTYW5zIFNlcmlmLGFyaWFsLHNhbnMtc2VyaWYiIHNpemU9IjQiPjxzcGFuIGNs YXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXplOiAxNXB4OyI+PGI+PHNwYW4g Y2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6IHNtYWxsOyBmb250LWZhbWlseTogdmVyZGFuYSwg Y2hhcmNvYWwsIGhlbHZldGljYSwgYXJpYWwsIHNhbnMtc2VyaWY7ICI+DQo8aDMgc3R5bGU9ImZv bnQtZmFtaWx5OiBoZWx2ZXRpY2EsIG1vbmFjbywgJ01TIFNhbnMgU2VyaWYnLCBhcmlhbCwgc2Fu cy1zZXJpZjsgZm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgY29sb3I6IHJn Yig1MSwgNTEsIDUxKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7ICI+DQoxMC4mbmJz cDsgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L2gzPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OiAy ZW07IG1hcmdpbi1yaWdodDogMmVtOyAiPlRoZSBsZXZlbCAob3IgdHlwZXMpIG9mIHNlY3VyaXR5 IG1lY2hhbmlzbXMgaW1wbGVtZW50ZWQgYmV0d2VlbiBwZWVyaW5nIHByb3ZpZGVycyBpcyBpbiBw cmFjdGljZSBkZXBlbmRlbnQgdXBvbiBvbiB0aGUgdW5kZXJseWluZyBwaHlzaWNhbCBzZWN1cml0 eSBvZiBTU1AgY29ubmVjdGlvbnMuIFRoaXMgbWVhbnMsIGFzIG5vdGVkIGluJm5ic3A7PGEgY2xh c3M9ImluZm8iIGhyZWY9Imh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL2NnaS1iaW4veG1sMnJmYy5j Z2kjQ28tTG9jYXRpb24iIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsgcG9zaXRpb246IHJlbGF0 aXZlOyB6LWluZGV4OiAyNDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBjb2xvcjogcmdiKDE1Mywg MCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyAiPlNlY3Rpb24mbmJzcDs2LjEu My4zPC9hPiwNCiB3aGV0aGVyIHBlZXJpbmcgZXF1aXBtZW50IGlzIGluIGEgc2VjdXJlIGZhY2ls aXR5IG9yIG5vdCBtYXkgYmVhciBvbiBvdGhlciB0eXBlcyBvZiBzZWN1cml0eSBtZWNoYW5pc21z IHdoaWNoIG1heSBiZSBhcHByb3ByaWF0ZS4gVGh1cywgaWYgdHdvIFNTUHMgcGVlcmVkIGFjcm9z cyBwdWJsaWMgSW50ZXJuZXQgbGlua3MsIHRoZXkgYXJlIGxpa2VseSB0byB1c2UgSVBTZWMgb3Ig VExTIHNpbmNlIHRoZSBsaW5rIGJldHdlZW4gdGhlIHR3byBkb21haW5zDQogc2hvdWxkIGJlIGNv bnNpZGVyZWQgdW50cnVzdGVkLjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDogMmVtOyBtYXJn aW4tcmlnaHQ6IDJlbTsgIj5NYW55IGRldGFpbGVkIGFuZCBoaWdobHkgcmVsZXZhbnQgc2VjdXJp dHkgcmVxdWlyZW1lbnRzIGZvciBTUEVFUk1JTlQgaGF2ZSBiZWVuIGRvY3VtZW50ZWQgaW4gU2Vj dGlvbiA1IG9mJm5ic3A7PGEgY2xhc3M9ImluZm8iIGhyZWY9Imh0dHA6Ly94bWwucmVzb3VyY2Uu b3JnL2NnaS1iaW4veG1sMnJmYy5jZ2kjSS1ELmlldGYtc3BlZXJtaW50LXJlcXVpcmVtZW50cyIg c3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyBwb3NpdGlvbjogcmVsYXRpdmU7IHotaW5kZXg6IDI0 OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGNvbG9yOiByZ2IoMTUzLCAwLCAwKTsgYmFja2dyb3Vu ZC1jb2xvcjogdHJhbnNwYXJlbnQ7ICI+W0nigJFELmlldGbigJFzcGVlcm1pbnTigJFyZXF1aXJl bWVudHNdPC9hPi4NCiBBcyBhIHJlc3VsdCwgdGhhdCBkb2N1bWVudCBzaG91bGQgYmUgY29uc2lk ZXJlZCByZXF1aXJlZCByZWFkaW5nLjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDogMmVtOyBt YXJnaW4tcmlnaHQ6IDJlbTsgIj5BZGRpdGlvbmFsIGFuZCBpbXBvcnRhbnQgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgaGF2ZSBiZWVuIGRvY3VtZW50ZWQgc2VwYXJhdGVseSBpbiZuYnNwOzxhIGNs YXNzPSJpbmZvIiBocmVmPSJodHRwOi8veG1sLnJlc291cmNlLm9yZy9jZ2ktYmluL3htbDJyZmMu Y2dpI0ktRC5pZXRmLXNwZWVybWludC12b2lwdGhyZWF0cyIgc3R5bGU9ImZvbnQtd2VpZ2h0OiBi b2xkOyBwb3NpdGlvbjogcmVsYXRpdmU7IHotaW5kZXg6IDI0OyB0ZXh0LWRlY29yYXRpb246IG5v bmU7IGNvbG9yOiByZ2IoMTUzLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7 ICI+W0nigJFELmlldGbigJFzcGVlcm1pbnTigJF2b2lwdGhyZWF0c108L2E+Lg0KIFRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzIHRoZSBtYW55IHJlbGV2YW50IHNlY3VyaXR5IHRocmVhdHMgdG8gU1BF RVJNSU5ULCBhcyB3ZWxsIHRoZSByZWxldmFudCBjb3VudGVybWVhc3VyZXMgYW5kIHNlY3VyaXR5 IHByb3RlY3Rpb25zIHdoaWNoIGFyZSByZWNvbW1lbmRlZCB0byBjb21iYXQgYW55IHBvdGVudGlh bCB0aHJlYXRzIG9yIG90aGVyIHJpc2tzLiBUaGlzIGluY2x1ZGVzIGEgd2lkZSByYW5nZSBvZiBk ZXRhaWxlZCB0aHJlYXRzIGluIFNlY3Rpb24NCiAyIG9mJm5ic3A7PGEgY2xhc3M9ImluZm8iIGhy ZWY9Imh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL2NnaS1iaW4veG1sMnJmYy5jZ2kjSS1ELmlldGYt c3BlZXJtaW50LXZvaXB0aHJlYXRzIiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7IHBvc2l0aW9u OiByZWxhdGl2ZTsgei1pbmRleDogMjQ7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgY29sb3I6IHJn YigxNTMsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgIj5bSeKAkUQuaWV0 ZuKAkXNwZWVybWludOKAkXZvaXB0aHJlYXRzXTwvYT4uDQogSXQgYWxzbyBpbmNsdWRlcyBrZXkg cmVxdWlyZW1lbnRzIGluIFNlY3Rpb24gMy4xIG9mPGEgY2xhc3M9ImluZm8iIGhyZWY9Imh0dHA6 Ly94bWwucmVzb3VyY2Uub3JnL2NnaS1iaW4veG1sMnJmYy5jZ2kjSS1ELmlldGYtc3BlZXJtaW50 LXZvaXB0aHJlYXRzIiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7IHBvc2l0aW9uOiByZWxhdGl2 ZTsgei1pbmRleDogMjQ7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgY29sb3I6IHJnYigxNTMsIDAs IDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgIj5bSeKAkUQuaWV0ZuKAkXNwZWVy bWludOKAkXZvaXB0aHJlYXRzXTwvYT4sDQogc3VjaCBhcyB0aGUgcmVxdWlyZW1lbnQgZm9yIHRo ZSBMVUYgYW5kIExSRiB0byBzdXBwb3J0IG11dHVhbCBhdXRoZW50aWNhdGlvbiBmb3IgcXVlcmll cywgYW1vbmcgb3RoZXIgcmVxdWlyZW1lbnRzIHdoaWNoIGFyZSByZWxhdGVkIHRvJm5ic3A7PGEg Y2xhc3M9ImluZm8iIGhyZWY9Imh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL2NnaS1iaW4veG1sMnJm Yy5jZ2kjSS1ELmlldGYtc3BlZXJtaW50LXJlcXVpcmVtZW50cyIgc3R5bGU9ImZvbnQtd2VpZ2h0 OiBib2xkOyBwb3NpdGlvbjogcmVsYXRpdmU7IHotaW5kZXg6IDI0OyB0ZXh0LWRlY29yYXRpb246 IG5vbmU7IGNvbG9yOiByZ2IoMTUzLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJl bnQ7ICI+W0nigJFELmlldGbigJFzcGVlcm1pbnTigJFyZXF1aXJlbWVudHNdPC9hPi4NCiBTZWN0 aW9uIDMuMiBvZiZuYnNwOzxhIGNsYXNzPSJpbmZvIiBocmVmPSJodHRwOi8veG1sLnJlc291cmNl Lm9yZy9jZ2ktYmluL3htbDJyZmMuY2dpI0ktRC5pZXRmLXNwZWVybWludC12b2lwdGhyZWF0cyIg c3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyBwb3NpdGlvbjogcmVsYXRpdmU7IHotaW5kZXg6IDI0 OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGNvbG9yOiByZ2IoMTUzLCAwLCAwKTsgYmFja2dyb3Vu ZC1jb2xvcjogdHJhbnNwYXJlbnQ7ICI+W0nigJFELmlldGbigJFzcGVlcm1pbnTigJF2b2lwdGhy ZWF0c108L2E+Jm5ic3A7ZXhwbGFpbnMNCiBob3cgdG8gbWVldCB0aGVzZSBzZWN1cml0eSByZXF1 aXJlbWVudHMsIGFuZCB0aGVuIFNlY3Rpb24gNCBleHBsb3JlcyBhIHdpZGUgcmFuZ2Ugb2Ygc3Vn Z2VzdGVkIGNvdW50ZXJtZWFzdXJlcy48L3A+DQo8L3NwYW4+PC9iPjwvc3Bhbj48L2ZvbnQ+PC9z cGFuPjwvZm9udD48L2gzPg0KPGEgbmFtZT0iYW5jaG9yMyIgc3R5bGU9ImZvbnQtd2VpZ2h0OiBi b2xkOyAiPjwvYT48L3NwYW4+PC9oMz4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVIt TEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+ DQo8ZGl2Pi0gVGhlIHNlY29uZCBwYXJhZ3JhcGggb2YgdGhlIHNlY3Rpb24gc2VlbXMgdG8gYmUg c2F5aW5nIHRoYXQgdGhlIFdHPC9kaXY+DQo8ZGl2PmJlbGlldmVzIHRoYXQgYWRkaXRpb25hbCBt ZXRob2RzIG9mIHBlZXJpbmcgbmVlZCB0byBiZSBzdGFuZGFyZGl6ZWQ8L2Rpdj4NCjxkaXY+KHdo aWNoIHNlZW1zIGZpbmUpIGJ1dCBpdCdzIHJhdGhlciB1bmNsZWFyIHdoYXQgdGhlICZxdW90O21h aW50YWluIGE8L2Rpdj4NCjxkaXY+Y29uc2lzdGVudCBhcHByb2FjaCZxdW90OyBpcyBzdXBwb3Nl ZCB0byBiZSBjb25zaXN0ZW50IHdpdGggZXNwZWNpYWxseSBzaW5jZTwvZGl2Pg0KPGRpdj50aGUg c2VjdXJpdHkgcmVxdWlyZW1lbnRzIG9mIHRoZSBwcmV2aW91cyBwYXJhZ3JhcGggYXJlIHVuY2xl YXIuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TdWdnZXN0ZWQgc29sdXRpb246IElm IGNsZWFyIGFuZCByZWFzb25hYmx5IHNwZWNpZmljIHJlcXVpcmVtZW50cyBjYW4gYmU8L2Rpdj4N CjxkaXY+aWRlbnRpZmllZCBmb3IgdGhlIHByZXZpb3VzIHBhcmFncmFwaCB0aGVuIGl0IHNlZW1z IGxpa2UgdGhlc2UgKG9yPC9kaXY+DQo8ZGl2PmVxdWl2YWxlbnQgcmVxdWlyZW1lbnRzKSBjYW4g YmUgYXBwbGllZCB0byBmdXR1cmUgc3RhbmRhcmRzIGZvciBwZWVyaW5nLjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+W0pMXSBUaGF0IHNlZW1zIHRvIGhhdmUg YmVlbiBvbGQgdGV4dCBhcmd1aW5nIGZvciBhIHNlcGFyYXRlIHNlY3VyaXR5IHRocmVhdHMgZG9j dW1lbnQsIHdoaWNoIHdlIG5vdyBoYXZlLCBzbyBJIHJlbW92ZWQgaXQgYXMgd3JpdHRlbiBhYm92 ZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tf QVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29s aWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+T3RoZXIgKGJhc2lj YWxseSBlZGl0b3JpYWwpIENvbW1lbnRzOjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ LSBJbiBTZWN0aW9uIDQsIHRoZSB0ZXJtICZxdW90O1Nlc3Npb24gQm9yZGVyIENvbnRyb2xsZXIm cXVvdDsgaXMgbm90IGRlZmluZWQgaW48L2Rpdj4NCjxkaXY+UkZDNTQ4NiBvciB0aGlzIGRvY3Vt ZW50IC0gaXQgc2VlbXMgbGlrZSBhIGRlZmluaXRpb24gc2hvdWxkIGJlIGluY2x1ZGVkLjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+W0pMXSBBbm90aGVyIHJl dmlld2VyIG1hZGUgdGhlIHNhbWUgcG9pbnQsIHNvIHdlIGNyZWF0ZWQgYSBuZXcgc2VjdGlvbiAy IG9uIHRlcm1pbm9sb2d5LiBXZSBhZGRyZXNzIHRoaXMgbm93OjwvZGl2Pg0KPGRpdj48c3BhbiBj bGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImZvbnQtc2l6ZTogc21hbGw7IGZvbnQtZmFt aWx5OiB2ZXJkYW5hLCBjaGFyY29hbCwgaGVsdmV0aWNhLCBhcmlhbCwgc2Fucy1zZXJpZjsgIj4N CjxwIHN0eWxlPSJtYXJnaW4tbGVmdDogMmVtOyBtYXJnaW4tcmlnaHQ6IDJlbTsgIj48L3A+DQo8 aDMgc3R5bGU9ImZvbnQtZmFtaWx5OiBoZWx2ZXRpY2EsIG1vbmFjbywgJ01TIFNhbnMgU2VyaWYn LCBhcmlhbCwgc2Fucy1zZXJpZjsgZm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQtc3R5bGU6IG5vcm1h bDsgY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7 ICI+DQoyLjEuJm5ic3A7IFNlc3Npb24gQm9yZGVyIENvbnRyb2xsZXIgKFNCQyk8L2gzPg0KQSBT ZXNzaW9uIEJvcmRlciBDb250cm9sbGVyIChTQkMpIGlzIHJlZmVycmVkIHRvIGluJm5ic3A7PGEg Y2xhc3M9ImluZm8iIGhyZWY9Imh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL2NnaS1iaW4veG1sMnJm Yy5jZ2kjUmVsYXRpb25zaGlwcyBCZXR3ZWVuIEZ1bmN0aW9ucy9FbGVtZW50cyIgc3R5bGU9ImZv bnQtd2VpZ2h0OiBib2xkOyBwb3NpdGlvbjogcmVsYXRpdmU7IHotaW5kZXg6IDI0OyB0ZXh0LWRl Y29yYXRpb246IG5vbmU7IGNvbG9yOiByZ2IoMTUzLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjog dHJhbnNwYXJlbnQ7ICI+U2VjdGlvbiZuYnNwOzU8L2E+Lg0KIEFuIFNCQyBjYW4gY29udGFpbiBh IFNpZ25hbGluZyBGdW5jdGlvbiAoU0YpLCBTaWduYWxpbmcgUGF0aCBCb3JkZXIgRWxlbWVudCAo U0JFKSBhbmQgRGF0YSBQYXRoIEJvcmRlciBFbGVtZW50IChEQkUpLCBhbmQgbWF5IHBlcmZvcm0g dGhlIExvb2stVXAgRnVuY3Rpb24gKExVRikgYW5kIExvY2F0aW9uIFJvdXRpbmcgRnVuY3Rpb24g KExSRikgZnVuY3Rpb25zLCBhcyBkZXNjcmliZWQgaW4mbmJzcDs8YSBjbGFzcz0iaW5mbyIgaHJl Zj0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvY2dpLWJpbi94bWwycmZjLmNnaSNSZWZlcmVuY2Ug QXJjaGl0ZWN0dXJlIiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7IHBvc2l0aW9uOiByZWxhdGl2 ZTsgei1pbmRleDogMjQ7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgY29sb3I6IHJnYigxNTMsIDAs IDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgIj5TZWN0aW9uJm5ic3A7MzwvYT4u DQogV2hldGhlciB0aGUgU0JDIHBlcmZvcm1zIG9uZSBvciBtb3JlIG9mIHRoZXNlIGZ1bmN0aW9u cyBpcyBnZW5lcmFsbHkgc3BlYWtpbmcgZGVwZW5kZW50IHVwb24gaG93IGEgU0lQIFNlcnZpY2Ug UHJvdmlkZXIgKFNTUCkgY29uZmlndXJlcyBzdWNoIGEgbmV0d29yayBlbGVtZW50LiBJbiBhZGRp dGlvbiwgcmVxdWlyZW1lbnRzIGZvciBhbiBTQkMgY2FuIGJlIGZvdW5kIGluJm5ic3A7PGEgY2xh c3M9ImluZm8iIGhyZWY9Imh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL2NnaS1iaW4veG1sMnJmYy5j Z2kjUkZDNTg1MyIgc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyBwb3NpdGlvbjogcmVsYXRpdmU7 IHotaW5kZXg6IDI0OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGNvbG9yOiByZ2IoMTUzLCAwLCAw KTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7ICI+W1JGQzU4NTNdPC9hPi4NCjxwPjwv cD4NCjwvc3Bhbj48L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElP Tl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElO RzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4tIEluIFNlY3Rpb24gNCwgdGhlIGZp cnN0IHRocmVlIGJ1bGxldCBwb2ludHMgd291bGQgaGF2ZSAmcXVvdDtmdW5jdGlvbjwvZGl2Pg0K PGRpdj5mdW5jdGlvbiZxdW90OyBpZiB0aGUgYWNyb255bXMgd2VyZSBzcGVsbGVkIG91dCAtIHRo aXMgbWlnaHQgYmUgb2theSBidXQgc29tZTwvZGl2Pg0KPGRpdj5wZW9wbGUgdmlldyBpdCBhcyBp bmNvcnJlY3QuPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5b SkxdIEFscmVhZHkgZml4ZWQuIEl0IG5vdyByZWFkczo8L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9 IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJmb250LXNpemU6IHNtYWxsOyBmb250LWZhbWlseTog dmVyZGFuYSwgY2hhcmNvYWwsIGhlbHZldGljYSwgYXJpYWwsIHNhbnMtc2VyaWY7ICI+DQo8aDMg c3R5bGU9ImZvbnQtZmFtaWx5OiBoZWx2ZXRpY2EsIG1vbmFjbywgJ01TIFNhbnMgU2VyaWYnLCBh cmlhbCwgc2Fucy1zZXJpZjsgZm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Y29sb3I6IHJnYig1MSwgNTEsIDUxKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7ICI+ DQo1LiZuYnNwOyBSZWxhdGlvbnNoaXBzIEJldHdlZW4gRnVuY3Rpb25zL0VsZW1lbnRzPC9oMz4N CjxwIHN0eWxlPSJtYXJnaW4tbGVmdDogMmVtOyBtYXJnaW4tcmlnaHQ6IDJlbTsgIj5QbGVhc2Ug YWxzbyByZWZlciB0byZuYnNwOzxhIGNsYXNzPSJpbmZvIiBocmVmPSJodHRwOi8veG1sLnJlc291 cmNlLm9yZy9jZ2ktYmluL3htbDJyZmMuY2dpI3JlZl9hcmMiIHN0eWxlPSJmb250LXdlaWdodDog Ym9sZDsgcG9zaXRpb246IHJlbGF0aXZlOyB6LWluZGV4OiAyNDsgdGV4dC1kZWNvcmF0aW9uOiBu b25lOyBjb2xvcjogcmdiKDE1MywgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50 OyAiPkZpZ3VyZSZuYnNwOzE8L2E+LjwvcD4NCjx1bCBjbGFzcz0idGV4dCIgc3R5bGU9Im1hcmdp bi1sZWZ0OiAyZW07IG1hcmdpbi1yaWdodDogMmVtOyAiPg0KPGxpIHN0eWxlPSJtYXJnaW4tbGVm dDogM2VtOyAiPkFuIFNCRSBjYW4gY29udGFpbiBhIFNpZ25hbGluZyBGdW5jdGlvbiAoU0YpLjwv bGk+PGxpIHN0eWxlPSJtYXJnaW4tbGVmdDogM2VtOyAiPkFuIFNGIGNhbiBwZXJmb3JtIGEgTG9v ay1VcCBGdW5jdGlvbiAoTFVGKSBhbmQgTG9jYXRpb24gUm91dGluZyBGdW5jdGlvbiAoTFJGKS48 L2xpPjxsaSBzdHlsZT0ibWFyZ2luLWxlZnQ6IDNlbTsgIj5BcyBhbiBhZGRpdGlvbmFsIGNvbnNp ZGVyYXRpb24sIGEgU2Vzc2lvbiBCb3JkZXIgQ29udHJvbGxlciwgY2FuIGNvbnRhaW4gYW4gU0Ys IFNCRSBhbmQgREJFLCBhbmQgbWF5IGFjdCBhcyBib3RoIGFuIExVRiBhbmQgTFJGLjwvbGk+PGxp IHN0eWxlPSJtYXJnaW4tbGVmdDogM2VtOyAiPlRoZSBmb2xsb3dpbmcgZnVuY3Rpb25zIG1heSBj b21tdW5pY2F0ZSBhcyBmb2xsb3dzIGluIGFuIGV4YW1wbGUgU1NQIG5ldHdvcmssIGRlcGVuZGlu ZyB1cG9uIHZhcmlvdXMgcmVhbC13b3JsZCBpbXBsZW1lbnRhdGlvbnM6DQo8dWwgY2xhc3M9InRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDogMmVtOyBtYXJnaW4tcmlnaHQ6IDJlbTsgIj4NCjxsaSBz dHlsZT0ibWFyZ2luLWxlZnQ6IDNlbTsgIj5TRiBtYXkgY29tbXVuaWNhdGUgd2l0aCBMVUYsIExS RiwgU0JFIGFuZCBTRjwvbGk+PGxpIHN0eWxlPSJtYXJnaW4tbGVmdDogM2VtOyAiPkxVRiBtYXkg Y29tbXVuaWNhdGUgd2l0aCBTRiBhbmQgU0JFPC9saT48bGkgc3R5bGU9Im1hcmdpbi1sZWZ0OiAz ZW07ICI+TFJGIG1heSBjb21tdW5pY2F0ZSB3aXRoIFNGIGFuZCBTQkU8L2xpPjwvdWw+DQo8L2xp PjwvdWw+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9 Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDog I2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2 Pi0gSW4gdGhlIGZvdXJ0aCBidWxsZXQgb2YgU2VjdGlvbiA0LCBpdCdzIG5vdCBjbGVhciB3aGF0 ICZxdW90O2NhbjwvZGl2Pg0KPGRpdj5jb21tdW5pY2F0ZSZxdW90OyBtZWFucyAtIGlzIHRoaXMg YSByZXN0cmljdGl2ZSBzdGF0ZW1lbnQsIGRvZXMgaXQgbWVhbiB0aGF0PC9kaXY+DQo8ZGl2Pm9u bHkgdGhlIGxlZnQtbW9zdCBmdW5jdGlvbiBjYW4gaW5pdGlhdGUgYW4gZXhjaGFuZ2Ugb3Igc29t ZXRoaW5nIGVsc2U8L2Rpdj4NCjxkaXY+YWx0b2dldGhlci4mbmJzcDsmbmJzcDtJdCBzZWVtcyBs aWtlIGEgY2xhcmlmaWNhdGlvbiBpcyBpbiBvcmRlci48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PltKTF0gQ2xhcmlmaWVkIGFib3ZlPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NL UVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAw IDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pi0gSW4gU2VjdGlvbiA1LjEuMi4yLCB0aGUgdGVy bSAmcXVvdDtjYXJyaWVyLW9mLXJlY29yZCZxdW90OyBpcyB1c2VkLiZuYnNwOyZuYnNwO1RoZSB0 ZXJtIGlzPC9kaXY+DQo8ZGl2Pm5vdCBkZWZpbmVkIG9yIHVzZWQgZWxzZXdoZXJlIGFuZCBzZWVt cyB0byBiZSBpbXBvcnRhbnQgdG8gdGhlIHByb3BlcjwvZGl2Pg0KPGRpdj5mdW5jdGlvbmluZyBv ZiB0aGUgcHJvY2VkdXJlLiZuYnNwOyZuYnNwO0EgY2xhcmlmaWNhdGlvbiB3b3VsZCBzZWVtIHRv IGJlIGluIG9yZGVyLjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+W0pMXSBBZ3JlZSwgYW5kIHdlIGFsc28gYWRkZWQgdGhpcyB0byB0aGUgbmV3IHRlcm1pbm9s b2d5IHNlY3Rpb246PC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBz dHlsZT0iZm9udC1zaXplOiBzbWFsbDsgZm9udC1mYW1pbHk6IHZlcmRhbmEsIGNoYXJjb2FsLCBo ZWx2ZXRpY2EsIGFyaWFsLCBzYW5zLXNlcmlmOyAiPg0KPGgzIHN0eWxlPSJmb250LWZhbWlseTog aGVsdmV0aWNhLCBtb25hY28sICdNUyBTYW5zIFNlcmlmJywgYXJpYWwsIHNhbnMtc2VyaWY7IGZv bnQtd2VpZ2h0OiBib2xkOyBmb250LXN0eWxlOiBub3JtYWw7IGNvbG9yOiByZ2IoNTEsIDUxLCA1 MSk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyAiPg0KMi4yLiZuYnNwOyBDYXJyaWVy LW9mLVJlY29yZDwvaDM+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDJlbTsgbWFyZ2luLXJpZ2h0 OiAyZW07ICI+QSBjYXJyaWVyLW9mLXJlY29yZCwgYXMgdXNlZCBpbiZuYnNwOzxhIGNsYXNzPSJp bmZvIiBocmVmPSJodHRwOi8veG1sLnJlc291cmNlLm9yZy9jZ2ktYmluL3htbDJyZmMuY2dpI1Jv dXRpbmcgVGFibGUiIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsgcG9zaXRpb246IHJlbGF0aXZl OyB6LWluZGV4OiAyNDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBjb2xvcjogcmdiKDE1MywgMCwg MCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyAiPlNlY3Rpb24mbmJzcDs2LjEuMi4y PC9hPiwNCiBpcyBkZWZpbmVkIGluJm5ic3A7PGEgY2xhc3M9ImluZm8iIGhyZWY9Imh0dHA6Ly94 bWwucmVzb3VyY2Uub3JnL2NnaS1iaW4veG1sMnJmYy5jZ2kjUkZDNTA2NyIgc3R5bGU9ImZvbnQt d2VpZ2h0OiBib2xkOyBwb3NpdGlvbjogcmVsYXRpdmU7IHotaW5kZXg6IDI0OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IGNvbG9yOiByZ2IoMTUzLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJh bnNwYXJlbnQ7ICI+W1JGQzUwNjddPC9hPi4gVGhhdCBkb2N1bWVudA0KIGRlc2NyaWJlcyB0aGUg dGVybSB0byByZWZlciB0byB0aGUgZW50aXR5IGhhdmluZyBkaXNjcmV0aW9uIG92ZXIgdGhlIGRv bWFpbiBhbmQgem9uZSBjb250ZW50IGFuZCBhY3RpbmcgYXMgdGhlIHJlZ2lzdHJhbnQgZm9yIGEg dGVsZXBob25lIG51bWJlciwgYXMgcmVwcmVzZW50ZWQgaW4gRU5VTS4gVGhpcyBjYW4gYmU6PC9w Pg0KPHVsIGNsYXNzPSJ0ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6IDJlbTsgbWFyZ2luLXJpZ2h0 OiAyZW07ICI+DQo8bGkgc3R5bGU9Im1hcmdpbi1sZWZ0OiAzZW07ICI+dGhlIFNlcnZpY2UgUHJv dmlkZXIgdG8gd2hpY2ggdGhlIEUuMTY0IG51bWJlciB3YXMgYWxsb2NhdGVkIGZvciBlbmQgdXNl ciBhc3NpZ25tZW50LCB3aGV0aGVyIGJ5IHRoZSBOYXRpb25hbCBSZWd1bGF0b3J5IEF1dGhvcml0 eSAoTlJBKSBvciB0aGUgSW50ZXJuYXRpb25hbCBUZWxlY29tbXVuaWNhdGlvbiBVbmlvbiAoSVRV KSwgZm9yIGluc3RhbmNlLCBhIGNvZGUgdW5kZXIgJnF1b3Q7SW50ZXJuYXRpb25hbA0KIE5ldHdv cmtzJnF1b3Q7ICgmIzQzOzg4Mikgb3IgJnF1b3Q7VW5pdmVyc2FsIFBlcnNvbmFsIFRlbGVjb21t dW5pY2F0aW9ucyAoVVBUKSZxdW90OyAoJiM0Mzs4NzgpIG9yLDwvbGk+PGxpIHN0eWxlPSJtYXJn aW4tbGVmdDogM2VtOyAiPmlmIHRoZSBudW1iZXIgaXMgcG9ydGVkLCB0aGUgc2VydmljZSBwcm92 aWRlciB0byB3aGljaCB0aGUgbnVtYmVyIHdhcyBwb3J0ZWQsIG9yPC9saT48bGkgc3R5bGU9Im1h cmdpbi1sZWZ0OiAzZW07ICI+d2hlcmUgbnVtYmVycyBhcmUgYXNzaWduZWQgZGlyZWN0bHkgdG8g ZW5kIHVzZXJzLCB0aGUgc2VydmljZSBwcm92aWRlciB0aGF0IHRoZSBlbmQgdXNlciBudW1iZXIg YXNzaWduZWUgaGFzIGNob3NlbiB0byBwcm92aWRlIGEgUHVibGljIFN3aXRjaGVkIFRlbGVwaG9u ZSBOZXR3b3JrL1B1YmxpYyBMYW5kIE1vYmlsZSBOZXR3b3JrIChQU1ROLyBQTE1OKSBwb2ludC1v Zi1pbnRlcmNvbm5lY3QgZm9yDQogdGhlIG51bWJlci48L2xpPjwvdWw+DQo8cCBzdHlsZT0ibWFy Z2luLWxlZnQ6IDJlbTsgbWFyZ2luLXJpZ2h0OiAyZW07ICI+SXQgaXMgdW5kZXJzdG9vZCB0aGF0 IHRoZSBkZWZpbml0aW9uIG9mIGNhcnJpZXItb2YtcmVjb3JkIHdpdGhpbiBhIGdpdmVuIGp1cmlz ZGljdGlvbiBpcyBzdWJqZWN0IHRvIG1vZGlmaWNhdGlvbiBieSBuYXRpb25hbCBhdXRob3JpdGll cy48L3A+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9 Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDog I2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2 Pi0gSW4gU2VjdGlvbiA1LjEuMy4yLCBJUFNlYyBpcyBtZW50aW9uZWQgaW4gdGhlIG9yaWdpbmF0 aW5nIHByb2NlZHVyZXMuPC9kaXY+DQo8ZGl2PlRoZXJlIGlzIG5vIGNvcnJlc3BvbmRpbmcgbWVu dGlvbiBpbiB0aGUgdGFyZ2V0IHByb2NlZHVyZXMgc2VjdGlvbjwvZGl2Pg0KPGRpdj53aGljaCBz ZWVtcyB0byBiZSBhbiBvbWlzc2lvbiB0aGF0IHNob3VsZCBiZSBjb3JyZWN0ZWQuPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5bSkxdIFl1cC4gJm5ic3A7V2Ug YWRkZWQgYSBsaW5lIHRvIHRoZSByZWxldmFudCBzZWN0aW9uIHRvIGFkZHJlc3MgdGhpcyBhbmQg cmVmZXIgYmFjayB0byB0aGUgSVBTZWMgc2VjdGlvbi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXplOiBz bWFsbDsgZm9udC1mYW1pbHk6IHZlcmRhbmEsIGNoYXJjb2FsLCBoZWx2ZXRpY2EsIGFyaWFsLCBz YW5zLXNlcmlmOyAiPg0KPGgzIHN0eWxlPSJmb250LWZhbWlseTogaGVsdmV0aWNhLCBtb25hY28s ICdNUyBTYW5zIFNlcmlmJywgYXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtd2VpZ2h0OiBib2xkOyBm b250LXN0eWxlOiBub3JtYWw7IGNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGJhY2tncm91bmQtY29s b3I6IHRyYW5zcGFyZW50OyAiPg0KNi4yLjEuJm5ic3A7IFRMUzwvaDM+DQo8cCBzdHlsZT0ibWFy Z2luLWxlZnQ6IDJlbTsgbWFyZ2luLXJpZ2h0OiAyZW07ICI+VGhlIHNlY3Rpb24gZGVmaW5lcyB0 aGUgdXNhZ2Ugb2YgVExTIGJldHdlZW4gdHdvIFNTUHMmbmJzcDs8YSBjbGFzcz0iaW5mbyIgaHJl Zj0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvY2dpLWJpbi94bWwycmZjLmNnaSNSRkM1MjQ2IiBz dHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7IHBvc2l0aW9uOiByZWxhdGl2ZTsgei1pbmRleDogMjQ7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgY29sb3I6IHJnYigxNTMsIDAsIDApOyBiYWNrZ3JvdW5k LWNvbG9yOiB0cmFuc3BhcmVudDsgIj5bUkZDNTI0Nl08L2E+Jm5ic3A7PGEgY2xhc3M9ImluZm8i IGhyZWY9Imh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL2NnaS1iaW4veG1sMnJmYy5jZ2kjUkZDNTc0 NiIgc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyBwb3NpdGlvbjogcmVsYXRpdmU7IHotaW5kZXg6 IDI0OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGNvbG9yOiByZ2IoMTUzLCAwLCAwKTsgYmFja2dy b3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7ICI+W1JGQzU3NDZdPC9hPiZuYnNwOzxhIGNsYXNzPSJp bmZvIiBocmVmPSJodHRwOi8veG1sLnJlc291cmNlLm9yZy9jZ2ktYmluL3htbDJyZmMuY2dpI1JG QzU4NzgiIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsgcG9zaXRpb246IHJlbGF0aXZlOyB6LWlu ZGV4OiAyNDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBjb2xvcjogcmdiKDE1MywgMCwgMCk7IGJh Y2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyAiPltSRkM1ODc4XTwvYT4uDQogV2hlbiB0aGUg cmVjZWl2aW5nIFNTUCByZWNlaXZlcyBhIFRMUyBjbGllbnQgaGVsbG8sIGl0IHJlc3BvbmRzIHdp dGggaXRzIGNlcnRpZmljYXRlLiBUaGUgVGFyZ2V0IFNTUCBjZXJ0aWZpY2F0ZSBzaG91bGQgYmUg dmFsaWQgYW5kIHJvb3RlZCBpbiBhIHdlbGwta25vd24gY2VydGlmaWNhdGUgYXV0aG9yaXR5LiBU aGUgcHJvY2VkdXJlcyB0byBhdXRoZW50aWNhdGUgdGhlIFNTUCdzIG9yaWdpbmF0aW5nIGRvbWFp biBhcmUgc3BlY2lmaWVkIGluJm5ic3A7PGEgY2xhc3M9ImluZm8iIGhyZWY9Imh0dHA6Ly94bWwu cmVzb3VyY2Uub3JnL2NnaS1iaW4veG1sMnJmYy5jZ2kjUkZDNTkyMiIgc3R5bGU9ImZvbnQtd2Vp Z2h0OiBib2xkOyBwb3NpdGlvbjogcmVsYXRpdmU7IHotaW5kZXg6IDI0OyB0ZXh0LWRlY29yYXRp b246IG5vbmU7IGNvbG9yOiByZ2IoMTUzLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNw YXJlbnQ7ICI+W1JGQzU5MjJdPC9hPi48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDJlbTsg bWFyZ2luLXJpZ2h0OiAyZW07ICI+VGhlIFNGIG9mIHRoZSBUYXJnZXQgU1NQIHZlcmlmaWVzIHRo YXQgdGhlIElkZW50aXR5IGhlYWRlciBpcyB2YWxpZCwgY29ycmVzcG9uZHMgdG8gdGhlIG1lc3Nh Z2UsIGNvcnJlc3BvbmRzIHRvIHRoZSBJZGVudGl0eS1JbmZvIGhlYWRlciwgYW5kIHRoYXQgdGhl IGRvbWFpbiBpbiB0aGUgRnJvbSBoZWFkZXIgY29ycmVzcG9uZHMgdG8gb25lIG9mIHRoZSBkb21h aW5zDQogaW4gdGhlIFRMUyBjbGllbnQgY2VydGlmaWNhdGUuPC9wPg0KPHAgc3R5bGU9Im1hcmdp bi1sZWZ0OiAyZW07IG1hcmdpbi1yaWdodDogMmVtOyAiPkFzIG5vdGVkIGFib3ZlIGluJm5ic3A7 PGEgY2xhc3M9ImluZm8iIGhyZWY9Imh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL2NnaS1iaW4veG1s MnJmYy5jZ2kjSVBTZWMiIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsgcG9zaXRpb246IHJlbGF0 aXZlOyB6LWluZGV4OiAyNDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBjb2xvcjogcmdiKDE1Mywg MCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyAiPlNlY3Rpb24mbmJzcDs2LjEu My4yPC9hPiwNCiBzb21lIGRlcGxveW1lbnRzIG1heSB1dGlsaXplIElQU2VjIHJhdGhlciB0aGFu IFRMUy48L3A+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg aWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVG VDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UnVzcyBNdW5keTwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C97035A116E27jasonlivingoodcablecomcastcom_-- From paul.hoffman@vpnc.org Sun Feb 20 14:06:09 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 049FF3A6CF7 for ; Sun, 20 Feb 2011 14:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.323 X-Spam-Level: X-Spam-Status: No, score=-101.323 tagged_above=-999 required=5 tests=[AWL=0.723, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O46cXxFgonFN for ; Sun, 20 Feb 2011 14:06:08 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 13FCC3A6CD6 for ; Sun, 20 Feb 2011 14:06:07 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1KM6lg6022009 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 20 Feb 2011 15:06:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D619077.4050706@vpnc.org> Date: Sun, 20 Feb 2011 14:06:47 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-sidr-cp@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-sidr-cp-16.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 22:06:09 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a certificate policy for Internet number resource holdings; basically, this is proposed to be the CP for the routing PKI being proposed in the SIDR WG. As such, it is a bunch of minutae that relying parties are supposed to care about, but will mostly accept blindly. This document is closely modeled after RFC 3647, the CP that is the framework for most CPs we see in the PKIX world. The security considerations listed in the document seem fine. They call out the fact that names are not unique in the RPKI (as if they were in the normal PKIX world...), so that relying parties must not rely just on the names for chaining, but must also be sure the expected signing key is used as well. This document could have a zillion more security considerations aimed at relying parties that don't pay careful attention, but such text would likely be ignored by the same parties who ignore the main CP text. Thus, this document is fine as-is. --Paul Hoffman From bertietf@bwijnen.net Mon Feb 21 00:20:31 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30CCE3A6FBE; Mon, 21 Feb 2011 00:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hwjDhXErqVf; Mon, 21 Feb 2011 00:20:30 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 534FF3A6F84; Mon, 21 Feb 2011 00:20:29 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PrR0u-0006lp-NX; Mon, 21 Feb 2011 09:21:02 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PrR0u-0006Mv-Km; Mon, 21 Feb 2011 09:21:00 +0100 Message-ID: <4D62206E.2030909@bwijnen.net> Date: Mon, 21 Feb 2011 09:21:02 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Tina Tsou References: <00dc01cbc734$9ab8cbe0$d02a63a0$@com> In-Reply-To: <00dc01cbc734$9ab8cbe0$d02a63a0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4071e60cfdd6c027100037708add5603a Cc: iesg@ietf.org, "Ersue, Mehmet \(NSN - DE/Munich\)" , draft-ietf-netconf-4741bis@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-netconf-4741bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 08:20:31 -0000 Revision 9 is out and tried to address IETF LC comments Here is the diff between the rev you reviewed and the latest one: http://tools.ietf.org/rfcdiff?url1=draft-ietf-netconf-4741bis-07&url2=draft-ietf-netconf-4741bis-09 Bert document shepherd On 2/8/11 3:05 AM, Tina Tsou 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. > > It is well written, so only some editorial comments are below. > > #1 > " > 2.2. Authentication, Integrity, and Confidentiality > ... > 2.3. Authentication > ... > " > > Perhaps the Titles of 2.2 and 2.3 can harmonize better to explain why there > are two "authentications" here. > > #2 > " > 6.2. Subtree Filter Components > > A subtree filter is comprised of XML elements and their XML > attributes. There are five types of components that may be present > in a subtree filter: > > o Namespace Selection > > o Attribute Match Expressions > > o Containment Nodes > > o Selection Nodes > > o Content Match Nodes > ... > " > > If a figure could be provided to describe the relationship among these 5 > components and when it becomes what, it would be very helpful for readers to > understand more easily. > > #3 > " > 6.2.3. Containment Nodes > > Nodes that contain child elements within a subtree filter are called > "containment nodes". > > I would say "Child Elements Nodes" or "Child Nodes" might be a little bit > more of straight forward than "Containment Nodes". > > > #4 > " > 7.2. > ... > Parameters: > ... > merge: The configuration data in the parameter is > merged with the configuration at the corresponding level in > the target datastore. This is the default behavior. > ... > " > Has the parameter been introduced before? > > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From shanna@juniper.net Mon Feb 21 07:05:44 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDF0F3A7121; Mon, 21 Feb 2011 07:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQ4oBNK80KhZ; Mon, 21 Feb 2011 07:05:44 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 9534F3A7115; Mon, 21 Feb 2011 07:05:43 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTWJ/bZxJfEf8oy7M5ru3F9qEgwZr52dF@postini.com; Mon, 21 Feb 2011 07:06:25 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 21 Feb 2011 07:03:52 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 21 Feb 2011 10:04:23 -0500 From: Stephen Hanna To: "secdir@ietf.org" , "iesg@ietf.org" Date: Mon, 21 Feb 2011 10:04:22 -0500 Thread-Topic: secdir review of draft-ietf-pwe3-fc-encap-14.txt Thread-Index: AcvR2J79mnoqbMWXRHiAcNAfdrQddA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-pwe3-fc-encap@tools.ietf.org" Subject: [secdir] secdir review of draft-ietf-pwe3-fc-encap-14.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 15:05:44 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the IESG.=20 These comments were written primarily for the benefit of the security=20 area directors. Document editors and WG chairs should treat these=20 comments just like any other last call comments. This document describes how Fibre Channel traffic can be carried over MPLS networks using a Fibre Channel pseudowire (FC PW). I am not an expert in Fibre Channel, MPLS, or pseudowires so I will not venture any judgment on the content of the draft. I will focus exclusively on the Security Considerations section. The Security Considerations section is rather brief, only five sentences long. While I support brevity, this section seems to omit key information. For example, the text says "FC PW shares susceptibility to a number of pseudowire-layer attacks and implementations SHOULD use whatever mechanisms for confidentiality, integrity, and authentication are developed for PWs in general. These methods are beyond the scope of this document." That's too brief. At least, the authors should add a reference to a document that describes the attacks to which this protocol is susceptible and the countermeasures that can be employed. If no such document exists, either it should be written or this document should describe the threats and countermeasures or this document should admit that the threats and countermeasures are not understood at this time. You can't just leave the analysis of threats and countermeasures to the reader. Thanks, Steve Hanna From new-work-bounces@ietf.org Thu Feb 17 10:12:23 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 166043A6E19; Thu, 17 Feb 2011 10:12:23 -0800 (PST) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2A13A6E2C for ; Thu, 17 Feb 2011 10:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.227 X-Spam-Level: X-Spam-Status: No, score=-10.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-xk284Y4eBb for ; Thu, 17 Feb 2011 10:12:21 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 003013A6E19 for ; Thu, 17 Feb 2011 10:12:20 -0800 (PST) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Pq8LS-000618-E0; Thu, 17 Feb 2011 13:12:50 -0500 Message-Id: <6EA67834-47AB-48CD-B6A7-178B4B45FBB8@w3.org> From: Ian Jacobs To: new-work@ietf.org Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 17 Feb 2011 12:12:50 -0600 X-Mailer: Apple Mail (2.936) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 21 Feb 2011 09:40:12 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Web Real-Time Communications Working Group (until 2011-03-18) 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, 17 Feb 2011 18:12:23 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to = revise the Ubiquitous Web Applications Activity [0] (see the W3C = Process Document description of Activity Proposals [1]). This proposal = includes a draft charter for the Web Real-Time Communications Working = Group: http://www.w3.org/2010/12/webrtc-charter As part of ensuring that the community is aware of proposed work at = W3C, this draft charter is public during the Advisory Committee review = period. W3C invites public comments through 2011-03-18 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 Fran=E7ois Daoust, Team Contact . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2007/uwa/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From dharkins@lounge.org Mon Feb 21 12:47:01 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 313033A6F5C; Mon, 21 Feb 2011 12:47:01 -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=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXhQmcsCDWSX; Mon, 21 Feb 2011 12:47:00 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 77A603A6F53; Mon, 21 Feb 2011 12:47:00 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2021F1022400A; Mon, 21 Feb 2011 12:47:43 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 21 Feb 2011 12:47:43 -0800 (PST) Message-ID: <921c32f070a0520ac880b4bf4b4d8404.squirrel@www.trepanning.net> Date: Mon, 21 Feb 2011 12:47:43 -0800 (PST) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-ietf-payload-rfc4695-bis-01.all@tools.ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [secdir] secdir review of draft-ietf-payload-rfc-4695-bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 20:47:01 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft fixes several errors that were found in RFC 4695. I reviewed the changes between RFC 4695 and this draft and found no issues that the Security ADs should be made aware of. The Security Considerations do not seem to have changed. The Security Considerations mention an issue in this draft (and RFC 4695) that can lessen RTP security. I am not suggesting a change to this draft but if the RTP community is interested in addressing this issue I believe it could be fixed by using AES-SIV (RFC 5297) instead of AES-CM (the XOR'd components of the IV used by AES-CM should become distinct, and unpadded, vector inputs to AES-SIV). regards, Dan. From weiler+secdir@watson.org Mon Feb 21 16:29:52 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70FBD3A67AC for ; Mon, 21 Feb 2011 16:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5a2zA6LtTTx for ; Mon, 21 Feb 2011 16:29:51 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 3F2033A677C for ; Mon, 21 Feb 2011 16:29:51 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p1M0UXZe025002 for ; Mon, 21 Feb 2011 19:30:33 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p1M0UXOm024999 for ; Mon, 21 Feb 2011 19:30:33 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 21 Feb 2011 19:30:33 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 21 Feb 2011 19:30:33 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 00:29:52 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Catherine Meadows is next in the rotation. For telechat 2011-03-03 Reviewer LC end Draft Alan DeKok T 2011-03-01 draft-ietf-hip-over-hip-05 Donald Eastlake T 2011-03-01 draft-ietf-6lowpan-usecases-09 Tobias Gondrom T 2011-03-01 draft-ietf-hip-cert-09 Love Hornquist-Astrand T 2011-02-21 draft-ietf-v6ops-v6-in-mobile-networks-03 Julien Laganier T 2011-02-11 draft-holsten-about-uri-scheme-06 Magnus Nystrom T 2011-02-23 draft-meadors-multiple-attachments-ediint-10 Radia Perlman T 2011-02-08 draft-mraihi-mutual-oath-hotp-variants-13 Sam Weiler TR2011-02-21 draft-ietf-sipcore-199-05 Tom Yu T 2011-02-22 draft-josefsson-rc4-test-vectors-02 For telechat 2011-03-17 Jeffrey Hutzelman T 2011-03-09 draft-zhu-mobility-survey-03 Barry Leiba T 2011-03-18 draft-zhu-mobileme-doc-04 Last calls and special requests: Rob Austein 2011-02-16 draft-ietf-netconf-rfc4742bis-06 Dave Cridland 2011-02-21 draft-ietf-sidr-arch-12 Alan DeKok 2011-02-23 draft-ietf-isis-reg-purge-00 Shawn Emery 2011-02-21 draft-ietf-ecrit-phonebcp-16 Phillip Hallam-Baker 2011-02-28 draft-ietf-morg-multimailbox-search-06 Sam Hartman 2011-02-21 draft-ietf-sidr-res-certs-21 Love Hornquist-Astrand 2011-03-16 draft-yevstifeyev-tn3270-uri-16 Charlie Kaufman - draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00 Scott Kelly 2011-03-18 draft-ietf-sipping-nat-scenarios-15 Stephen Kent 2011-03-04 draft-ietf-xcon-ccmp-12 Tero Kivinen 2011-03-04 draft-ietf-xcon-common-data-model-23 Julien Laganier 2011-03-04 draft-ietf-xcon-examples-08 Chris Lonvick R2011-03-17 draft-giralt-schac-ns-04 David McGrew - draft-ietf-ecrit-framework-12 David McGrew 2011-03-03 draft-ietf-sidr-iana-objects-01 Russ Mundy 2011-01-04 draft-cardona-cablelabs-urn-05 Russ Mundy 2011-02-17 draft-ietf-speermint-voipthreats-07 Vincent Roca 2011-02-07 draft-reed-urn-dgiwg-02 Sam Weiler 2011-02-16 draft-ietf-hokey-ldn-discovery-06 Brian Weis 2011-03-02 draft-herzog-static-ecdh-04 Nico Williams 2011-01-14 draft-yevstifeyev-http-headers-not-recognized-11 Nico Williams 2011-02-09 draft-ietf-rmt-bb-fec-raptorq-04 Glen Zorn 2011-02-10 draft-ietf-shim6-multihome-shim-api-16 From julien.ietf@gmail.com Mon Feb 21 16:33:47 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29713A67B0; Mon, 21 Feb 2011 16:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1jv6iUi+L68; Mon, 21 Feb 2011 16:33:47 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id AA48C3A67AA; Mon, 21 Feb 2011 16:33:46 -0800 (PST) Received: by fxm15 with SMTP id 15so3099026fxm.31 for ; Mon, 21 Feb 2011 16:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=mOq4PgErm1fTysaIdFiXBNn6Vtj3XBla1Qq50gDFTwU=; b=QHI/F5r5F8BoS+i3M6YIrl3ZtnvGXQodzLd5FG0Az8oEILwq8d0Fc6J1ECG0KLdEMC GBzlKN1wxiyn9c1q89UKf5KOSDJJD5Q9zSCOpVaPPFr9Ta4+oME/Cbb8IP7/ydDgFxbc lh18Q7tN2GepVS6Mk2vUMeN2Q1O3BDoVzCbcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=llU4bt6ploS88Dr+aLQmW75LnUiut34JVoUk412FS2AxhfLD17lSvLnumvjCeU5rD3 ETqHaMkwespol+5DP/lt6X5qaveEiBuVwRCsSw5UJ6JeYrZLGnX2rxZTohGOkAGSILV7 L5TLbQNXu0y6pxPMI8OXTO56pqg2ZyyGNNvz8= MIME-Version: 1.0 Received: by 10.223.74.206 with SMTP id v14mr2618114faj.66.1298334868912; Mon, 21 Feb 2011 16:34:28 -0800 (PST) Received: by 10.223.74.142 with HTTP; Mon, 21 Feb 2011 16:34:28 -0800 (PST) Date: Mon, 21 Feb 2011 17:34:28 -0700 Message-ID: From: Julien Laganier To: secdir@ietf.org, draft-holsten-about-uri-scheme.all@tools.ietf.org, iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] secdir review of draft-holsten-about-uri-scheme-06.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 00:33:48 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is a re-check. I still have no concerns with publication of this document. --julien From hallam@gmail.com Tue Feb 22 05:06:42 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 428023A688F; Tue, 22 Feb 2011 05:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzxY4Oh6O5Ub; Tue, 22 Feb 2011 05:06:41 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id BFDFC3A687C; Tue, 22 Feb 2011 05:06:40 -0800 (PST) Received: by bwz12 with SMTP id 12so3625203bwz.27 for ; Tue, 22 Feb 2011 05:07:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=K7+48PUAxKsH3Xcox+DcMTigVyrTh+8Atz3PbcCKDX8=; b=l/fMVmdgnxsR7sQPOue5q8FmTnKNFv3HxrG8e1Mp+nHCHuHm0qj+lWnRmZuSHTPpg5 JEX8NIuZSg6jFvop4N4d0GumxTCEmmbEmSyNTy3RhPD90MbXAG27qrH21GXxnZAsdmjL Bh/O7Ua8nYrTmaNRfDFdLkpv4sZfkWJ1uf6yc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=po2ZXQt34YwTbPlRcRzERm2vcXlHcEe8/ADexpP1K07azpKxpM85zh8aoZILvsB99M LrfGo3YHacnCsuu/y5egYHkjvoFbSAtwqcFuqji/648iUf6dRaj/e7qVC/SyrTOCyilc M9z+aNEYGH+mhlTiriHLrTf2PucwAFak35BhE= MIME-Version: 1.0 Received: by 10.204.71.141 with SMTP id h13mr2456632bkj.180.1298380043537; Tue, 22 Feb 2011 05:07:23 -0800 (PST) Received: by 10.204.14.139 with HTTP; Tue, 22 Feb 2011 05:07:23 -0800 (PST) Date: Tue, 22 Feb 2011 08:07:23 -0500 Message-ID: From: Phillip Hallam-Baker To: secdir@ietf.org, iesg@ietf.org, Barry Leiba , Alexey.Melnikov@isode.com Content-Type: multipart/alternative; boundary=0016e6dd8942474d98049cdea989 Subject: [secdir] SECDIR Review of draft-ietf-morg-multimailbox-search-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 13:06:42 -0000 --0016e6dd8942474d98049cdea989 Content-Type: text/plain; charset=ISO-8859-1 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 makes a minor adjustment to the search mechanism of imap, allowing searches to be made slightly more efficiently. As such, the only security concern that is impacted is resource consumption which is appropriately called out in the specification. -- Website: http://hallambaker.com/ --0016e6dd8942474d98049cdea989 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security dir= ectorate's
ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security
a= rea directors. =A0Document editors and WG chairs should treat these
comm= ents just like any other last call comments.

This document makes a minor adjustment to the search= mechanism of imap, allowing searches to be made slightly more efficiently.=

As such, the only security concern that is = impacted is resource consumption which is appropriately called out in the s= pecification.

--0016e6dd8942474d98049cdea989-- From kent@bbn.com Tue Feb 22 20:10:02 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF363A69B8 for ; Tue, 22 Feb 2011 20:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FSdlxrQpOaa for ; Tue, 22 Feb 2011 20:10:00 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 7F6C13A69B7 for ; Tue, 22 Feb 2011 20:10:00 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:53507 helo=[169.223.148.236]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Ps63o-000FCE-5w; Tue, 22 Feb 2011 23:10:46 -0500 Mime-Version: 1.0 Message-Id: Date: Tue, 22 Feb 2011 22:50:15 -0500 To: secdir@ietf.org From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-913688253==_ma============" Cc: mary.ietf.barnes@gmail.com, spromano@unina.it, hgs+xcon@cs.columbia.edu, chris@ns-technologies.com, rjsparks@nostrum.com Subject: [secdir] review of draft-ietf-xcon-ccmp-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 04:10:02 -0000 --============_-913688253==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable I reviewed this document=20 (draft-ietf-xcon-ccmp-12) as part of the security=20 directorate's ongoing effort to review all IETF=20 documents being processed by the IESG. These=20 comments were written primarily for the benefit=20 of the security area directors. Document editors=20 and WG chairs should treat these comments just=20 like any other last call comments. This long (111 page) document defines a protocol=20 (CCMP) to manage centralized conferencing=20 consistent with the XCON framework. It enables=20 users who are "authenticated and authorized" to=20 "create, manipulate, and delete conference=20 objects." I did not read the whole document. I=20 focused on the security considerations section=20 and sections referenced by it. The security considerations section is about 4=20 pages long, a pleasant change from the one=20 sentence or one paragraph SC sections I often=20 encounter. The SC section begins with a list of six security=20 requirements posited for CCMP. Each requirement=20 cites the relevant section of the document where=20 the mechanisms needed to fulfill the requirement=20 are described. This is a nice organizational=20 approach, but half of the requirements are=20 addressed in later subsections of the SC section,=20 not in the CCMP definition that forms the bulk of=20 this document. Also, requirement #6 strays from=20 the "requirement/reference" model, and provides=20 an inline description of RECOMMENDED DoS=20 mitigation strategies. It might be better if some=20 of the text associated with this requirement=20 (e.g., dealing with long request pending times)=20 were moved to the relevant section(s) of the=20 document. The remainder of the SC section is divided into 3=20 subsections, dealing with a client contacting the=20 "proper" conference server, user authentication=20 and authorization, and the security and privacy=20 of user identities. The first subsection (10.1) cites use of TLS=20 (with server certificates) as a secure transport,=20 to enable a user (as a client) to authenticate=20 the identity of the server to which the user is=20 connecting. The text calls for the server=20 certificate to attest to the IP address or DNS=20 name for the CMPP server, via a Subject=20 Alternative Name (SAN). However, the discussion=20 includes an odd sentence: "If the client has external information as to the=20 expected identity or credentials of the proper=20 conference server (e.g., a certificate=20 fingerprint), these checks MAY be omitted." It is not clear what the phrase "these checks"=20 refers to with respect to TLS checks on server=20 certificate validity. For example, does this mean=20 that the TLS implementation is supposed to allow=20 the user to provide a certificate fingerprint as=20 an input in lieu of the more common check of the=20 =46QDN portion of a URI against selected fields=20 from the server certificate? The HTTPS RFC (2818)=20 makes no mention of such a facility, and it is=20 outside the scope of the TLS RFC (5246). This=20 text needs to be clarified. A client would normally be expected to have a=20 priori knowledge of some form of server identity,=20 e.g., a FQDN. If the client is able to contact=20 the server it needs this info, and it needs this=20 info to be able to interpret the server=20 certificate as evidence of having contacted the=20 "proper" server. So the fist part of the sentence=20 above "If the client has external information as=20 to the expected identity =8A of the proper=20 conference server =8A" seems odd. The second=20 option here "=8A (e.g., a certificate fingerprint)"=20 is a different way of confirming that the proper=20 server has been contacted, but it would not be a=20 way of determining which server to contact in the=20 first place. This text needs to be expanded upon=20 to provide an unambiguous characterization of the=20 intended security requirement. Section 7 of the document describes how to=20 determine the proper server (fulfilling=20 requirement #1 from the SC section), if it is not=20 pre-configured. That section calls for use of the=20 DNS (via U-NAPTR resolution) to acquire a URI for=20 the server. If a URI is the server ID, then it=20 makes sense to requires use of a FQDN SAN in a=20 server certificate. (I am surprised that the=20 document suggests an IP address SAN as an option=20 for the server certificate; who prefers=20 hard-wired addresses over DNS names?) There is no=20 mention in Section 7 of a certificate=20 fingerprint, so I suggest removing this text.=20 Also, there should be some discussion of the role=20 of DNSSEC here, i.e., if one is relying on NAPTR=20 resolution to locate the proper CMPP server, a=20 spoofed DNS reply can lead the user to the wrong=20 server (even if the user can authenticate that=20 server, via TLS). Section 10.2 describes the need for a user to=20 authenticate to a conference server, and it=20 RECOMMENDs use of TLS, or use of a call signaling=20 protocol. This text is a bit vague, as it does=20 not cite any specific call signaling protocols.=20 It says "In the cases where a user is authorized=20 via multiple mechanisms, it is RECOMMENDED that=20 the conference server correlate the authorization=20 of the CCMP interface with other authorization=20 mechanisms - e.g., PSTN users that join with a=20 PIN and control the conference using CCMP." The term=20 "correlate" is ambiguous in this context. =46or a user employing CMPP, the text does not=20 indicate whether the RECOMMENDATION is for TLS to=20 be used to protect a password sent to a CMPP=20 server, or whether a user certificate is the=20 goal. This text needs further clarification. The discussion of a "conference user identifier"=20 in Section 3.2 (and in other sections) is not=20 precise. Perhaps the XCON framework doc makes=20 this concept clear, but it should be restated=20 here for completeness. There is a paragraph in this section discussing=20 Role-based access control. It is unnecessarily=20 vague. In an RBAC context The user ID would be a role that is occupied by=20 an authorized user. The text here does not make=20 this as clear as it could (should) be. The final subsection of this document (10.3)=20 deals with security and privacy for user=20 identities. The writing in this subsection needs=20 help as there are a number of indefinite=20 antecedents for pronouns scattered throughout=20 (and mismatches in number). Nonetheless, the=20 privacy requirements put forth seem fairly=20 simple. However, the text does not note that the=20 CMPP server will know the identity of each=20 participant (in order to implement the=20 authorization functions in 10.2) and thus user=20 anonymity needs to be interpreted in that=20 context. (If the user authenticates in the=20 context of a role some additional privacy may be=20 offered, but that too is not discussed.) I saw no=20 mention of whether CMPP provides a way for=20 participants in a conference to be made aware of=20 whether they may be anonymous or invisible=20 participants on a call. It seems that this might=20 be a reasonable feature to offer, if one offers=20 the privacy features discussed here. --============_-913688253==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable review of draft-ietf-xcon-ccmp-12
I reviewed this document (draft-ietf-xcon-ccmp-12) 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 long (111 page) document defines a protocol (CCMP) to manage centralized conferencing consistent with the XCON framework. It enables users who are "authenticated and authorized" to "create, manipulate, and delete conference objects." I did  not read the whole document. I focused on the security considerations section and sections referenced by it.

The security considerations section is about 4 pages long, a pleasant change from the one sentence or one paragraph SC sections I often encounter.

The SC section begins with a list of six security requirements posited for CCMP. Each requirement cites the relevant section of the document where the mechanisms needed to fulfill the requirement are described. This is a nice organizational approach, but half of the requirements are addressed in later subsections of the SC section, not in the CCMP definition that forms the bulk of this document. Also, requirement #6 strays from the "requirement/reference" model, and provides an inline description of RECOMMENDED DoS mitigation strategies. It might be better if some of the text associated with this requirement (e.g., dealing with long request pending times) were moved to the relevant section(s) of the document.

The remainder of the SC section is divided into 3 subsections, dealing with a client contacting the "proper" conference server, user authentication and authorization, and the security and privacy of user identities.

The first subsection (10.1) cites use of TLS (with server certificates) as a secure transport, to enable a user (as a client) to authenticate the identity of the server to which the user is connecting. The text calls for the server certificate to attest to the IP address or DNS name for the CMPP server, via a Subject Alternative Name (SAN). However, the discussion includes an odd sentence:

"If the client has external information as to the expected identity or credentials of the proper conference server (e.g., a certificate fingerprint), these checks MAY be omitted."

It is not clear what the phrase "these checks" refers to with respect to TLS checks on server certificate validity. For example, does this mean that the TLS implementation is supposed to allow the user to provide a certificate fingerprint as an input in lieu of the more common check of the FQDN portion of a URI against selected fields from the server certificate? The HTTPS RFC (2818) makes no mention of such a facility, and it is outside the scope of the TLS RFC (5246). This text needs to be clarified.

A client would normally be expected to have a priori knowledge of some form of server identity, e.g., a FQDN. If the client is able to contact the server it needs this info, and it needs this info to be able to interpret the server certificate as evidence of having contacted the "proper" server. So the fist part of the sentence above "If the client has external information as to the expected identity =8A of the proper conference server =8A" seems odd.  The second option here "=8A (e.g., a certificate fingerprint)" is a different way of confirming that the proper server has been contacted, but it would not be a way of determining which server to contact in the first place. This text needs to be expanded upon to provide an unambiguous characterization of the intended security requirement.

Section 7 of the document describes how to determine the proper server (fulfilling requirement #1 from the SC section), if it is not pre-configured. That section calls for use of the DNS (via U-NAPTR resolution) to acquire a URI for the server. If a URI is the server ID, then it makes sense to requires use of a FQDN SAN in a server certificate. (I am surprised that the document suggests an IP address SAN as an option for the server certificate; who prefers hard-wired addresses over DNS names?) There is no mention in Section 7 of a certificate fingerprint, so I suggest removing this text. Also, there should be some discussion of the role of DNSSEC here, i.e., if one is relying on NAPTR resolution to locate the proper CMPP server, a spoofed DNS reply can lead the user to the wrong server (even if the user can authenticate that server, via TLS).

Section 10.2 describes the need for a user to authenticate to a conference server, and it RECOMMENDs use of TLS, or use of a call signaling protocol. This text is a bit vague, as it does not cite any specific call signaling protocols. It says "In the cases where a user is authorized via multiple mechanisms, it is RECOMMENDED that the conference server correlate the authorization of the CCMP interface with other authorization mechanisms - e.g., PSTN users that join with a PIN and
control the conference using CCMP." The term "correlate" is ambiguous in this context.
 
=46or a user employing CMPP, the text does not indicate whether the RECOMMENDATION is for TLS to be used to protect a password sent to a CMPP server, or whether a user certificate is the goal. This text needs further clarification.

The discussion of a "conference user identifier" in Section 3.2 (and in other sections) is not precise.  Perhaps the XCON framework doc makes this concept clear, but it should be restated here for completeness.

There is a paragraph in this section discussing Role-based access control.  It is unnecessarily vague. In an RBAC context
The user ID would be a role that is occupied by an authorized user. The text here does not make this as clear as it could (should) be.
The final subsection of this document (10.3) deals with security and privacy for user identities.  The writing in this subsection needs help as there are a number of indefinite antecedents for pronouns scattered throughout (and mismatches in number). Nonetheless, the privacy requirements put forth seem fairly simple. However, the text does not note that the CMPP server will know the identity of each participant (in order to implement the authorization functions in 10.2) and thus user anonymity needs to be interpreted in that context. (If the user authenticates in the context of a role some additional privacy may be offered, but that too is not discussed.) I saw no mention of whether CMPP provides a way for participants in a conference to be made aware of whether they may be anonymous or invisible participants on a call. It seems that this might be a reasonable feature to offer, if one offers the privacy features discussed here.
--============_-913688253==_ma============-- From tlyu@mit.edu Tue Feb 22 20:12:37 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D05A03A69A1; Tue, 22 Feb 2011 20:12: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKp-FHV+6W2G; Tue, 22 Feb 2011 20:12:37 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by core3.amsl.com (Postfix) with ESMTP id E2BA33A67F5; Tue, 22 Feb 2011 20:12:36 -0800 (PST) X-AuditID: 1209190e-b7b3bae000000a71-67-4d6489620365 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-3.mit.edu (Symantec Brightmail Gateway) with SMTP id 11.19.02673.269846D4; Tue, 22 Feb 2011 23:13:22 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p1N4DMJ2019600; Tue, 22 Feb 2011 23:13:22 -0500 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p1N4DHsU008690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Feb 2011 23:13:18 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id p1N4DH82012890; Tue, 22 Feb 2011 23:13:17 -0500 (EST) To: secdir@ietf.org, iesg@ietf.org, draft-josefsson-rc4-test-vectors.all@tools.ietf.org From: Tom Yu Date: Tue, 22 Feb 2011 23:13:17 -0500 Message-ID: Lines: 25 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: AAAAAA== Subject: [secdir] secdir review of draft-josefsson-rc4-test-vectors-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 04:12:37 -0000 The Security Considerations section states: The RC4 algorithm does not meet the basic criteria required for an encryption algorithm, as its output is distinguishable from random. The use of RC4 continue to be recommended against; in particular, its use in new specifications is discouraged. This note is intended only to aid the interoperability of existing specifications that make use of RC4. I believe this statement is accurate, and have nothing substantial to add to it. Comments not directly relevant to security follow. Section 5 ("Copying conditions") states: This document is intended to be considered a Code Component, and is thus effectively available under the Simplified BSD license. I think it would be reasonable to say that Section 2 qualifies as a Code Component; the case for the other sections being considered as Code Components is tenuous, in my opinion. Editorial: In Section 1, "crypto-analysis" should probably be "cryptanalysis". From barryleiba.mailing.lists@gmail.com Fri Feb 25 12:19:04 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 034C43A6A26; Fri, 25 Feb 2011 12:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.863 X-Spam-Level: X-Spam-Status: No, score=-102.863 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWjRPtr0Nonx; Fri, 25 Feb 2011 12:19:03 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 28E773A6A0E; Fri, 25 Feb 2011 12:19:03 -0800 (PST) Received: by iwl42 with SMTP id 42so1577556iwl.31 for ; Fri, 25 Feb 2011 12:19:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=D+AAbWMolHRqa2NnZxRejnLLeJ58assWbYSbIQM9UIo=; b=fY7yODrkCnTrC2C6TirRTFJxc9sTVr9esfnoarTwiP19kKaEByygmkLfcXONEe3iQs D1NkzC3TfU8P1vkBxTLcgCoNRxJsCGvQAfAgTEZUzYZst3WvNidFNW97HTRzd7EQg10D edj9mFfhzf8j6tmf5qluCer3Sv63+16FrRnxQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=lEcCy4KmQAwF0Uh7Op0ZW2r8N32RZ4nNs3VuTByfCw1C0M8Z2tXKFt7mM5+5lifO6X kSsxEt1Rv/lArB4txLmNO+xmgI+mnLM60cOqH/RWjtryPTJRAD1pmiIWjubhKI4Yq2wX T6Dx12yjzLtiVQI7oPkMgaL6iCULDq2kRGHlU= MIME-Version: 1.0 Received: by 10.43.62.198 with SMTP id xb6mr1243876icb.387.1298665196283; Fri, 25 Feb 2011 12:19:56 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.229.67 with HTTP; Fri, 25 Feb 2011 12:19:56 -0800 (PST) Date: Fri, 25 Feb 2011 15:19:56 -0500 X-Google-Sender-Auth: yBLCRHfHVvut-okq5G8zkymEPsY Message-ID: From: Barry Leiba To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-zhu-mobileme-doc.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] secdir review of draft-zhu-mobileme-doc-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 20:19:04 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is informational, and documents a system in use (and quite successfully so) by Apple. It's a well-written description that appears to be thorough, and I have to trust that it's accurate and complete (it seems to be). Because it's documenting what's already there, it wouldn't be appropriate to look to change things, in general, except to ask for clarifications -- and there's nothing I think I want clarified. And for what it's worth, the security aspects of the BTMM service look quite solid. It's ready to publish. Barry From radiaperlman@gmail.com Fri Feb 25 22:35:00 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 252003A68E9; Fri, 25 Feb 2011 22:35:00 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S557HsT7k4Iu; Fri, 25 Feb 2011 22:34:58 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id D2ED33A6924; Fri, 25 Feb 2011 22:34:57 -0800 (PST) Received: by iyj8 with SMTP id 8so1674461iyj.31 for ; Fri, 25 Feb 2011 22:35:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=pgUdYcaMbh9F+eH6nMmv2ErJhiGXlITietvckQBx3p0=; b=TcoRVwAUtmatYneKJMsktMZqlDkJWiKAj/pdQGXJ69AzkYJyKPoGFXUpB9R1H4ywuf Eb2NCLBJzgeVLg9hrQeDOPQsLJccoJafMwlWc1HMvNUpK2eF0G5JrRdQWIT4nQsTA7jI IUigq8/akoYry0QMfnpGWnWKqthaVn7Nj0NII= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YqRwr+gv71JJqVCkoUVcz6qJRcTS6Qdx0dRzHqkgo0Wo07zXnYCuiNDVGkJm9q/tcd 1UrWA2pNh2oYLXMtGTeK4L8UYA5u+bi2quYEawC3MICfeAgy8cxIIwqIjDasb871Gfy0 1NH/6VU0A7UfS8CFAtCczoCcLD3ClurA2Kvqc= MIME-Version: 1.0 Received: by 10.42.218.6 with SMTP id ho6mr1869967icb.1.1298702151869; Fri, 25 Feb 2011 22:35:51 -0800 (PST) Received: by 10.43.59.2 with HTTP; Fri, 25 Feb 2011 22:35:51 -0800 (PST) Date: Fri, 25 Feb 2011 22:35:51 -0800 Message-ID: From: Radia Perlman To: draft-mraihi-mutual-oath-hotp-variants@tools.ietf.org, secdir@ietf.org, iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] SECDIR review of draft-mraihi-mutual-oath-hotp-variants-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 06:35:00 -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. I found the document quite difficult to understand, even though it was relatively short. Part of what makes it hard to read is due to terminology, like using "signature" to mean, (I think), simply a response to a challenge, rather than (how I would use the term) an integrity check on a message. This was especially confusing because in section 3, requirement R2 claims that OCRA will generate a symmetric key digital signature on a message, whereas the "signature variant" in section 7.3 seems to be just the same as challenge/response, other than omitting the input that I'd call "channel binding", (but they call "S".) Personally I don't like the term OTP to mean the general type of thing generated by one of these crypto token cards, since I think of it as the specific OTP protocol (RFC 2289), but apparently wikipedia defines OTP as based on a token display value, so it must be correct, and I'll adapt. :-) I also don't like the term "random questions" to mean a challenge. To me, "random questions" is when a verifier knows a bunch of human-rememberable questions, and asks a random subset of them to the human. It's particularly hard to understand a document when the same quantity is sometimes referred to as a "challenge" and sometimes as a "question". To their credit, code is included, which helped in some cases for me to clarify what was going on when I was having trouble understanding the prose. There also seems to be unnecessary complexity, like including a hash of the PIN rather than simply the PIN, into the inputs of the function, and the truncation function that, rather than simply taking the first n bits or the last n bits, uses the last 4 bits of the hash to determine where in the hash to take the 32 bits. With 32 bits of the hash to compute as a digital value, the algorithm supports up to 10 decimal digits. That would mean that if you use 10 digits, given that 32 bits is just 4 billion, the first digit will never be more than 4. I do understand why it would be nice to have an open standard for these sort of token devices, so that people can build interoperable tokens and verifiers. But I don't understand the need for all the variations in OCRA, especially when imagining the user having to type in a lot of values. It's hard enough to type in a PIN, but then also typing in channel bindings, challenges to the server, etc., make it hard for me to imagine a human putting up with this. Mysteriously to me, requirement R7 says that the challenge might have integrity checking, so that the device can notice and inform the user if the user mistypes the challenge. But what about the PIN and the channel bindings? Wouldn't that be just as important to catch an honest user mistake? The document does not explain how to verify a response, and I think if it did, it would be clear that the mutual authentication will not work if it included a counter and/or timestamp. These values are not necessarily synchronized at client and server, so the server would have to test several plausible inputs, and if both are used, if there are k plausible counter values, and n plausible timestamps, it would be k*n possible values to test. The spec assumes that the token card will display the (single) value that the server transmits, and the user will compare it against the display. I also find it a bit mysterious that the PIN is an input into what the client sends, but not in what the server responds. The server needs to know the PIN in order to verify what the client sends, so I can't quite see the reason for the asymmetry. What does the sentence "The server SHOULD also provide whenever possible a mean for the client (if able) to verify the validity of the signature challenge." mean? Radia From weiler@watson.org Sat Feb 26 03:42:35 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BDC13A681C; Sat, 26 Feb 2011 03:42:35 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bi2kKO0Xlupp; Sat, 26 Feb 2011 03:42:34 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 0E8C23A67D4; Sat, 26 Feb 2011 03:42:33 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p1QBhQKv000404; Sat, 26 Feb 2011 06:43:26 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p1QBhPqW000397; Sat, 26 Feb 2011 06:43:26 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 26 Feb 2011 06:43:25 -0500 (EST) From: Samuel Weiler To: Barry Leiba , Alexey.Melnikov@isode.com In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Sat, 26 Feb 2011 06:43:26 -0500 (EST) Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR Review of draft-ietf-morg-multimailbox-search-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 11:42:35 -0000 On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote: > This document makes a minor adjustment to the search mechanism of > imap, allowing searches to be made slightly more efficiently. If the user specifies some mailbox(es) which she doesn't have access rights to AND some mailbox(es) which she can access, the doc says to IGNORE the ones she can't access. Wouldn't it be more useful to send an error for those mailboxes rather than silently fail? Also, the security considerations says: Implementations MUST, of course, apply access controls appropriately, limiting a user's access to ESEARCH in the same way its access is limited for any other IMAP commands. This extension has no data- access risks beyond what may be there in the unextended IMAP implementation. Are there any other IMAP commands that access multiple mailboxes at once? If not, if might be worth repeating some of the text in section 2, just to call out the new case that must be checked. From weiler+secdir@watson.org Sat Feb 26 03:56:33 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57D103A6857 for ; Sat, 26 Feb 2011 03:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkCircARw89X for ; Sat, 26 Feb 2011 03:56:32 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id DC5183A6856 for ; Sat, 26 Feb 2011 03:56:31 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p1QBvQsg003641 for ; Sat, 26 Feb 2011 06:57:26 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p1QBvQGu003638 for ; Sat, 26 Feb 2011 06:57:26 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 26 Feb 2011 06:57:26 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Sat, 26 Feb 2011 06:57:26 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 11:56:33 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Hilarie Orman is next in the rotation. For telechat 2011-03-03 Reviewer LC end Draft Rob Austein T 2011-02-16 draft-ietf-netconf-rfc4742bis-07 Alan DeKok T 2011-03-01 draft-ietf-hip-over-hip-05 Donald Eastlake T 2011-03-01 draft-ietf-6lowpan-usecases-09 Tobias Gondrom T 2011-03-01 draft-ietf-hip-cert-09 Love Hornquist-Astrand T 2011-02-21 draft-ietf-v6ops-v6-in-mobile-networks-03 Russ Mundy T 2011-02-17 draft-ietf-speermint-voipthreats-07 Tina TSOU TR2011-02-07 draft-ietf-netconf-4741bis-09 Sam Weiler TR2011-02-21 draft-ietf-sipcore-199-05 Sam Weiler T 2011-02-16 draft-ietf-hokey-ldn-discovery-06 Glen Zorn T 2011-02-10 draft-ietf-shim6-multihome-shim-api-16 For telechat 2011-03-17 Jeffrey Hutzelman T 2011-03-09 draft-zhu-mobility-survey-03 Catherine Meadows T 2011-03-09 draft-ietf-ancp-protocol-15 Kathleen Moriarty T 2011-03-11 draft-ietf-intarea-server-logging-recommendations-03 Magnus Nystrom T 2011-02-23 draft-meadors-multiple-attachments-ediint-10 Magnus Nystrom T 2011-03-10 draft-ietf-ipsecme-failure-detection-05 Carl Wallace TR2011-02-22 draft-herzog-setkey-03 For telechat 2011-04-14 Sandy Murphy T 2011-03-23 draft-kanno-tls-camellia-00 Last calls and special requests: Dave Cridland 2011-02-21 draft-ietf-sidr-arch-12 Alan DeKok 2011-02-23 draft-ietf-isis-reg-purge-00 Shawn Emery 2011-02-21 draft-ietf-ecrit-phonebcp-16 Sam Hartman 2011-02-21 draft-ietf-sidr-res-certs-21 Love Hornquist-Astrand 2011-03-16 draft-yevstifeyev-tn3270-uri-16 Charlie Kaufman 2011-03-08 draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00 Scott Kelly 2011-03-18 draft-ietf-sipping-nat-scenarios-15 Tero Kivinen 2011-03-04 draft-ietf-xcon-common-data-model-23 Julien Laganier 2011-03-04 draft-ietf-xcon-examples-08 Matt Lepinski 2011-03-08 draft-ietf-dime-nat-control-07 Chris Lonvick R2011-03-17 draft-giralt-schac-ns-04 David McGrew - draft-ietf-ecrit-framework-12 David McGrew 2011-03-03 draft-ietf-sidr-iana-objects-01 Russ Mundy 2011-01-04 draft-cardona-cablelabs-urn-05 Vincent Roca 2011-02-07 draft-reed-urn-dgiwg-02 Brian Weis 2011-03-02 draft-herzog-static-ecdh-05 Nico Williams 2011-01-14 draft-yevstifeyev-http-headers-not-recognized-11 Nico Williams 2011-02-09 draft-ietf-rmt-bb-fec-raptorq-04 From barryleiba@gmail.com Sat Feb 26 06:47:46 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F6B03A6944; Sat, 26 Feb 2011 06:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.879 X-Spam-Level: X-Spam-Status: No, score=-102.879 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ym7kNLl16Tl; Sat, 26 Feb 2011 06:47:45 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6A9E83A68D4; Sat, 26 Feb 2011 06:47:45 -0800 (PST) Received: by iwl42 with SMTP id 42so2113047iwl.31 for ; Sat, 26 Feb 2011 06:48:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JZP2If7pLGDu2wTaWoEZRpA6mcFdhs6GZ9UEsl0maS0=; b=Wjug5uK0v4aacSIkwhY9rncQAuj5Q0rKAGoEB2OqZQJyEUyG8cmUIjXPHLV9h1Qi4U fPsrDhNlF28rRY4kREcwEd4s4vcKzwCe2DA4fpKpJ1AsjA36njMvaF8HJARNpGsMNPTS Y1MX6lLilmq/4rnIONMocRcFZmhey786WNh3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Zg4WzDVPqHZf+Vrs4H1+xyAnniZgp9Yy8lvT8f71kmw7hp0gIl6+YjdEGlTdBKoRSp 7jmH2ldw/pLnfRcsU2jtperiOAjLcvf0ICLRHlAGS4YgExoGV5KLiKHVj0hAuYq1BH9k s1nUXvceypmFJewMPMSFi2JzfY7fvfrpoW0P8= MIME-Version: 1.0 Received: by 10.42.213.194 with SMTP id gx2mr2351158icb.39.1298731720220; Sat, 26 Feb 2011 06:48:40 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.231.38.13 with HTTP; Sat, 26 Feb 2011 06:48:40 -0800 (PST) In-Reply-To: References: Date: Sat, 26 Feb 2011 09:48:40 -0500 X-Google-Sender-Auth: V-kvS9fZe9T_GWQkVRqckYHc00A Message-ID: From: Barry Leiba To: Samuel Weiler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexey.Melnikov@isode.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR Review of draft-ietf-morg-multimailbox-search-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 14:47:46 -0000 > If the user specifies some mailbox(es) which she doesn't have access righ= ts > to AND some mailbox(es) which she can access, the doc says to IGNORE the > ones she can't access. =A0Wouldn't it be more useful to send an error for > those mailboxes rather than silently fail? Perhaps, but it seemed to be the consensus of the client folks that it didn't matter, and it would be more useful to them to have the command succeed as long as there were some "valid" mailboxes in the list. We could allow the command to succeed and return results for the good mailboxes, and untagged error responses to indicate the bad ones. But we'd only want that for ones explicitly specified, not those that are implicitly included. For example, using the command from the example: C: tag1 ESEARCH IN (mailboxes "folder1" subtree "folder2") unseen If "folder1" or "folder2" doesn't exist (or the user has no access), notification of that might be appropriate. But if, say, "folder2/aaa" and "folder2/bbb" both exist and the user has access to the former and not the latter, sending an error for "folder2/bbb" would give away information. We wouldn't want this to become a way to probe for mailbox names. Apart from that, we'd have to define a new way to indicate the situation, perhaps with a further extension to the ESEARCH response. We have a response code "NONEXISTENT" that we can use for single mailboxes, putting it on a tagged or untagged "NO": C: tag1 RENAME folder1 folderX S: tag1 NO [NONEXISTENT] failed because folder1 doesn't exist But if you get this: C: tag1 ESEARCH IN (mailboxes "folder1" subtree "folder2") unseen S: * NO [NONEXISTENT] failed because folder1 doesn't exist S: * ESEARCH (TAG "tag1" MAILBOX "folder2" UIDVALIDITY 1) UID ALL 4001,4003,4005,4007,4009 S: tag1 OK done ...then the client doesn't know which mailbox(es) failed, because the text after the response code isn't machine parsable. We'd have to extend the ESEARCH response for it, somewhat like this: S: * ESEARCH [NONEXISTENT] (TAG "tag1" MAILBOX "folder1") We could certainly do that, but given that the only ways this can happen is through a serious client bug or another client's deleting or renaming "folder1" out from under this client, that the latter doesn't actually happen very often, that client developers have already told us that they don't care, and that clients that get it wrong may expose information about inaccessible mailboxes... it's best to leave it as it is. > Are there any other IMAP commands that access multiple mailboxes at once? > =A0If not, if might be worth repeating some of the text in section 2, jus= t to > call out the new case that must be checked. Apart from LIST, this is the first such IMAP command. I'd be happy to repeat or refer to some of the text from section 2 in the security considerations. Barry From tobias.gondrom@gondrom.org Sat Feb 26 14:46:32 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDC4B3A68BC for ; Sat, 26 Feb 2011 14:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 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, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCdebMkmX8+L for ; Sat, 26 Feb 2011 14:46:31 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 57A6E3A6960 for ; Sat, 26 Feb 2011 14:46:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=PlwknsLVeYuv4EdljpdEY3YSv8yVWdl3zRWLQ261ygAKOyWP1etMfgyJWdMDVP6nxuNtbPkXaWS7TZ2IrVv8JCmzxZiI9/oJZSitNbtGoFgqnFQ2afmC7pf/4TUq8QRs; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 1466 invoked from network); 26 Feb 2011 23:46:42 +0100 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Feb 2011 23:46:42 +0100 Message-ID: <4D6982E8.2040607@gondrom.org> Date: Sat, 26 Feb 2011 22:47:04 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101206 SUSE/3.1.7 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: secdir@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-hip-cert.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Secdir review of draft-ietf-hip-cert-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 22:46:32 -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 draft is experimental and specifies for the Host Identity Protocol (HIP, RFC5201, experimental) the certificate parameter and the error signaling in case of a failed verification. >From the security perspective, the considerations in this document appear to be overall sufficient (note that RFC5201 already covers several of the security consideration scenarios of the base protocol). A few small comments: 1. section 2.CERT 2nd paragraph: "The CERT parameter is covered, when present, by the HIP SIGNATURE field and is a non-critical parameter." Not sure it is sufficiently clear what you mean by "covered", maybe the word "protected" is better in this context. 2. Personally I would have liked to see at least one user scenario for the CERT with this document, but acknowledge that the document intentionally excludes such use cases (though I do understand why they would not want to provide an example). 3. section 2.CERT 8th paragraph: expand "HIT" on first use => "HIT (Host Identity Tag)" or introduce abbrevation in abstract "Host Identity Tags" => "Host Identity Tags (HIT)" 4. the authors should run idnits when submitting the documents: "There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. - line 356: Found possible IPv6 address '2001:13:724d:f3c0:6ff0:33c2:15d8:5f50' in position 53 in the paragraph; this doesn't match RFC 3849's suggested 2001:DB8::/32 address range or RFC 4193's Unique Local Address range FC00::/7. - and line 537: Found possible IPv6 address '2001:15:2453:698a:9aa:253a:dcb5:981e' in position 264 in the paragraph; this doesn't match RFC 3849's suggested 2001:DB8::/32 address range or RFC 4193's Unique Local Address range FC00::/7." Best regards, Tobias From magnusn@gmail.com Sat Feb 26 19:54:20 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163E53A69AD; Sat, 26 Feb 2011 19:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5oQge+wS1ns; Sat, 26 Feb 2011 19:54:18 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id C0EA53A69AA; Sat, 26 Feb 2011 19:54:18 -0800 (PST) Received: by iyj8 with SMTP id 8so2224390iyj.31 for ; Sat, 26 Feb 2011 19:55:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=iPYRgMBoZfGI8V+2y3FUcJkfCyH1aK3o2rQE4bMu7iI=; b=g6wFPWpPXmXdJhKDwAYiNgYU/ybLR8IlR+rtXxfbWhDU3PpcP4QRs69rtx5EMylmId 6TChsn7L0IEJs4EwoLoaKWCtpWb9Fw15V5yrdASKc/ZW6Pzew19kPj7RApsPpcJyPz1m CfSqAi8/A2jEB87QaK8rRfkeY71nIi63VfRLg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Z0C79m/VPSjcA5Y1WAuwDz4Apg7hdLYpteJO2Q9X1KBnZvg0sQmBzyXVSDyFJVO6tn pC+E6AzOhwAtiiIzG63PNiS7WNqzlZrsOr4b/EzqgiFbmslQSHXY7j4hVsURlg4Cnef5 lRcn4Ze6Xe7c918iO5oCT0oA64iCrgVSoNq9c= MIME-Version: 1.0 Received: by 10.231.32.133 with SMTP id c5mr1220771ibd.115.1298778915289; Sat, 26 Feb 2011 19:55:15 -0800 (PST) Received: by 10.231.31.70 with HTTP; Sat, 26 Feb 2011 19:55:15 -0800 (PST) Date: Sat, 26 Feb 2011 19:55:15 -0800 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: draft-meadors-multiple-attachments-ediint@tools.ietf.org, secdir@ietf.org, iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [secdir] Secdir review of draft-meadors-multiple-attachments-ediint-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 03:54: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. =A0These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines how to carry multiple, related EDI documents in MIME using the multipart/related content-type and how to calculate message integrity codes over such related documents. Section 2.3: a) Reference to MIC computation in EDIINT compression should be to Section 4, not Section 2 of RFC 5402. b) For clarity, may want to replace the text "When a digital signature is applied to the multipart/related envelope, the MIC is calculated on the entire multipart/related envelope, including the MIME header and all attached documents." with: "When a digital signature is applied to the multipart/related envelope, the MIC is calculated on the entire multipart/related envelope, including the multipart/related MIME header and all attached documents." c) Similarly, (as the sender performs the MIC calculation before encrypting) I would suggest replacing: "For an encrypted but unsigned and uncompressed message, the MIC is calculated on the decrypted multipart/related envelope, including header and all attached documents." with: "For an encrypted but unsigned and uncompressed message, the MIC is calculated on the unencrypted multipart/related envelope, including the multipart/related header and all attached documents." d) I don't understand: "or an unsigned and unencrypted message, the MIC is calculated over the data inside the multipart/related boundaries prior to Content- Transfer-Encoding. However, unsigned and unencrypted messages SHOULD not be sent due to lack of security.": Why do the MIC-calculation on the internal data only? Why not use the same algorithm (i.e. include the outermost multipart/related MIME header?). Also, should not canonicalization be carried out in this case? Section 3: - May be useful to use micalg SHA-256 (I realize this is an example, but generally we'd like to move in this direction and so examples should encourage it)? Section 4: - May be worthwhile to reference to S/MIME (RFC 5751) for Security considerations in general for signed multipart/related messages. -- Magnus From d3e3e3@gmail.com Sun Feb 27 19:42:25 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4C03A6998; Sun, 27 Feb 2011 19:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.252 X-Spam-Level: X-Spam-Status: No, score=-104.252 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJWIyEJ4Pnmz; Sun, 27 Feb 2011 19:42:25 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 7A9AD3A698D; Sun, 27 Feb 2011 19:42:24 -0800 (PST) Received: by wyb42 with SMTP id 42so3558233wyb.31 for ; Sun, 27 Feb 2011 19:43:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=05zEgxLRHDz7ysBRqkIIOzIm74JT4WWNG0DR4LVYHew=; b=DJUUh+dsZKHmX6daCLrZ5eV3m2Zuk0IRD3J+Ujw/fETq5m6KNxt5WyTgxAcoP0PFht KV1IofLhP4XJALdmg2iVHbM0x39Arn1EO2VCGPL0EIdgGOKSUhQW1bbgI2HeNWM7jseo s89G2IfsIPooQPouO8SsNq9r8K+dUUaQMzrY8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=xr3A4kbziAYoom34kMsBWMxNioSpP7AzbZ8k6u3zXprjPMaMQBh4qhvJJgq6UBtT7h HrS2ynu7ih22jO3bSUcKeXyKHG3lz6YJbDK5lqoMHeXdbqdZsCb/XAUm+kApdyziGRVR ZL2KtR15eFrPUWrSdMrcPGuKPq473YIFBgqDk= Received: by 10.227.9.222 with SMTP id m30mr4461270wbm.211.1298864603160; Sun, 27 Feb 2011 19:43:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.68.140 with HTTP; Sun, 27 Feb 2011 19:43:03 -0800 (PST) From: Donald Eastlake Date: Sun, 27 Feb 2011 22:43:03 -0500 Message-ID: To: iesg@ietf.org, secdir@ietf.org, draft-ietf-6lowpan-usecases.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [secdir] SECDIR review of draft-ietf-6lowpan-usecases-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 03:42:25 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments As you might guess from the draft name, this is an informational document describing a number of use cases for low-power wireless personal area networks. The security considerations section, reasonably enough, briefly indicates why different use cases may have considerably different security requirements and what some types of such security requirements could be. The thing that I think is lacking is some hint as to where to look to find possible mechanisms to meet those requirements. For this type of document, no detailed analysis of mechanisms is needed. But I would feel better if a sentence could be added such as follow (with some alternative wording in square brackets): "These varied security requirement [can commonly][are expected to] be met by the use of mechanisms such as IPsec and IKE, TLS, or 802.15.4 link security.". If there is an appropriate security mechanism survey document that would be fine. I did look at RFC 4919 as something that could be referenced and it seems too preliminary and tentative. RFC 4944 is only a little better. Perhaps there should be a reference to draft-qiu-6lowpan-secure-router at least as an example of work in progress in this area. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From weiler@watson.org Mon Feb 28 14:24:59 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2D863A6C97; Mon, 28 Feb 2011 14:24:58 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+qyjZJXvWcs; Mon, 28 Feb 2011 14:24:58 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 21A403A6C6E; Mon, 28 Feb 2011 14:24:57 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p1SMPw83058226; Mon, 28 Feb 2011 17:25:58 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p1SMPvaY058222; Mon, 28 Feb 2011 17:25:58 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 28 Feb 2011 17:25:57 -0500 (EST) From: Samuel Weiler To: iesg@ietf.org, secdir@ietf.org, draft-ietf-hokey-ldn-discovery.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, 28 Feb 2011 17:25:59 -0500 (EST) Subject: [secdir] secdir review of draft-ietf-hokey-ldn-discovery-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 28 Feb 2011 22:24:59 -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. There is a big risk here, and the security considerations section captures it very succinctly: "The communication ... is security sensitive and requires authentication, integrity and replay protection." Perhaps that should be repeated earlier in the doc. Editorial: it's not clear to me why this is being defined only for DHCPv6. A sentence explaining that would be helpful. -- Sam