From weiler+secdir@watson.org Wed Jul 1 22:13:06 2009 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 478D53A6C20; Wed, 1 Jul 2009 22:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 X-MYZpmir8Cu; Wed, 1 Jul 2009 22:13:05 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 5758C3A6AF3; Wed, 1 Jul 2009 22:13:05 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n625DNWd018974; Thu, 2 Jul 2009 01:13:23 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n625DNIf018970; Thu, 2 Jul 2009 01:13:23 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 2 Jul 2009 01:13:23 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org, iesg@ietf.org, ospf-chairs@tools.ietf.org, draft-ietf-ospf-dynamic-hostname@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.0.1 (fledge.watson.org [127.0.0.1]); Thu, 02 Jul 2009 06:13:24 +0100 (BST) Subject: [secdir] secdir review of draft-ietf-ospf-dynamic-hostname 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: Thu, 02 Jul 2009 05:13: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. The dynamic hostname TLV is an optional in-band mechanism to provide human-friendly symbolic names that map to router IDs. The security considerations section 1) encourages the use of OSPF authentication and 2) calls out the grand fun possible if a misconfigured or compromised router sends bad mappings. While that's probably less fun than could be had from just sending bad routing data, it adds an extra level of complexity to the debugging when these new symbolic names, as shown in config and debugging tools, don't match the expected router IDs. But I'm not sure anything more really needs to be said here. Resource exhaustion, as raised by Robert Sparks, looks to be a possibility, but I could go either way on whether it's worth adding words about it specifically -- do we need to call out the potential for resource exhaustion for every field in every protocol? I'd let the doc go as-is. -- Sam From secdir-bounces@mit.edu Thu Jul 2 13:04:19 2009 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 0173028C23E for ; Thu, 2 Jul 2009 13:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.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 MlYkG98NeQjk for ; Thu, 2 Jul 2009 13:04:18 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 0895E28C22E for ; Thu, 2 Jul 2009 13:04:17 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n62K4e2b022551 for ; Thu, 2 Jul 2009 16:04:40 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n62K4dKa022548 for ; Thu, 2 Jul 2009 16:04:39 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n62K4Wmc012424 for ; Thu, 2 Jul 2009 16:04:32 -0400 (EDT) Received: from fw5540.nrl.navy.mil (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 6703B22B70DA for ; Thu, 2 Jul 2009 16:04:31 -0400 (EDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by mit.edu with ESMTP id 5Jqu7Ss8NEg5hDY3 for ; Thu, 02 Jul 2009 16:04:31 -0400 (EDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.6/8.13.6) with ESMTP id n62K4M1T019489; Thu, 2 Jul 2009 16:04:22 -0400 (EDT) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.6/8.13.6) with SMTP id n62K4KSl025186; Thu, 2 Jul 2009 16:04:20 -0400 (EDT) Received: from gilgamesh.fw5540.net ([10.0.3.67]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009070216042014928 ; Thu, 02 Jul 2009 16:04:20 -0400 Message-Id: From: Catherine Meadows To: iesg@ietf.org, secdir@mit.edu, jf.mule@cablelabs.com, jason_livingood@cable.comcast.com, d.malas@cablelabs.com Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 16:04:15 -0400 X-Mailer: Apple Mail (2.935.3) X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: multipart/mixed; boundary="===============1645621705==" Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Subject: [secdir] Secdir Review of draft-ietf-speermint-requirements 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, 02 Jul 2009 20:04:19 -0000 --===============1645621705== Content-Type: multipart/alternative; boundary=Apple-Mail-16--177600070 --Apple-Mail-16--177600070 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document concerns the requirements for peering at the session layer using the SIP protocol in order to exchange multimedia traffic. The security requirements are presented in the Security Considerations section. It addresses three parts : acquisition of session establishment data, SIP signaling exchanges, end End-to-end media security. For session establishment data acquisition, the document says that both authentication and confidentiality MUST be supported. For SIP signaling exchanges, the authors note that this is beyond the scope of the document, but gives some recommendations without normative requirements. For media exchange the requirements are that the session peering protocols MUST NOT interfere with any security mechanisms of the media exchange protocols. I found the security considerations section well-thought out and well- motivated, The authors were careful to give reasons for all their assertions, and their discussion of security mechanisms for SIP signaling exchanges is also welcome in that it provides context, even though it is strictly outside the scope of the document. I do not see any problems here. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail-16--177600070 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.


This document concerns = the requirements for peering at the session layer using the SIP = protocol
in order to exchange multimedia traffic.   The = security requirements are presented
in the Security = Considerations section.  It addresses three parts : acquisition of = session establishment
data, SIP signaling exchanges, end = End-to-end media security.  For session establishment data = acquisition,
the document says that both authentication and = confidentiality MUST be supported.  For SIP signaling = exchanges,
the authors note that this is beyond the scope of = the document, but gives some recommendations without = normative 
requirements.  For media exchange the = requirements are that the session peering protocols MUST NOT interfere = with
any security mechanisms of the media exchange = protocols.

I found the security considerations = section well-thought out and well-motivated,  The authors were = careful to give reasons
for all their assertions, and their = discussion of security mechanisms for SIP signaling exchanges is also = welcome in that it provides
context, even though it is = strictly outside the scope of the document.  I do not see any = problems here.


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

= --Apple-Mail-16--177600070-- --===============1645621705== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir --===============1645621705==-- From catherine.meadows@nrl.navy.mil Thu Jul 2 13:54:40 2009 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 B7E5B3A68DA; Thu, 2 Jul 2009 13:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-1.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 w6TlWJscM6So; Thu, 2 Jul 2009 13:54:39 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id A87353A6850; Thu, 2 Jul 2009 13:54:39 -0700 (PDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.6/8.13.6) with ESMTP id n62Kt15j025180; Thu, 2 Jul 2009 16:55:01 -0400 (EDT) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.6/8.13.6) with SMTP id n62Kscex027229; Thu, 2 Jul 2009 16:54:42 -0400 (EDT) Received: from gilgamesh.fw5540.net ([10.0.3.67]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009070216543814980 ; Thu, 02 Jul 2009 16:54:38 -0400 Message-Id: <79F2D899-118B-4FBD-BA29-9B65FFD6F6B7@nrl.navy.mil> From: Catherine Meadows To: iesg@ietf.org, secdir@ietf.org, luby@qualcomm.com, watson@qualcomm.com, vicisano@qualcomm.com, Brian Adamson , lorenzo@vicisano.net Content-Type: multipart/alternative; boundary=Apple-Mail-17--174581501 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 16:54:34 -0400 X-Mailer: Apple Mail (2.935.3) Subject: [secdir] Secdir review of draft-ietf-rmt-bb-lct-revised-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: Thu, 02 Jul 2009 20:54:40 -0000 --Apple-Mail-17--174581501 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This paper concerns the Layered Coding Transport building block. LCT provides support for massively scalable protocols using the IP multicast network service. LCT supports sessions consisting or multiple channels, all with the same sender, but many different receivers. This makes it compatible with many massively scalable congestion control protocols that use this structure. When we are dealing with massively scalable congestion control protocols, the question of denial of service naturally comes to mind. Thus the security considerations section rightly mainly concerns itself with that. However, it left me with several questions. 1. The introduction says that "Protocol Instantiations that use the LCT building block MUST address the security requirements described in the following sections." But there are no MUSTs or MUST NOTs in the following sections. Indeed,sections 8.1 and 8.2 don't contain any recommendations at all; they simply identify vulnerabilities (which could, however, be addressed by authentication). I would suggest either toning down the introduction ("MUST address the potential vulnerabilities" instead of "MUST address the requirements") or beef up the specific sections. 2. The sections themselves have a kind of piecemeal feel about them, addressing specific potential attacks, but without giving a feeling that everything that is covered. It might be a better idea to describe what services security mechanisms could provide (e.g. authentication, confidentiality) describe the various each service offered by LCT and its vulnerabilities, and then what security services would address. I suspect, given the vulnerabilities that the authors have already described, it would mostly boil down to identifying which LCT data should or must be authenticated. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail-17--174581501 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.

This paper concerns the Layered = Coding Transport building block.  LCT provides
support = for massively scalable protocols using the IP multicast network = service.
LCT supports sessions = consisting or multiple channels, all with th= e same sender, but
many different recei= vers.  This makes it compatible with ma= ny massively scalable congestion
control pro= tocols that use this structure.

When we are dealing with massively scalab= le congestion control protocols, the question
of denial of service naturally comes = to mind.  Thus the security considerations&n= bsp;section
rightly mainly concerns itself w= ith that.  However, it left me with&nbs= p;several questions.

1.  The = introduction says that "Protocol Instantiations t= hat use the LCT building block MUST
address the security requirements described in&= nbsp;the following sections."   But there&nb= sp;are no MUSTs
or MUST NOTs in th= e following sections.  Indeed,sections 8.1 a= nd 8.2 don't contain any recommendations
at all; they simply identify vulnerabilities&nb= sp;(which could, however, be addressed by au= thentication).  I would
suggest either toning down the = introduction ("MUST address the potential vulnerabilities" instead of = "MUST address
the requirements") or beef up the specific = sections.

2.  The sections themselves have = a kind of piecemeal feel about them, addressing specific potential = attacks, but
without giving a feeling that everything that is = covered.  It might be a better idea to describe what services = security mechanisms
could provide (e.g. authentication, = confidentiality) describe the various each service offered by LCT and = its vulnerabilities,
and then what security services would = address.  I suspect, given the vulnerabilities that the authors = have already described, it
would mostly boil down to = identifying which LCT data should or must be = authenticated.


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

= --Apple-Mail-17--174581501-- From cpignata@cisco.com Thu Jul 2 19:26:12 2009 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 7000F3A67EA for ; Thu, 2 Jul 2009 19:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 ybyBBLTe7rZz for ; Thu, 2 Jul 2009 19:26:11 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BDF2D3A697F for ; Thu, 2 Jul 2009 19:26:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,338,1243814400"; d="scan'208";a="49303315" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 03 Jul 2009 02:26:27 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n632QR1g008168; Thu, 2 Jul 2009 22:26:27 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n632QR2M017730; Fri, 3 Jul 2009 02:26:27 GMT Received: from xmb-rtp-204.amer.cisco.com ([64.102.31.25]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 22:26:27 -0400 Received: from 171.70.151.174 ([171.70.151.174]) by xmb-rtp-204.amer.cisco.com ([64.102.31.25]) with Microsoft Exchange Server HTTP-DAV ; Fri, 3 Jul 2009 02:26:26 +0000 Message-ID: From: "Carlos Pignataro (cpignata)" To: Thread-Topic: secdir review of draft-ietf-ospf-dynamic-hostname Thread-Index: Acn7hao0DQ4p4FGIRHCNsN/I9Vv43w== In-Reply-To: Content-Type: text/plain; format=flowed; delsp=yes; charset="us-ascii" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (iPhone Mail 7A341) Date: Thu, 2 Jul 2009 22:26:17 -0400 References: X-OriginalArrivalTime: 03 Jul 2009 02:26:27.0006 (UTC) FILETIME=[AAB635E0:01C9FB85] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1508; t=1246587987; x=1247451987; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=cpignata@cisco.com; z=From:=20=22Carlos=20Pignataro=20(cpignata)=22=20 |Subject:=20Re=3A=20secdir=20review=20of=20draft-ietf-ospf- dynamic-hostname |Sender:=20 |To:=20; bh=VJKyA+ZqGLIjjzFL+3xRvZZtWP4tovXN+wBaJyP3+OY=; b=miPFGKNawFzWj9j2CM0lKwm5GiNDUCMgq8Rh6mRtccjvKzBAtH225JXid5 PA3ubY99ZB0sXdf2dXkwyucrjG31ZKBuY/YATYD3tQBGwdKEDuRp7Po6Gu5b BSMQ+c59IW; Authentication-Results: rtp-dkim-2; header.From=cpignata@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: ospf-chairs@tools.ietf.org, draft-ietf-ospf-dynamic-hostname@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-ospf-dynamic-hostname 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, 03 Jul 2009 02:26:12 -0000 Many Thanks for your review, Sam. -- Thumb typed by Carlos Pignataro. On Jul 2, 2009, at 1:14 AM, "Samuel Weiler" wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should > treat these comments just like any other last call comments. > > > The dynamic hostname TLV is an optional in-band mechanism to provide > human-friendly symbolic names that map to router IDs. > > The security considerations section 1) encourages the use of OSPF > authentication and 2) calls out the grand fun possible if a > misconfigured or compromised router sends bad mappings. While > that's probably less fun than could be had from just sending bad > routing data, it adds an extra level of complexity to the debugging > when these new symbolic names, as shown in config and debugging > tools, don't match the expected router IDs. But I'm not sure > anything more really needs to be said here. > > Resource exhaustion, as raised by Robert Sparks, looks to be a > possibility, but I could go either way on whether it's worth adding > words about it specifically -- do we need to call out the potential > for resource exhaustion for every field in every protocol? > > I'd let the doc go as-is. > > -- Sam > From weiler+secdir@watson.org Fri Jul 3 17:30:56 2009 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 436C63A6935 for ; Fri, 3 Jul 2009 17:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzP2ZOE1UzsW for ; Fri, 3 Jul 2009 17:30:55 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 5487A3A687B for ; Fri, 3 Jul 2009 17:30:55 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n640F3GP074483 for ; Fri, 3 Jul 2009 20:15:03 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n640F3le074479 for ; Fri, 3 Jul 2009 20:15:03 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 3 Jul 2009 20:15:03 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Sat, 04 Jul 2009 01:15:03 +0100 (BST) Subject: [secdir] Assignments for July 10th 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, 04 Jul 2009 00:30:56 -0000 If you've been keeping your secdir reviews on your own todo list, this would be a good time to check the list below to make sure a review is still wanted for the doc: at least ten docs were removed from the assignment backlog because they were on yesterday's telechat but no review was ever received. We only have three new assignments this week (to Chris Newman, Vidya Narayanan, and Magnus Nystrom); Hilarie Orman is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-07-16 (all of these were first assiged previously) Scott Kelly T draft-ietf-softwire-lb-03 Julien Laganier T draft-hollenbeck-rfc4934bis-01 Catherine Meadows T draft-hollenbeck-rfc4930bis-02 Chris Newman T draft-ietf-sip-connect-reuse-13 Nico Williams T draft-ietf-pcn-marking-behaviour-04 Glen Zorn T draft-solinas-suiteb-cert-profile-04 Last calls and special requests: Dave Cridland draft-ietf-behave-nat-behavior-discovery-06 Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 Shawn Emery draft-ietf-ipfix-export-per-sctp-stream-02 Tobias Gondrom draft-ietf-nea-pa-tnc-04 Phillip Hallam-Baker draft-ietf-nea-pb-tnc-04 Steve Hanna draft-peterson-rai-rfc3427bis-01 Steve Hanna draft-ietf-netconf-partial-lock-09 Love Hornquist-Astrand draft-ietf-ipfix-mib-06 Love Hornquist-Astrand draft-ietf-opsawg-smi-datatypes-in-xsd-05 Charlie Kaufman draft-ietf-ipsecme-ikev2-redirect-11 Stephen Kent draft-ietf-l3vpn-as4octet-ext-community-03 Julien Laganier draft-ietf-sip-certs-07 Julien Laganier draft-ietf-l3vpn-v6-ext-communities-02 Barry Leiba draft-ietf-simple-interdomain-scaling-analysis-06 Catherine Meadows draft-ietf-speechsc-mrcpv2-19 Sandy Murphy draft-ietf-speermint-voip-consolidated-usecases-13 Vidya Narayanan draft-ietf-sip-saml-06 Vidya Narayanan draft-ietf-enum-3761bis-04 Vidya Narayanan draft-ietf-opsawg-syslog-snmp-03 Chris Newman draft-ietf-mpls-tp-requirements-09 Magnus Nystrom draft-ietf-opsawg-syslog-msg-mib-04 Eric Rescorla draft-ietf-enum-iax-05 Joe Salowey draft-ietf-geopriv-lis-discovery-11 Hannes Tschofenig draft-ietf-pce-monitoring-05 Sam Weiler draft-chown-v6ops-rogue-ra-03 Nico Williams draft-ietf-v6ops-ra-guard-03 Larry Zhu draft-thaler-v6ops-teredo-extensions-03 Larry Zhu draft-ietf-ecrit-location-hiding-req-01 From Shawn.Emery@Sun.COM Fri Jul 3 23:44:13 2009 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 8F0143A6962; Fri, 3 Jul 2009 23:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.946 X-Spam-Level: X-Spam-Status: No, score=-5.946 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 qWa4zcGUgeB6; Fri, 3 Jul 2009 23:44:12 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 5EC0F3A6823; Fri, 3 Jul 2009 23:44:10 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n646Tws9015663; Sat, 4 Jul 2009 06:29:58 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KM800600V0E3R00@mail-amer.sun.com>; Sat, 04 Jul 2009 00:29:58 -0600 (MDT) Received: from [10.0.0.5] ([unknown] [67.190.47.79]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KM800746VDY3Z00@mail-amer.sun.com>; Sat, 04 Jul 2009 00:29:58 -0600 (MDT) Date: Sat, 04 Jul 2009 00:29:41 -0600 From: Shawn M Emery Sender: Shawn.Emery@Sun.COM To: secdir@ietf.org Message-id: <4A4EF6D5.3050505@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090505) Cc: draft-ietf-ipfix-export-per-sctp-stream@tools.ietf.org, iesg@ietf.org, ipfix-chairs@tools.ietf.org Subject: [secdir] Review of draft-ietf-ipfix-export-per-sctp-stream-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: Sat, 04 Jul 2009 06:44:13 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes a protocol for exporting definitions and associated data over one Stream Control Transmission Protocol (SCTP) stream, as opposed to spreading across multiple streams in support of IP Flow Information eXport (IPFIX). The advantages being; determination of the rate of loss, reduction in data loss, reduce resource requirements by receiver, etc. This draft defers security considerations to RFC 5101, which does a good job in defining the various scenarios and respective solutions. I didn't find any new security concerns that this draft introduces. General comments(s): Thanks for including an example section. Editorial comment(s): Please expand abbreviations, such as PR, SCTP, and IPFIX at the beginning of the document. s/ RFC5101 /[RFC5101]/ s/RFC 2119 [RFC2119]/[RFC2119]/ s/RFC 3917 [RFC3917]/[RFC3917]/ s/descried/described/ Shawn. -- From secdir-bounces@mit.edu Sat Jul 4 09:12:31 2009 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 E74B73A694D for ; Sat, 4 Jul 2009 09:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, 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 uiusUITLabb5 for ; Sat, 4 Jul 2009 09:12:30 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id D7DFE3A69B7 for ; Sat, 4 Jul 2009 09:12:29 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n64GCqnA002256 for ; Sat, 4 Jul 2009 12:12:52 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n64GCpD4002250 for ; Sat, 4 Jul 2009 12:12:51 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n64GChZL025270 for ; Sat, 4 Jul 2009 12:12:44 -0400 (EDT) Received: from doar.tau.ac.il (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 80A7D216A5D5 for ; Sat, 4 Jul 2009 12:12:43 -0400 (EDT) Received: from doar.tau.ac.il (gate.tau.ac.il [132.66.16.26]) by mit.edu with ESMTP id jc7ULCJrOf0QXKqj for ; Sat, 04 Jul 2009 12:12:43 -0400 (EDT) Received-SPF: pass (mit.edu: domain of canetti@post.tau.ac.il designates 132.66.16.26 as permitted sender) receiver=mit.edu; client_ip=132.66.16.26; envelope-from=canetti@post.tau.ac.il; Received: from [192.168.205.191] (unknown [208.59.93.230]) by doar.tau.ac.il (Postfix) with ESMTP id 3097EBEF8; Sat, 4 Jul 2009 19:12:41 +0300 (IDT) Message-ID: <4A4F7F73.2010204@post.tau.ac.il> Date: Sat, 04 Jul 2009 12:12:35 -0400 From: Ran Canetti User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: ancp@ietf.org, secdir@mit.edu, hassnaa.moustafa@orange-ftgroup.com, Ran Canetti X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Subject: [secdir] SECDIR review of hassnaa.moustafa@orange-ftgroup.com X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 16:12: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 describes potential threats and attacks, and consequently security requirements for the Access Note Control Protocol. (This protocol allows configuring the components of DSL connections to the Internet.) My main comment is that most (if not all) of the attacks seem to be generic man-in-the-middle and DOS attacks. Also the short list of security requirements that are derived from these attacks (section 8) seem pretty generic authentication and secrecy requirements for Internet connections. It would be nice to differentiate and highlight the security threats and concerns that are special to the ANCS setting. In particular, what are the trust relationships between the different protocol principals/entities? Are they all run by the same administrative domain? Also, are all links equally untrusted, or are there links that are less trusted than others? Also, are all attacks equally devestating? Which are more costly/important to prevent? Best, Ran _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From catherine.meadows@nrl.navy.mil Mon Jul 6 08:53:57 2009 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 7BC0328C37C; Mon, 6 Jul 2009 08:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 3j3ofFvDd9Xn; Mon, 6 Jul 2009 08:53:56 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id 7616C28C275; Mon, 6 Jul 2009 08:53:56 -0700 (PDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.6/8.13.6) with ESMTP id n66FrM7e018762; Mon, 6 Jul 2009 11:53:22 -0400 (EDT) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.6/8.13.6) with SMTP id n66FrLaj013161; Mon, 6 Jul 2009 11:53:21 -0400 (EDT) Received: from gilgamesh.fw5540.net ([10.0.3.67]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009070611532016993 ; Mon, 06 Jul 2009 11:53:20 -0400 Message-Id: <897517DC-2F59-440A-BD63-BD71E1AF4421@nrl.navy.mil> From: Catherine Meadows To: secdir@ietf.org, iesg@ietf.org, "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=Apple-Mail-11-152943827 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 6 Jul 2009 11:53:19 -0400 X-Mailer: Apple Mail (2.935.3) Subject: [secdir] review of draft-hollenbeck-rfc4933bis-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: Mon, 06 Jul 2009 15:53:57 -0000 --Apple-Mail-11-152943827 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Quote from last review: "The draft updates RFC 4933, the EPP Contacts Mapping spec. The updates listed are relatively minor - updates to references and a few minor updates to text." Version 1 has reviewed recently (June 10, by Sandy Murphy) and the author already made the changes that were agreed upon in following discussion. Everything mostly looks OK to me, but there is one issue that never got completely resolved as far as I can tell from what I saw online. This is the question of channel binding issues as described RFC 4953. I'm having trouble accessing that document right now, but apparently the issue is that low-level authentication mechanisms will not provide any distinction between channels at a higher level. This can make it possible for someone with access to the authentication mechanisms to spoof different channels. In particular, if the EPP authorization information is protected with lower-level authentication mechanisms this could be the case. Unless there is good reason to believe that this sort of attack is impossible (in which case it would be a good idea to say why) it might be good that >> Both client and server MUST ensure that authorization >> information is stored and exchanged with high-grade encryption >> mechanisms to provide privacy services. be changed to Both client and server MUST ensure that authorization information is stored and exchanged with high-grade encryption mechanisms to provide privacy and authentication services at the appropriate level of granularity. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail-11-152943827 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.

Quote from last = review:

"The draft updates RFC 4933, the EPP = Contacts Mapping spec.  
The updates listed are relatively minor = - updates to 
references and a few minor updates to = text."

Version 1 has = reviewed recently (June 10, by Sandy Murphy)=  and the author already
made the c= hanges that were agreed upon in following&nb= sp;discussion.

Everything mostly looks&= nbsp;OK to me, but there is one issue&n= bsp;that never got completely resolved
as&nb= sp;far as I can tell from what I s= aw online.  This is the question of&nbs= p;channel binding issues as described
RFC = 4953.  I'm having trouble accessing that document right now, but = apparently the issue is that
low-level authentication = mechanisms will not provide any distinction between channels at a higher = level.
This can make it possible for someone with access to = the authentication mechanisms to spoof different channels.
In = particular, if the EPP authorization information is protected with = lower-level authentication mechanisms this could
be the case. =  Unless there is good reason to believe that this sort of attack is = impossible (in which case it would
be a good idea to say why) = it might be = good 
that 

Both client and server MUST = ensure that authorization
   information is stored and exchanged with = high-grade encryption
   mechanisms to provide privacy = services.

be changed = to

Both client and server MUST ensure that = authorization
   information is stored and exchanged = with high-grade encryption
   mechanisms to provide = privacy and authentication services at the appropriate = level
of = granularity.


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

= --Apple-Mail-11-152943827-- From paul.hoffman@vpnc.org Mon Jul 6 17:02:20 2009 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 634703A6DAA for ; Mon, 6 Jul 2009 17:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.235, 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 fesGKC8GzTOb for ; Mon, 6 Jul 2009 17:02:19 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5918F3A6806 for ; Mon, 6 Jul 2009 17:02:13 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6702YjD095992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 6 Jul 2009 17:02:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 6 Jul 2009 17:02:32 -0700 To: secdir@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [secdir] Fwd: I-D ACTION:draft-ko-mif-security-considerations-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, 07 Jul 2009 00:02:20 -0000 >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : MIF Security Analysis > > Author(s) : N. Ko, C. Williams, J. Qin > Filename : draft-ko-mif-security-considerations-00.txt > Pages : 6 > Date : 2009-7-6 > >MIF is working to describe the issues of attaching to multiple > networks on hosts and document existing practice. The group is also > expected to analyze the impacts and effectiveness of these existing > mechanisms. A MIF node will have various security considerations > that must be reviewed. This document provides security analysis for > MIF. MIF security requirements are also presented. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ko-mif-security-considerations-00.txt > This seems like pretty important work. I am not a routing person at all, but if someone here who cares about routing and/or multihoming wants to follow this from the early days, I bet we'll have fewer big issues at the end and the world will be much better off. --Paul Hoffman, Director --VPN Consortium From Sven.Ooghe@alcatel-lucent.be Tue Jul 7 07:26:04 2009 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 8F2AD3A6E60; Tue, 7 Jul 2009 07:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 FKlVgYyt6sxB; Tue, 7 Jul 2009 07:26:02 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id E649C3A6935; Tue, 7 Jul 2009 07:26:01 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n67EPPEn022250; Tue, 7 Jul 2009 16:25:57 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 16:25:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jul 2009 16:25:47 +0200 Message-ID: <7168964CAC5C144685272595141B6DBA028CEFA3@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <039b01c9f8c3$a108a7e0$e319f7a0$@coopercain.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-ancp-framework-10 Thread-Index: Acn4w5iFLrA4q3muRTSpPrluE93lVAGSxbrg References: <039b01c9f8c3$a108a7e0$e319f7a0$@coopercain.com> From: "OOGHE Sven" To: "pat cain" , , X-OriginalArrivalTime: 07 Jul 2009 14:25:48.0686 (UTC) FILETIME=[D2BAEAE0:01C9FF0E] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 X-Mailman-Approved-At: Tue, 07 Jul 2009 08:19:59 -0700 Cc: iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-ancp-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: Tue, 07 Jul 2009 14:26:05 -0000 Pat Thanks for reviewing. I have changed the first sentence in the security considerations section according to your proposed wording. Regards Sven -----Original Message----- From: pat cain [mailto:pcain2@mail2.coopercain.com]=20 Sent: maandag 29 juni 2009 16:12 To: secdir@ietf.org; draft-ietf-ancp-framework@tools.ietf.org Cc: iesg@ietf.org Subject: secdir review of draft-ietf-ancp-framework-10 Hi, I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document defines a framework for an Access Node Control Mechanism between a Network Access Server and a DSLAM. It is informational. I have a mostly small comment on this document: The security considerations section points to "draft-ietf-ancp-security-threats that lists the security-related security threats". I read that document, too. It has more than threats in it; there a whole section on security requirements.=20 I would add a small phrase to the security considerations of the framework to=20 make sure the reader is aware that there are more requirements than just what=20 is in the framework document. Maybe just add a few words to the first sentence of the security considerations section in the framework: "I develops a threat model [ and identifies requirements] for ANCP security...." Otherwise it looked okay to me.=20 Pat Cain From shollenbeck@verisign.com Tue Jul 7 13:46:09 2009 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 D75CB3A6967; Tue, 7 Jul 2009 13:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBDEhT3TBq73; Tue, 7 Jul 2009 13:46:08 -0700 (PDT) Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by core3.amsl.com (Postfix) with ESMTP id 7CE553A688C; Tue, 7 Jul 2009 13:46:08 -0700 (PDT) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id n67Jek5h003019; Tue, 7 Jul 2009 15:41:26 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 15:52:05 -0400 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_01C9FF3C.66B71721" Date: Tue, 7 Jul 2009 15:52:03 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0702B8DA2E@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <897517DC-2F59-440A-BD63-BD71E1AF4421@nrl.navy.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of draft-hollenbeck-rfc4933bis-02 Thread-Index: Acn+UgpuDYWKSgOJQuyUxQ2fFNSRxwA6Q7vg References: <897517DC-2F59-440A-BD63-BD71E1AF4421@nrl.navy.mil> From: "Hollenbeck, Scott" To: "Catherine Meadows" , , X-OriginalArrivalTime: 07 Jul 2009 19:52:05.0490 (UTC) FILETIME=[676A2520:01C9FF3C] Subject: Re: [secdir] review of draft-hollenbeck-rfc4933bis-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, 07 Jul 2009 20:46:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FF3C.66B71721 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I made this statement in my response to Sandy: =20 "I would need more specific information to know if there's something to be done with this comment. Reliance on security mechanisms provided at the transport layer has been part of this specification since day one. I am not aware of any implementation issues." =20 There was no follow-up, so I remain a little unsure of how to address the comment. Similarly, I need a clarification to know if the text change suggested below is best made in 4933bis. =20 There's a separate document that addresses EPP transport over TCP. If the channel binding issue is primarily an issue with TCP (is it?), I'd prefer to address it in the TCP mapping document (4934bis). If it's more focused on the application-layer exchange of authorization information I'm OK with making the text change suggested below in 4933bis. I should note that the same text exists in 4931bis so I'd need to change it there as well. =20 So - where is the most appropriate place to add text? =20 -Scott- ________________________________ From: Catherine Meadows [mailto:catherine.meadows@nrl.navy.mil]=20 Sent: Monday, July 06, 2009 11:53 AM To: secdir@ietf.org; iesg@ietf.org; Hollenbeck, Scott Cc: Catherine Meadows Subject: review of draft-hollenbeck-rfc4933bis-02 =09 =09 I have reviewed this document as part of the security=20 directorate's ongoing effort to review all IETF documents=20 being processed by the IESG.=20 These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs=20 should treat these comments just like any other last call comments.=20 Quote from last review: =09 "The draft updates RFC 4933, the EPP Contacts Mapping spec. =20 The updates listed are relatively minor - updates to=20 references and a few minor updates to text." Version 1 has reviewed recently (June 10, by Sandy Murphy) and the author already made the changes that were agreed upon in following discussion. Everything mostly looks OK to me, but there is one issue that never got completely resolved as far as I can tell from what I saw online. This is the question of channel binding issues as described RFC 4953. I'm having trouble accessing that document right now, but apparently the issue is that low-level authentication mechanisms will not provide any distinction between channels at a higher level. This can make it possible for someone with access to the authentication mechanisms to spoof different channels. In particular, if the EPP authorization information is protected with lower-level authentication mechanisms this could be the case. Unless there is good reason to believe that this sort of attack is impossible (in which case it would be a good idea to say why) it might be good=20 that=20 Both client and server MUST ensure that authorization =09 information is stored and exchanged with high-grade encryption =09 mechanisms to provide privacy services. be changed to Both client and server MUST ensure that authorization information is stored and exchanged with high-grade encryption mechanisms to provide privacy and authentication services at the appropriate level of granularity. =09 Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil ------_=_NextPart_001_01C9FF3C.66B71721 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I made this statement in my response to = Sandy:
 
"I would need more specific information = to know if=20 there's something to be done with this comment. Reliance on security = mechanisms=20 provided at the transport layer has been part of this specification = since day=20 one. I am not aware of any implementation = issues."
 
There was no follow-up, so I remain a little unsure of = how=20 to address the comment.  Similarly, I need a clarification to = know if=20 the text change suggested below is best made in = 4933bis.
 
There's a separate document that addresses EPP transport = over=20 TCP.  If the channel binding issue is primarily an issue with TCP = (is it?),=20 I'd prefer to address it in the TCP mapping document (4934bis).  If = it's=20 more focused on the application-layer exchange of authorization = information I'm=20 OK with making the text change suggested below in 4933bis.  I = should note=20 that the same text exists in 4931bis so I'd need to change it there as=20 well.
 
So - where is the most appropriate place to add=20 text?
 
-Scott-

From: Catherine Meadows=20 [mailto:catherine.meadows@nrl.navy.mil]
Sent: Monday, July = 06, 2009=20 11:53 AM
To: secdir@ietf.org; iesg@ietf.org; Hollenbeck,=20 Scott
Cc: Catherine Meadows
Subject: review of=20 draft-hollenbeck-rfc4933bis-02

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

Quote from last review:

"The draft updates RFC 4933, the EPP Contacts Mapping spec. =  
The=20 updates listed are relatively minor - updates to 
references = and a few=20 minor updates to text."

Version 1 has=20 = reviewed recently (June 10, by Sandy Murphy= ) and the author already
=
made the changes that were agreed upon=  in following discussion.

=
Everything mostly looks OK to me, but&= nbsp;there is one issue that never got = ;completely resolved
=
as far as I can tell from what&nb= sp;I saw online.  This is the question=  of channel binding issues as described
RFC 4953.  I'm having trouble accessing that document right = now, but=20 apparently the issue is that
low-level authentication mechanisms will not provide any = distinction=20 between channels at a higher level.
This can make it possible for someone with access to the = authentication=20 mechanisms to spoof different channels.
In particular, if the EPP authorization information is protected = with=20 lower-level authentication mechanisms this could
be the case.  Unless there is good reason to believe that = this sort=20 of attack is impossible (in which case it would
be a good idea to say why) it might be good 
that 

Both client and server MUST ensure that=20 authorization
   information is stored = and=20 exchanged with high-grade encryption
   mechanisms to provide = privacy=20 services.

be changed to

Both client and server MUST ensure that=20 authorization
   information is stored and exchanged = with=20 high-grade encryption
   mechanisms to provide = privacy and=20 authentication services at the appropriate level
of granularity.


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

------_=_NextPart_001_01C9FF3C.66B71721-- From secdir-bounces@mit.edu Tue Jul 7 14:16:21 2009 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 16D1F3A68A1 for ; Tue, 7 Jul 2009 14:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.024 X-Spam-Level: X-Spam-Status: No, score=-105.024 tagged_above=-999 required=5 tests=[AWL=1.575, 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 M6zfYUsYvKk1 for ; Tue, 7 Jul 2009 14:16:20 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 05CBD3A687D for ; Tue, 7 Jul 2009 14:16:19 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n67LFn5j004389 for ; Tue, 7 Jul 2009 17:15:49 -0400 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n67LFmOp004386 for ; Tue, 7 Jul 2009 17:15:48 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n67LFbiR016201 for ; Tue, 7 Jul 2009 17:15:37 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id C834F13469C0 for ; Tue, 7 Jul 2009 17:15:36 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id CMDQ6XbuDHQIgo8M for ; Tue, 07 Jul 2009 17:15:36 -0400 (EDT) X-Barracuda-Envelope-From: new-work-bounces@ietf.org Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org; Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E8ED28C55A; Tue, 7 Jul 2009 14:15:05 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3437E28C525; Tue, 7 Jul 2009 14:15:02 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090707211502.3437E28C525@core3.amsl.com> Date: Tue, 7 Jul 2009 14:15:02 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Wed, 08 Jul 2009 08:39:51 -0700 Subject: [secdir] [New-work] WG Review: Recharter of DNS Extensions (dnsext) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 21:16:21 -0000 A modified charter has been submitted for the DNS Extensions (dnsext) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, July 14, 2009. DNS Extensions Working group (dnsext) ---------------------------------------- Last Modified: 2009-06-24 Current Status: Active Working Group Chair(s): Olafur Gudmundsson Andrew Sullivan Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: namedroppers@ops.ietf.org To Subscribe: namedroppers-request@ops.ietf.org Archive: http://ops.ietf.org/lists/namedroppers/ Description of Working Group: The DNS has a large installed base and repertoire of protocol specifications. The DNSEXT WG group will actively advance DNS protocol-related RFCs on the standards track while thoroughly reviewing further proposed extensions. The scope of the DNSEXT WG is confined to the DNS protocol, particularly changes that affect DNS protocols "on the wire" or the internal processing of DNS data. DNS operations are out of scope for the WG. The WG will limit itself to review of proposals for new extensions and clarification to the DNS protocol, including DNSSEC. Adoption of new work targeted for standards track will require changes to this charter. The working group can nevertheless undertake work in following subjects without a charter change: DNSSEC and TSIG/TKEY algorithm maintenance Hardening DNS protocol and providing guidance to implementors Examining transport protocols possibly adding new ones. Advancing existing Proposed Standard RFCs to Draft/Full Standard Obsoleting RFCs. Before formal adoption of any such items at least 5 working group participants must publicly state that the item is within charter and is worthwhile item for further study. The DNSEXT WG will conduct the specified RFC5395 review of RR templates as they are posted, and EDNS0 Option templates if EDNS0-bis updates registration requirements. The WG will review DNS protocol related work which may originate elsewhere in the IETF, including AD-sponsored submissions or drafts in other working group. The WG does not intend to hold face to face meetings, though may do so if deemed necessary for resolution of a specific issue at hand. Milestones: Jul 2009 TSIG/MD5 Obsoleting to IESG. Jul 2009 RSA/SHA256 to IESG. Aug 2009 AXFR Clarify to IESG. Sep 2009 EDNS0 Ping Option advanced to IESG Oct 2009 Resolver side Forgery Resilience advanced to IESG Oct 2009 DNSSEC Errata document to IESG Nov 2009 GOST DNSKEY and DS support advanced to IESG Dec 2009 EDNS0-bis update advanced to IESG Feb 2010 DNS existing transport protocol recommendations/clarifications to IESG Jun 2010 DNS transport protocol specification _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From catherine.meadows@nrl.navy.mil Wed Jul 8 09:01:54 2009 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 65DC228C0EA; Wed, 8 Jul 2009 09:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 Ow-pd9zfAsIO; Wed, 8 Jul 2009 09:01:50 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id BFB683A69B8; Wed, 8 Jul 2009 09:01:49 -0700 (PDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.6/8.13.6) with ESMTP id n68G2EGk009108; Wed, 8 Jul 2009 12:02:14 -0400 (EDT) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.6/8.13.6) with SMTP id n68G2CcI028540; Wed, 8 Jul 2009 12:02:12 -0400 (EDT) Received: (from [IPv6:::1] [10.0.0.13]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009070812021020198 ; Wed, 08 Jul 2009 12:02:10 -0400 Message-Id: <6F8E48C3-9E52-4912-B748-3C9A43519EA7@nrl.navy.mil> From: Catherine Meadows To: "Hollenbeck, Scott" In-Reply-To: <046F43A8D79C794FA4733814869CDF0702B8DA2E@dul1wnexmb01.vcorp.ad.vrsn.com> Content-Type: multipart/alternative; boundary=Apple-Mail-3-326275132 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 8 Jul 2009 12:02:10 -0400 References: <897517DC-2F59-440A-BD63-BD71E1AF4421@nrl.navy.mil> <046F43A8D79C794FA4733814869CDF0702B8DA2E@dul1wnexmb01.vcorp.ad.vrsn.com> X-Mailer: Apple Mail (2.935.3) Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] review of draft-hollenbeck-rfc4933bis-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, 08 Jul 2009 16:01:54 -0000 --Apple-Mail-3-326275132 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit My apologies! I should have read RFC 4953 first. The I-D tracker is still giving me a 404, but I was able to find it on the tcpm WG website. What RFC 4953 discusses is a specific vulnerability in TCP, which involves the fact that reset sequence (RST) numbers can cycle through quickly in large windows, and they make the protocol vulnerable to spurious resets from attackers in that case. So this really is a TCP issue, and I agree that the TCP mapping document in the appropriate place for this if there is an issue, which would depend on the window size. My apologies again for typing without reading first, and for introducing such a red herring. My interpretation of "channel binding attack" in this context was no where near the mark. I now no longer believe that there are any further changes to be made to this document. Also, somebody needs to fix the ID tracker. My attempt to find 4934 wound up in a 404 too. Cathy On Jul 7, 2009, at 3:52 PM, Hollenbeck, Scott wrote: > I made this statement in my response to Sandy: > > "I would need more specific information to know if there's something > to be done with this comment. Reliance on security mechanisms > provided at the transport layer has been part of this specification > since day one. I am not aware of any implementation issues." > > There was no follow-up, so I remain a little unsure of how to > address the comment. Similarly, I need a clarification to know if > the text change suggested below is best made in 4933bis. > > There's a separate document that addresses EPP transport over TCP. > If the channel binding issue is primarily an issue with TCP (is > it?), I'd prefer to address it in the TCP mapping document > (4934bis). If it's more focused on the application-layer exchange > of authorization information I'm OK with making the text change > suggested below in 4933bis. I should note that the same text exists > in 4931bis so I'd need to change it there as well. > > So - where is the most appropriate place to add text? > > -Scott- > > From: Catherine Meadows [mailto:catherine.meadows@nrl.navy.mil] > Sent: Monday, July 06, 2009 11:53 AM > To: secdir@ietf.org; iesg@ietf.org; Hollenbeck, Scott > Cc: Catherine Meadows > Subject: review of draft-hollenbeck-rfc4933bis-02 > > 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. > > Quote from last review: > > "The draft updates RFC 4933, the EPP Contacts Mapping spec. > The updates listed are relatively minor - updates to > references and a few minor updates to text." > > Version 1 has reviewed recently (June 10, by Sandy Murphy) and the > author already > made the changes that were agreed upon in following discussion. > > Everything mostly looks OK to me, but there is one issue that never > got completely resolved > as far as I can tell from what I saw online. This is the question > of channel binding issues as described > RFC 4953. I'm having trouble accessing that document right now, but > apparently the issue is that > low-level authentication mechanisms will not provide any distinction > between channels at a higher level. > This can make it possible for someone with access to the > authentication mechanisms to spoof different channels. > In particular, if the EPP authorization information is protected > with lower-level authentication mechanisms this could > be the case. Unless there is good reason to believe that this sort > of attack is impossible (in which case it would > be a good idea to say why) it might be good > that > >>> Both client and server MUST ensure that authorization >>> information is stored and exchanged with high-grade encryption >>> mechanisms to provide privacy services. > > be changed to > > Both client and server MUST ensure that authorization > information is stored and exchanged with high-grade encryption > mechanisms to provide privacy and authentication services at the > appropriate level > of granularity. > > > Catherine Meadows > Naval Research Laboratory > Code 5543 > 4555 Overlook Ave., S.W. > Washington DC, 20375 > phone: 202-767-3490 > fax: 202-404-7942 > email: catherine.meadows@nrl.navy.mil > Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail-3-326275132 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable My apologies!  I should = have read RFC 4953 first.  The I-D tracker is still giving me = a 404,
but I was able to find it on the tcpm WG = website.

What RFC 4953 discusses is a = specific vulnerability in TCP, which involves the fact that reset = sequence (RST) numbers can cycle through quickly in large = windows,
and they make the protocol vulnerable to spurious = resets from attackers in that case.  So this really is a TCP issue, = and I agree that the TCP mapping document in the appropriate place = for
this if there is an issue, which would depend on the = window = size. 

My apologies again for=  typing without reading first, and for = introducing such a red herring.  My int= erpretation of "channel binding attack" in this = context was no where near the mark.
I now no longer believe that there are any further changes to be made = to this document.

Also, somebody needs to fix = the ID tracker.  My attempt to find 4934 wound up in a 404 = too.

Cathy

On Jul 7, = 2009, at 3:52 PM, Hollenbeck, Scott wrote:

=
I made this statement in my response = to Sandy:
 
"I would need more specific = information to know if there's something to be done with this comment. = Reliance on security mechanisms provided at the transport layer has been = part of this specification since day one. I am not aware of any = implementation issues."
 
There was no follow-up, so I remain a little unsure of = how to address the comment.  Similarly, I need a clarification = to know if the text change suggested below is best made in = 4933bis.
 
There's a separate document that addresses EPP = transport over TCP.  If the channel binding issue is primarily an = issue with TCP (is it?), I'd prefer to address it in the TCP mapping = document (4934bis).  If it's more focused on the application-layer = exchange of authorization information I'm OK with making the text change = suggested below in 4933bis.  I should note that the same text = exists in 4931bis so I'd need to change it there as = well.
 
So - where is the most appropriate place to add = text?
 
-Scott-

From: Catherine Meadows [mailto:catherine.meadows@nr= l.navy.mil]
Sent: Monday, July 06, 2009 11:53 = AM
To: secdir@ietf.org; = iesg@ietf.org; Hollenbeck, = Scott
Cc: Catherine Meadows
Subject: review of = draft-hollenbeck-rfc4933bis-02

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.

Quote from last = review:

"The draft updates RFC 4933, the EPP = Contacts Mapping spec.  
The updates listed are relatively = minor - updates to 
references and a few minor updates to = text."

Version 1 has = reviewed recently (June 10, by Sandy Murphy)=  and the author already
=
made the changes that were agreed upon&= nbsp;in following discussion.

=
Everything mostly looks OK to me, but&n= bsp;there is one issue that never got c= ompletely resolved
=
as far as I can tell from what&nbs= p;I saw online.  This is the question&n= bsp;of channel binding issues as described
=
RFC 4953.  I'm having trouble accessing that document right = now, but apparently the issue is that
low-level = authentication mechanisms will not provide any distinction between = channels at a higher level.
This can make it possible for = someone with access to the authentication mechanisms to spoof = different channels.
In particular, if the EPP authorization = information is protected with lower-level authentication mechanisms = this could
be the case.  Unless there is good reason to = believe that this sort of attack is impossible (in which case it = would
be a good idea to say why) it might be = good 
that 

=
Both client and = server MUST ensure that authorization
=
   information is stored and = exchanged with high-grade encryption
   mechanisms to provide privacy = services.

be changed to
=

Both client and server MUST ensure that = authorization
   information is stored and exchanged = with high-grade encryption
   mechanisms to provide = privacy and authentication services at the appropriate level
=
of granularity.


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


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

= --Apple-Mail-3-326275132-- From shollenbeck@verisign.com Wed Jul 8 12:29:56 2009 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 44C643A6B11; Wed, 8 Jul 2009 12:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 gsB4DapG-hGz; Wed, 8 Jul 2009 12:29:54 -0700 (PDT) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id 7D3273A6B5E; Wed, 8 Jul 2009 12:29:54 -0700 (PDT) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n68JIK0v029430; Wed, 8 Jul 2009 15:18:20 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 20:30:20 +0100 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_01CA0002.87D4B30B" Date: Wed, 8 Jul 2009 15:30:19 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0702B8DAD5@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <6F8E48C3-9E52-4912-B748-3C9A43519EA7@nrl.navy.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of draft-hollenbeck-rfc4933bis-02 Thread-Index: Acn/5Xk32/Jg0jNCRdmxwandTw+Q9wAHQUVw References: <897517DC-2F59-440A-BD63-BD71E1AF4421@nrl.navy.mil> <046F43A8D79C794FA4733814869CDF0702B8DA2E@dul1wnexmb01.vcorp.ad.vrsn.com> <6F8E48C3-9E52-4912-B748-3C9A43519EA7@nrl.navy.mil> From: "Hollenbeck, Scott" To: "Catherine Meadows" X-OriginalArrivalTime: 08 Jul 2009 19:30:20.0731 (UTC) FILETIME=[882178B0:01CA0002] Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] review of draft-hollenbeck-rfc4933bis-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, 08 Jul 2009 19:29:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0002.87D4B30B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No problem here - thanks for the clarification! =20 -Scott- ________________________________ From: Catherine Meadows [mailto:catherine.meadows@nrl.navy.mil]=20 Sent: Wednesday, July 08, 2009 12:02 PM To: Hollenbeck, Scott Cc: Catherine Meadows; secdir@ietf.org; iesg@ietf.org Subject: Re: review of draft-hollenbeck-rfc4933bis-02 =09 =09 My apologies! I should have read RFC 4953 first. The I-D tracker is still giving me a 404,=20 but I was able to find it on the tcpm WG website. What RFC 4953 discusses is a specific vulnerability in TCP, which involves the fact that reset sequence (RST) numbers can cycle through quickly in large windows, and they make the protocol vulnerable to spurious resets from attackers in that case. So this really is a TCP issue, and I agree that the TCP mapping document in the appropriate place for this if there is an issue, which would depend on the window size.=20 My apologies again for typing without reading first, and for introducing such a red herring. My interpretation of "channel binding attack" in this context was no where near the mark. I now no longer believe that there are any further changes to be made to this document. Also, somebody needs to fix the ID tracker. My attempt to find 4934 wound up in a 404 too. Cathy On Jul 7, 2009, at 3:52 PM, Hollenbeck, Scott wrote: I made this statement in my response to Sandy: =20 "I would need more specific information to know if there's something to be done with this comment. Reliance on security mechanisms provided at the transport layer has been part of this specification since day one. I am not aware of any implementation issues." =20 There was no follow-up, so I remain a little unsure of how to address the comment. Similarly, I need a clarification to know if the text change suggested below is best made in 4933bis. =20 There's a separate document that addresses EPP transport over TCP. If the channel binding issue is primarily an issue with TCP (is it?), I'd prefer to address it in the TCP mapping document (4934bis). If it's more focused on the application-layer exchange of authorization information I'm OK with making the text change suggested below in 4933bis. I should note that the same text exists in 4931bis so I'd need to change it there as well. =20 So - where is the most appropriate place to add text? =20 -Scott- ________________________________ From: Catherine Meadows [mailto:catherine.meadows@nrl.navy.mil]=20 Sent: Monday, July 06, 2009 11:53 AM To: secdir@ietf.org; iesg@ietf.org; Hollenbeck, Scott Cc: Catherine Meadows Subject: review of draft-hollenbeck-rfc4933bis-02 =09 =09 I have reviewed this document as part of the security=20 directorate's ongoing effort to review all IETF documents=20 being processed by the IESG.=20 These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs=20 should treat these comments just like any other last call comments.=20 Quote from last review: =09 "The draft updates RFC 4933, the EPP Contacts Mapping spec. =20 The updates listed are relatively minor - updates to=20 references and a few minor updates to text." Version 1 has reviewed recently (June 10, by Sandy Murphy) and the author already made the changes that were agreed upon in following discussion. Everything mostly looks OK to me, but there is one issue that never got completely resolved as far as I can tell from what I saw online. This is the question of channel binding issues as described RFC 4953. I'm having trouble accessing that document right now, but apparently the issue is that low-level authentication mechanisms will not provide any distinction between channels at a higher level. This can make it possible for someone with access to the authentication mechanisms to spoof different channels. In particular, if the EPP authorization information is protected with lower-level authentication mechanisms this could be the case. Unless there is good reason to believe that this sort of attack is impossible (in which case it would be a good idea to say why) it might be good=20 that=20 Both client and server MUST ensure that authorization =09 information is stored and exchanged with high-grade encryption =09 mechanisms to provide privacy services. be changed to Both client and server MUST ensure that authorization information is stored and exchanged with high-grade encryption mechanisms to provide privacy and authentication services at the appropriate level of granularity. =09 Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil =09 Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil ------_=_NextPart_001_01CA0002.87D4B30B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
No problem here - thanks for the=20 clarification!
 
-Scott-

From: Catherine Meadows=20 [mailto:catherine.meadows@nrl.navy.mil]
Sent: Wednesday, = July 08,=20 2009 12:02 PM
To: Hollenbeck, Scott
Cc: Catherine = Meadows;=20 secdir@ietf.org; iesg@ietf.org
Subject: Re: review of=20 draft-hollenbeck-rfc4933bis-02

My apologies!  I should have read RFC 4953 first. =  The I-D tracker is still giving me a 404,
but I was able to find it on the tcpm WG website.

What RFC 4953 discusses is a specific vulnerability in TCP, = which=20 involves the fact that reset sequence (RST) numbers can cycle through = quickly=20 in large windows,
and they make the protocol vulnerable to spurious resets from = attackers=20 in that case.  So this really is a TCP issue, and I agree that = the TCP=20 mapping document in the appropriate place for
this if there is an issue, which would depend on the window=20 size. 

=
My apologies again for typing without = reading first, and for introducing such a&n= bsp;red herring.  My interpretation of "cha= nnel binding attack" in=20 this = context was no where near the mark.
I now no longer believe that there are any further changes to be = made to=20 this document.

Also, somebody needs to fix the ID tracker.  My attempt to = find 4934=20 wound up in a 404 too.

Cathy

On Jul 7, 2009, at 3:52 PM, Hollenbeck, Scott wrote:
I made this statement in my response to=20 Sandy:
 
"I would need more specific = information to know=20 if there's something to be done with this comment. Reliance on = security=20 mechanisms provided at the transport layer has been part of this=20 specification since day one. I am not aware of any implementation=20 issues."
 
There was no follow-up, so I remain a little unsure = of how=20 to address the comment.  Similarly, I need a clarification = to know=20 if the text change suggested below is best made in=20 4933bis.
 
There's a separate document that addresses EPP = transport over=20 TCP.  If the channel binding issue is primarily an issue with = TCP (is=20 it?), I'd prefer to address it in the TCP mapping document = (4934bis). =20 If it's more focused on the application-layer exchange of = authorization=20 information I'm OK with making the text change suggested below in=20 4933bis.  I should note that the same text exists in 4931bis so = I'd=20 need to change it there as well.
 
So - where is the most appropriate place to add = text?
 
-Scott-

From: Catherine Meadows [mailto:catherine.meadows@n= rl.navy.mil]=20
Sent: Monday, July 06, 2009 11:53 AM
To: secdir@ietf.org; iesg@ietf.org; Hollenbeck,=20 Scott
Cc: Catherine Meadows
Subject: review of = draft-hollenbeck-rfc4933bis-02

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

Quote from last review:

"The draft updates RFC 4933, the EPP Contacts Mapping spec.=20  
The updates listed are relatively minor - updates=20 to 
references and a few minor updates to text."

Version 1 has=20 = reviewed recently (June 10, by Sandy Murphy= ) and the author already
=
made the changes that were agreed upon=  in following discussion.

=
Everything mostly looks OK to me, but&= nbsp;there is one issue that never got = ;completely resolved
=
as far as I can tell from what&nb= sp;I saw online.  This is the question=  of channel binding issues as described
RFC 4953.  I'm having trouble accessing that document = right now,=20 but apparently the issue is that
low-level authentication mechanisms will not provide any = distinction=20 between channels at a higher level.
This can make it possible for someone with access to the=20 authentication mechanisms to spoof different channels.
In particular, if the EPP authorization information is = protected with=20 lower-level authentication mechanisms this could
be the case.  Unless there is good reason to believe = that this=20 sort of attack is impossible (in which case it would
be a good idea to say why) it might be good 
that 

Both client and server MUST ensure = that=20 authorization
   information is = stored and=20 exchanged with high-grade encryption
   mechanisms to = provide=20 privacy services.

be changed to

Both client and server MUST ensure that=20 authorization
   information is stored and = exchanged=20 with high-grade encryption
   mechanisms to = provide=20 privacy and authentication services at the appropriate level
of granularity.


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


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

------_=_NextPart_001_01CA0002.87D4B30B-- From weiler+secdir@watson.org Wed Jul 8 19:18:33 2009 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 17A5E3A6F64 for ; Wed, 8 Jul 2009 19:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2PG2Dw6UzXD for ; Wed, 8 Jul 2009 19:18:32 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 121303A68F8 for ; Wed, 8 Jul 2009 19:18:31 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n692IwVZ057194 for ; Wed, 8 Jul 2009 22:18:58 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n692IwZa057191 for ; Wed, 8 Jul 2009 22:18:58 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 8 Jul 2009 22:18:58 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Thu, 09 Jul 2009 03:18:58 +0100 (BST) Subject: [secdir] Assignments for July 14th 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: Thu, 09 Jul 2009 02:18:33 -0000 If you've been keeping your secdir reviews on your own todo list, this would be a good time to check the list below to make sure a review is still wanted for the doc: at least ten docs were removed from the assignment backlog last week because they were on the July 2nd telechat. Stefan Santesson is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-07-16 Reviewer Draft Tobias Gondrom T draft-ietf-nea-pa-tnc-04 Phillip Hallam-Baker T draft-ietf-nea-pb-tnc-04 Scott Kelly T draft-ietf-softwire-lb-03 Julien Laganier T draft-hollenbeck-rfc4934bis-01 Catherine Meadows T draft-hollenbeck-rfc4930bis-02 Sandy Murphy TR draft-hollenbeck-rfc4933bis-02 Chris Newman T draft-ietf-sip-connect-reuse-13 Nico Williams T draft-ietf-pcn-marking-behaviour-04 Glen Zorn T draft-solinas-suiteb-cert-profile-04 For telechat 2009-08-13 Reviewer Draft Dave Cridland T draft-ietf-behave-nat-behavior-discovery-07 Radia Perlman T draft-ietf-pwe3-mpls-transport-04 Last calls and special requests: Reviewer Draft Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 Steve Hanna draft-peterson-rai-rfc3427bis-02 Steve Hanna draft-ietf-netconf-partial-lock-09 Love Hornquist-Astrand draft-ietf-ipfix-mib-06 Love Hornquist-Astrand draft-ietf-opsawg-smi-datatypes-in-xsd-05 Charlie Kaufman draft-ietf-ipsecme-ikev2-redirect-11 Stephen Kent draft-ietf-l3vpn-as4octet-ext-community-03 Julien Laganier draft-ietf-sip-certs-07 Julien Laganier draft-ietf-l3vpn-v6-ext-communities-02 Barry Leiba draft-ietf-simple-interdomain-scaling-analysis-07 Catherine Meadows draft-ietf-speechsc-mrcpv2-19 Sandy Murphy draft-ietf-speermint-voip-consolidated-usecases-13 Vidya Narayanan draft-ietf-sip-saml-06 Vidya Narayanan draft-ietf-enum-3761bis-04 Vidya Narayanan draft-ietf-opsawg-syslog-snmp-03 Chris Newman draft-ietf-mpls-tp-requirements-09 Magnus Nystrom draft-ietf-opsawg-syslog-msg-mib-04 Hilarie Orman draft-ietf-ospf-hmac-sha-05 Eric Rescorla draft-ietf-enum-iax-05 Eric Rescorla draft-ietf-simple-xcap-diff-13 Joe Salowey draft-ietf-geopriv-lis-discovery-11 Joe Salowey draft-ietf-sipping-service-identification-03 Hannes Tschofenig draft-ietf-pce-monitoring-05 Sam Weiler draft-chown-v6ops-rogue-ra-03 Nico Williams draft-ietf-v6ops-ra-guard-03 Larry Zhu draft-thaler-v6ops-teredo-extensions-03 Larry Zhu draft-ietf-ecrit-location-hiding-req-01 From lars.eggert@nokia.com Thu Jul 9 00:06:49 2009 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 1EC653A68B5; Thu, 9 Jul 2009 00:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 q7tFYNlPYdnF; Thu, 9 Jul 2009 00:06:48 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id DCE773A67DD; Thu, 9 Jul 2009 00:06:47 -0700 (PDT) Received: from [192.168.0.197] (funet-wlan.fit.nokia.com [195.148.124.254]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n69772o9021500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 9 Jul 2009 10:07:02 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <03C04ACE-5773-4260-AABD-E799E614C469@nokia.com> From: Lars Eggert To: Sandra Murphy In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-21-380561542; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 9 Jul 2009 10:06:57 +0300 References: X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Thu, 09 Jul 2009 10:07:03 +0300 (EEST) Cc: "mdalal@cisco.com" , "ananth@cisco.com" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure 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, 09 Jul 2009 07:06:49 -0000 --Apple-Mail-21-380561542 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, Sandy, On 2009-6-8, at 16:59, Sandra Murphy wrote: > I've been on the road, so this is just a quick note to say that I > still > have questions, with a promise of more full answer when I get back > to the > office tomorrow. the authors are still waiting to hear your additional questions. Please let me know when we can expect them, so I know when I can expect a revision from the authors. Thanks, Lars > All the following done really from memory from a > re-review yesterday. Just so you know I haven't forgotten you. > > About quoting text: > > The example you point to of what each mitigation says is a good case. > (what is "rg"?) > > You posit a case 1 and case 2. This is a summary of what 793 says, > not a > quote. 793 spreads the discussion over 2 pages. your case 1 is > represented in a parenthetical remark in an "otherwise" clause - > hard to > find. And you have a typo in the inequality. And the case 2 in 793 > is > broken out over three different groupings of states. Do you mean > the new > ACK to be generated in all three state groups? > > About the stingency. > > If UNA is 1000, Max.snd.wnd is 50, and the ack is 975, then in 793, > the > ack is < UNA and so "it is ignored", in your draft the ack is > > UNA-max.snd.wnd so it is acceptable. > > So your draft accepts more ACKs that 793. > > Have I lost my ability to tell > from ACKS as "more stringent"? > > About the guidance to implementors. > > It still looks to me like this guidance is only useful to > implementors who > are implementing both the OS TCP stack *AND* the application. I.E., > freebsd won't know whether this to follow the guidance or not but > cisco/juniper/etc will. > > What is the "AS"? > > About grammar checks: > > And you did not miss email, I lost my marked up copy, so I've gone > through for the grammar check again (don't think I found all that many > nits) and will send to you. > > --Sandy > > --Apple-Mail-21-380561542 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA3MDkwNzA2NTdaMCMGCSqGSIb3DQEJBDEWBBRGmMhq49IDEo06 ebFGuUT5lwNK0TCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAgbbhPY5Pfsf9WOR53CyFTJ0bePulo7c7YrTCNyB5uHPJVyX5rtAc vaA3fdQyRg6HrFpfrrlie8yCuL6oXzo73RciAgTJEVn3F9AsSHXlMOhWtY4tWS5tUf3wIfI47B73 IHJoYiYSblM/rdWMDOAwu5ES+aiucP8IEkzibhCZFRuwAlFABdQLKph12bY1dL0+2Vm0ARNI0mtl hr8/aB4+xmbmDEFMdxZuzHmVZwu8DHty1JOiXBf2qNl8B3oLPb6BdCGkqSqHd1t99wWBxmjSgfcY eiG8sY6+abLwY9eSKxuQavm9Aj67mzLwCTNAYILMuI64cYhusaYFOftIwpGeJwAAAAAAAA== --Apple-Mail-21-380561542-- From watson@qualcomm.com Wed Jul 8 14:59:27 2009 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 2FB5D3A6A6D; Wed, 8 Jul 2009 14:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.798 X-Spam-Level: X-Spam-Status: No, score=-105.798 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 usIJiJS+oviz; Wed, 8 Jul 2009 14:59:17 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 231BB28C105; Wed, 8 Jul 2009 14:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1247090377; x=1278626377; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Watson,=20Mark"=20|To:=20C atherine=20Meadows=20,=0D =0A=20=20=20=20=20=20=20=20"iesg@ietf.org"=0D=0A=09,=20"secdir@ietf.org"=20,=0D=0A =20=20=20=20=20=20=20=20"Luby,=20Michael"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"Vicisano,=20L orenzo"=20,=0D=0A=20=20=20=20=20 =20=20=20Brian=0D=0A=20Adamson=20,=0D=0A=20=20=20=20=20=20=20=20"lorenzo@vicisano.net" =0D=0A=09|Date:=20Wed,=208=20Jul=20 2009=2014:59:29=20-0700|Subject:=20Re:=20Secdir=20review =20of=20draft-ietf-rmt-bb-lct-revised-09=20=20 |Thread-Topic:=20Secdir=20review=20of=20draft-ietf-rmt-bb -lct-revised-09=20=20|Thread-Index:=20Acn7V2W7RxTwzRksSdi XIBt3MPJuxAEv/f4T|Message-ID:=20|In-Reply-To:=20<79F2D899-118B-4FBD-BA29-9B65F FD6F6B7@nrl.navy.mil>|Accept-Language:=20en-US |Content-Language:=20en|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_C67A64D12EE47watsonqualcommcom_"|MIME-Version: =201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5670" =3B=20a=3D"20452354"; bh=2HOLU2PfxmnwyZlpqBdP3cuXE/PzFwB2DYXjwfqsT4Y=; b=T9lGFkcWFwQ18LVmgwHaYlxzdZvlweu1HL6biUCBqQSdXOKvsZD1hIOW UmrGG++5WVbbabKIgLRLoOoS/3Yn9ZV/nqKLPePvlC0b9BwCng/0LZxdL nKaDO7jw6kMqvy0rT4K6t9eQ8/8ooyANPYRcd8Ggj3mXrLGyG1yenEwGd A=; X-IronPort-AV: E=McAfee;i="5300,2777,5670"; a="20452354" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2009 14:59:37 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n68LxaIc014329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 Jul 2009 14:59:37 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n68LxZUk014906 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Jul 2009 14:59:36 -0700 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 8 Jul 2009 14:59:35 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Wed, 8 Jul 2009 14:59:35 -0700 From: "Watson, Mark" To: Catherine Meadows , "iesg@ietf.org" , "secdir@ietf.org" , "Luby, Michael" , "Vicisano, Lorenzo" , Brian Adamson , "lorenzo@vicisano.net" Date: Wed, 8 Jul 2009 14:59:29 -0700 Thread-Topic: Secdir review of draft-ietf-rmt-bb-lct-revised-09 Thread-Index: Acn7V2W7RxTwzRksSdiXIBt3MPJuxAEv/f4T Message-ID: In-Reply-To: <79F2D899-118B-4FBD-BA29-9B65FFD6F6B7@nrl.navy.mil> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C67A64D12EE47watsonqualcommcom_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 09 Jul 2009 08:48:32 -0700 Subject: Re: [secdir] Secdir review of draft-ietf-rmt-bb-lct-revised-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: Wed, 08 Jul 2009 21:59:27 -0000 --_000_C67A64D12EE47watsonqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Catherine, Thanks for your comments. To addess them I propose a small re-write of the = security section as shown below. Note that I am suggesting to remove the se= ction on "Forged session description attacks" section as transport of sessi= on descriptions is not a service provided by LCT. Instead I added a new par= agraph to the introduction and expanded a little (since the issue of secure= ly verifying the correspondance between session description and session dat= a packets was not addressed). 8. Security Considerations LCT is a Building Block as defined in [RFC3048] and as such does not define a complete protocol. Protocol Instantiations which use the LCT building block MUST address the potential vulnerabilities described in the following sections. For an example, see [I-D.ietf-rmt-pi-alc-revised]. Protocol Instantiations could address the vulnerabilities described below by taking measures to prevent receivers from accepting incorrect packets, for example by using a source authentication and content integrity mechanis= m. Note that for correct operation LCT assumes availability of session descrip= tion information (see Section 4). Incorrect or maliciously modified session= description information may result in receivers being unable to correctly = receive the session content, or that receivers inadvertently try to receive= at a much higher rate than they are capable of, thereby disrupting traffic= in portions of the network. Protocol Instantiations MUST address this pote= ntial vulnerability, for example by providing source authentication and int= egrity mechanisms for the session description. Additionally, these mechanis= ms MUST allow the receivers to securely verify the correspondence between s= ession description and LCT data packets. The following sections consider further each of the services provided by LC= T: 8.1 Session and object multiplexing and termination The Transport Session Identifier, Transport Object Identifier in the LCT he= ader provide for multiplexing of sessions and objects. Modification of thes= e fields by an attacker could have the effect of depriving a session or obj= ect of data and potentially directing incorrect data to another session or = object, in both cases effecting a denial-of-service attack. Additionally, injection of forged packets with fake TSI or TOI values may c= ause receivers to allocate resources for additional sessions or objects, ag= ain potentially effecting a DoS attack. The Close Object and Close Session bits in the LCT header provide for signa= ling of the end of a session or object. Modification of these fields by an = attacker could cause receivers to incorrectly behave as if the session or o= bject had ended, resulting in a denial-of-service attack, or conversely to = continue to unnecessarily utilize resources after the session or object has= ended (although resource utilisation in this case is largely an implementa= tion issue). As a result of the above vulnerabilities, these fields MUST be protected by= Protocol Instantiation security mechanisms (for example source authenticat= ion and data integrity mechanisms). 8.2 Time synchronisation The SCT and ERT mechanisms provide rudimentary time synchronization feature= s which can both be subject to attacks. Indeed an attacker can easily de-syn= chronize clients, sending erroneous SCT information, or mount a DoS attack by inform= ing all clients that the session (resp. a particular object) is about to be closed. As a result of the above vulnerabilities, these fields MUST be protected by= Protocol Instantiation security mechanisms (for example source authenticat= ion and data integrity mechanisms). 8.3 Data transport The LCT protocol provides for transport of information for other Building B= locks, specifically the PSI field for the Protocol Instantiation, the Conge= stion Control field for the Congestion Control Building Block, the Codepoin= t field for the FEC Building Block, the EXT-AUTH Header Extension (used by = the Protocol Instantiation) and the packet payload itself. Modification of any of these fields by an attacker may result in a Denial-o= f-service attack. In particular, modification of the Codepoint or packet pa= yload may prevent successful reconstruction or cause inaccurate reconstruct= ion of large portions of an object by receivers. Modification of the Conges= tion Control field may cause receivers to attempt to receive at an incorrec= t rate, potentially worsening or causing a congestion situation and thereby= effecting a DoS attack. As a result of the above vulnerabilities, these fields MUST be protected by= Protocol Instantiation security mechanisms (for example source authenticat= ion and data integrity mechanisms). ...Mark On 7/2/09 1:54 PM, "Catherine Meadows" wro= te: 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 paper concerns the Layered Coding Transport building block. LCT provi= des support for massively scalable protocols using the IP multicast network ser= vice. LCT supports sessions consisting or multiple channels, all with the same se= nder, but many different receivers. This makes it compatible with many massively sca= lable congestion control protocols that use this structure. When we are dealing with massively scalable congestion control protocols, t= he question of denial of service naturally comes to mind. Thus the security considerat= ions section rightly mainly concerns itself with that. However, it left me with several= questions. 1. The introduction says that "Protocol Instantiations that use the LCT bu= ilding block MUST address the security requirements described in the following sections." B= ut there are no MUSTs or MUST NOTs in the following sections. Indeed,sections 8.1 and 8.2 don't = contain any recommendations at all; they simply identify vulnerabilities (which could, however, be addr= essed by authentication). I would suggest either toning down the introduction ("MUST address the potential vu= lnerabilities" instead of "MUST address the requirements") or beef up the specific sections. 2. The sections themselves have a kind of piecemeal feel about them, addre= ssing specific potential attacks, but without giving a feeling that everything that is covered. It might be a be= tter idea to describe what services security mechanisms could provide (e.g. authentication, confidentiality) describe the various e= ach service offered by LCT and its vulnerabilities, and then what security services would address. I suspect, given the vulner= abilities that the authors have already described, it would mostly boil down to identifying which LCT data should or must be auth= enticated. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --_000_C67A64D12EE47watsonqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Secdir review of draft-ietf-rmt-bb-lct-revised-09   Hi Catherine,

Thanks for your comments. To addess them I propose a small re-write of the = security section as shown below. Note that I am suggesting to remove the se= ction on “Forged session description attacks” section as transp= ort of session descriptions is not a service provided by LCT. Instead I add= ed a new paragraph to the introduction and expanded a little (since the iss= ue of securely verifying the correspondance between session description and= session data packets was not addressed).

8. Security Considerations

LCT is a Building Block as defined in [RFC3048] and = as such does not
define a complete protocol.  Protocol Instantiations which use the
LCT building block MUST address the potential vulnerabilities described
in the following sections.  For an example, see
[I-D.ietf-rmt-pi-alc-revised].

Protocol Instantiations could address the vulnerabilities described below by taking measures to prevent receivers from accepting incorrect packets, for example by using a source authentication and content integrity mechanis= m.

Note that for correct operation LCT assumes availability of session descrip= tion information (see Section 4). Incorrect or maliciously modified session= description information may result in receivers being unable to correctly = receive the session content, or that receivers inadvertently try to receive= at a much higher rate than they are capable of, thereby disrupting traffic= in portions of the network. Protocol Instantiations MUST address this pote= ntial vulnerability, for example by providing source authentication and int= egrity mechanisms for the session description. Additionally, these mechanis= ms MUST allow the receivers to securely verify the correspondence between s= ession description and LCT data packets.

The following sections consider further each of the services provided by LC= T:

8.1  Session and object multiplexing and termination

The Transport Session Identifier, Transport Object Identifier in the LCT he= ader provide for multiplexing of sessions and objects. Modification of thes= e fields by an attacker could have the effect of depriving a session or obj= ect of data and potentially directing incorrect data to another session or = object, in both cases effecting a denial-of-service attack.

Additionally, injection of forged packets with fake TSI or TOI values may c= ause receivers to allocate resources for additional sessions or objects, ag= ain potentially effecting a DoS attack.

The Close Object and Close Session bits in the LCT header provide for signa= ling of the end of a session or object. Modification of these fields by an = attacker could cause receivers to incorrectly behave as if the session or o= bject had ended, resulting in a denial-of-service attack, or conversely to = continue to unnecessarily utilize resources after the session or object has= ended (although resource utilisation in this case is largely an implementa= tion issue).

As a result of the above vulnerabilities, these fields MUST be protected by= Protocol Instantiation security mechanisms (for example source authenticat= ion and data integrity mechanisms).

8.2  Time synchronisation

The SCT and ERT mechanisms provide rudimentary time synchronization feature= s
which can both be subject to attacks.  Indeed an attacker can easily d= e-synchronize
clients, sending erroneous SCT information, or mount a DoS attack by inform= ing all
clients that the session (resp. a particular object) is about to be closed.=

As a result of the above vulnerabilities, these fields MUST be protected by= Protocol Instantiation security mechanisms (for example source authenticat= ion and data integrity mechanisms).

8.3  Data transport

The LCT protocol provides for transport of information for other Building B= locks, specifically the PSI field for the Protocol Instantiation, the Conge= stion Control field for the Congestion Control Building Block, the Codepoin= t field for the FEC Building Block, the EXT-AUTH Header Extension (used by = the Protocol Instantiation) and the packet payload itself.

Modification of any of these fields by an attacker may result in a Denial-o= f-service attack. In particular, modification of the Codepoint or packet pa= yload may prevent successful reconstruction or cause inaccurate reconstruct= ion of large portions of an object by receivers. Modification of the Conges= tion Control field may cause receivers to attempt to receive at an incorrec= t rate, potentially worsening or causing a congestion situation and thereby= effecting a DoS attack.

As a result of the above vulnerabilities, these fields MUST be protected by= Protocol Instantiation security mechanisms (for example source authenticat= ion and data integrity mechanisms).

...Mark

On 7/2/09 1:54 PM, "Catherine Meadows" <catherine.meadows@nrl.navy.mil> wrote:

I have reviewed this document as part of th= e 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 paper concerns the Layered Coding Transport building block.  LCT = provides
support for massively scalable protocols using the IP multicast network ser= vice.
LCT supports sessions consisting or multiple channels, all with the same se= nder, but
many different receivers.  This makes it compatible with many massivel= y scalable congestion
control protocols that use this structure.

When we are dealing with massively scalable congestion control protocols, t= he question
of denial of service naturally comes to mind.  Thus the security consi= derations section
rightly mainly concerns itself with that.  However, it left me with se= veral questions.

1.  The introduction says that "Protocol Instantiations that use = the LCT building block MUST
address the security requirements described in the following sections."= ;   But there are no MUSTs
or MUST NOTs in the following sections.  Indeed,sections 8.1 and 8.2 d= on't contain any recommendations
at all; they simply identify vulnerabilities (which could, however, be addr= essed by authentication).  I would
suggest either toning down the introduction ("MUST address the potenti= al vulnerabilities" instead of "MUST address
the requirements") or beef up the specific sections.

2.  The sections themselves have a kind of piecemeal feel about them, = addressing specific potential attacks, but
without giving a feeling that everything that is covered.  It might be= a better idea to describe what services security mechanisms
could provide (e.g. authentication, confidentiality) describe the various e= ach service offered by LCT and its vulnerabilities,
and then what security services would address.  I suspect, given the v= ulnerabilities that the authors have already described, it
would mostly boil down to identifying which LCT data should or must be auth= enticated.


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


--_000_C67A64D12EE47watsonqualcommcom_-- From kent@bbn.com Thu Jul 9 11:32:38 2009 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 4F68E28C27E for ; Thu, 9 Jul 2009 11:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cwi1s6UFnFv1 for ; Thu, 9 Jul 2009 11:32:34 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 2B6433A6B81 for ; Thu, 9 Jul 2009 11:32:33 -0700 (PDT) Received: from dhcp89-089-096.bbn.com ([128.89.89.96]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MOyQU-0006RR-AX; Thu, 09 Jul 2009 14:32:59 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 9 Jul 2009 14:32:56 -0400 To: secdir@core3.amsl.com From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-964958118==_ma============" Cc: yakov@juniper.net, Dan.Tappan@Gmail.com, rsrihari@cisco.com Subject: [secdir] review of draft-ietf-l3vpn-as4octet-ext-community-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: Thu, 09 Jul 2009 18:32:38 -0000 --============_-964958118==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Draft-ietf-l3vpn-as4octet-ext-community-03.txt is a very brief (6 page) document that defines a new type of BGP extended community, one that can carry 32-bit AS numbers. It is a simple, logical successor to the existing extended community structure, which is limited to representing 16-bit AS numbers. The Security Considerations section states that "All the security considerations for BGP Extended Communities apply here." This may not be very informative for the average reader. I thought it might be preferable to include references here to relevant Security Considerations sections from prior RFCs dealing with this topic. So, I looked at RFC 4360 (BGP Extended Communities Attribute), since that is the document that is being extended to accommodate 32-bit ASNs. However, that document has a largely vacuous security considerations section: "This extension to BGP has similar security implications as BGP Communities [RFC1997]. This extension to BGP does not change the underlying security issues. Specifically, an operator who is relying on the information carried in BGP must have a transitive trust relationship back to the source of the information. Specifying the mechanism(s) to provide such a relationship is beyond the scope of this document." I then looked at RFC 1997, and discovered that its Security Considerations section states: "Security issues are not discussed in this memo." I suggest the authors take the time to write a meaningful Security Considerations section addressing BGP Extended Communities, since none of the prior documents on this topic seem to have done so. --============_-964958118==_ma============ Content-Type: text/html; charset="us-ascii" review of draft-ietf-l3vpn-as4octet-ext-community-03
I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Draft-ietf-l3vpn-as4octet-ext-community-03.txt is a very brief (6 page) document that defines a new type of BGP extended community, one that can carry 32-bit AS numbers. It is a simple, logical successor to the existing extended community structure, which is limited to representing 16-bit AS numbers.

The Security Considerations section states that "All the security considerations for BGP Extended Communities apply here."  This may not be very informative for the average reader. I thought it might be preferable to include references here to relevant Security Considerations sections from prior RFCs dealing with this topic. So, I looked at RFC 4360 (BGP Extended Communities Attribute), since that is the document that is being extended to accommodate 32-bit ASNs. However, that document has a largely vacuous security considerations section:

"This extension to BGP has similar security implications as BGP Communities [RFC1997].

This extension to BGP does not change the underlying security issues. Specifically, an operator who is relying on the information carried in BGP must have a transitive trust relationship back to the source of the information.  Specifying the mechanism(s) to provide such a relationship is beyond the scope of this document."

I then looked at RFC 1997, and discovered that its Security Considerations section states:

"Security issues are not discussed in this memo."
I suggest the authors take the time to write a meaningful Security Considerations section addressing BGP Extended Communities, since none of the prior documents on this topic seem to have done so.
--============_-964958118==_ma============-- From kent@bbn.com Thu Jul 9 12:12:55 2009 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 506C23A67DF for ; Thu, 9 Jul 2009 12:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzGhoVsTw645 for ; Thu, 9 Jul 2009 12:12:54 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 048443A6A87 for ; Thu, 9 Jul 2009 12:12:54 -0700 (PDT) Received: from dhcp89-089-096.bbn.com ([128.89.89.96]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MOz3Y-0006yO-BO; Thu, 09 Jul 2009 15:13:20 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 9 Jul 2009 15:13:18 -0400 To: secdir@core3.amsl.com From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-964955696==_ma============" Cc: hgs+ecrit@cs.columbia.edu, Hannes.Tschofenig@gmx.net Subject: [secdir] review of draft-ietf-geopriv-l7-lcp-ps-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: Thu, 09 Jul 2009 19:12:55 -0000 --============_-964955696==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Draft-ietf-geopriv-l7-lcp-ps-09.txt is a problem statement and requirements and design decisions document dealing with the layer 7 location configuration protocol (L7 LCP) being developed in the GEOPRIV WG. As stated in the abstract: This protocol aims to allow an end host to obtain location information, by value or by reference, from a Location Information Server (LIS) that is located in the access network. The obtained location information can then be used for a variety of different protocols and purposes. A protocol of this sort engenders significant privacy concerns. I was disappointed that the document does not do a good job of clearly stating these concerns and collecting them in one place, e.g., the Secruity Consideration section or the requirements section. Section 3 of the document describes four types of network environments: 1. DLS/cable nets and WiMax-like fixed access 2. Airport, City, Campus Wireless Networks (e.g., 802.11/a/b/g and Wimax) 3. 3G 4. Enterprise At the top level, this seems to be an odd taxonomy, e.g., how are 802.11 nets (2) different from enterprise nets (4) in general? One has to read the detailed examples that follow to try to learn why these are meaningfully different environments re the L7 LCP. It doesn't help that the examples provided do not correspond directly to the four environments named above! This section could be improved in this regard. Sections 4 & 5 document some of the issues that the L7 LCP design team has explored. There are some security-relevant observations in these sections, e.g., "The LIS discovery procedure raises deployment and security issues. The access network needs to be designed to prevent man-in-the-middle adversaries from presenting themselves as a LIS to end hosts. When an end host discovers a LIS, it needs to ensure [verify?] (and be able to ensure [verify?]) that the discovered entity is indeed an authorized LIS." Unfortunately, these are other comments are scattered throughout these sections and not collected in one place (anywhere in the document) where they are clearly identified as requirements. Section 6 enumerates the requirements that the design team proposes for the L7 LCP. Unfortunately, several security-relevant observations that appear in sections 4 & 5 do not seem to appear as requirements in this section. The Security Considerations section (7) is very brief and it does not capture many of the security-relevant "requirements" that were discussed in sections 4 & 5. Instead it notes that these are sprinkled throughout the document. I think it would be preferable if this info were collected here, especially because Sections 4 & 5 are not labeled as containing requirements, and Section 6 (which is the requirements list) does not seem to capture these security/privacy issues either. Finally, I note that the few security requirements listed in Section 7 are not quite accurate. For example, the client is required to be able to authenticate an LIS, but the real requirement would seem to be that the client can verify that the authenticated entity is an LIS! --============_-964955696==_ma============ Content-Type: text/html; charset="us-ascii" review of draft-ietf-geopriv-l7-lcp-ps-09.txt
I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Draft-ietf-geopriv-l7-lcp-ps-09.txt is a problem statement and requirements and design decisions document dealing with the layer 7 location configuration protocol (L7 LCP) being developed in the GEOPRIV WG. As stated in the abstract:

   This protocol aims to allow an end host to obtain
   location information, by value or by reference, from a Location
   Information Server (LIS) that is located in the access network.  The
   obtained location information can then be used for a variety of
   different protocols and purposes.
A protocol of this sort engenders significant privacy concerns. I was disappointed that the document does not do a good job of clearly stating these concerns and collecting them in one place, e.g., the Secruity Consideration section or the requirements section.

Section 3 of the document describes four types of network environments:
1.       DLS/cable nets and WiMax-like fixed access
2.    Airport, City, Campus Wireless Networks (e.g., 802.11/a/b/g and Wimax)
3.        3G
4.    Enterprise
At the top level, this seems to be an odd taxonomy, e.g., how are 802.11 nets (2) different from enterprise nets (4) in general?  One has to read the detailed examples that follow to try to learn why these are meaningfully different environments re the L7 LCP. It doesn't help that the examples provided do not correspond directly to the four environments named above! This section could be improved in this regard.

Sections 4 & 5 document some of the issues that the L7 LCP design team has explored. There are some security-relevant observations in these sections, e.g.,  "The LIS discovery procedure raises deployment and security issues.  The access network needs to be designed to prevent man-in-the-middle adversaries from presenting themselves as a LIS to end hosts.  When an end host discovers a LIS, it needs to ensure [verify?] (and be able to ensure [verify?]) that the discovered entity is indeed an authorized LIS." Unfortunately, these are other comments are scattered throughout these sections and not collected in one place (anywhere in the document) where they are clearly identified as requirements.

Section 6 enumerates the requirements that the design team proposes for the L7 LCP. Unfortunately, several security-relevant observations that appear in sections 4 & 5 do not seem to appear as requirements in this section.

The Security Considerations section (7) is very brief and it does not capture many of the security-relevant "requirements" that were discussed in sections 4 & 5. Instead it notes that these are sprinkled throughout the document. I think it would be preferable if this info were collected here, especially because Sections 4 & 5 are not labeled as containing requirements, and Section 6 (which is the requirements list) does not seem to capture these security/privacy issues either. Finally, I note that the few security requirements listed in Section 7 are not quite accurate. For example, the client is required to be able to authenticate an LIS, but the real requirement would seem to be that the client can verify that the authenticated entity is an LIS!
--============_-964955696==_ma============-- From scott@hyperthought.com Mon Jul 13 05:41:37 2009 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 E415128C300 for ; Mon, 13 Jul 2009 05:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 SQsV3U8YirQj for ; Mon, 13 Jul 2009 05:41:37 -0700 (PDT) Received: from smtp182.dfw.emailsrvr.com (smtp182.dfw.emailsrvr.com [67.192.241.182]) by core3.amsl.com (Postfix) with ESMTP id 3FBFA28C112 for ; Mon, 13 Jul 2009 05:41:37 -0700 (PDT) Received: from relay8.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay8.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 5ED9C3FFF6; Mon, 13 Jul 2009 08:42:07 -0400 (EDT) Received: by relay8.relay.dfw.mlsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id F0D893FFEF; Mon, 13 Jul 2009 08:42:05 -0400 (EDT) Message-ID: <4A5B2B97.9000206@hyperthought.com> Date: Mon, 13 Jul 2009 05:41:59 -0700 From: "Scott G. Kelly" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: secdir@ietf.org, iesg@ietf.org, cfilsfil@cisco.com, pmohapat@cisco.com, cpignata@cisco.com, softwire-chairs@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-ietf-softwire-lb-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: Mon, 13 Jul 2009 12:41:38 -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 extends the ways in which flows are identified by routers along the packet's path (other than the ingress/egress routers) by adding a new encapsulation Subsequent Address Family Identifier (SAFI) into the softwire binding. I have little experience with routing and softwires, so take this review accordingly. The draft is very brief and assumes that the reader is very familiar with softwires, routing, etc. It appears that it is simply extending RFC5512, and that it adds no new security considerations. The current security considerations sections is one sentence: "There are no additional security risks introduced by this design." I think this is correct. If I were writing this, I might point back at RFC 5512 here, or perhaps even cut/paste the brief security considerations from that document into this one, just to be informative. --Scott From cpignata@cisco.com Mon Jul 13 06:55:32 2009 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 3179E28C264; Mon, 13 Jul 2009 06:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, 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 4E-CYTxvHqSr; Mon, 13 Jul 2009 06:55:31 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 1C9BE28C326; Mon, 13 Jul 2009 06:55:31 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6DDu013002617; Mon, 13 Jul 2009 09:56:00 -0400 (EDT) Received: from [64.102.157.186] (dhcp-64-102-157-186.cisco.com [64.102.157.186]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6DDtxfE009108; Mon, 13 Jul 2009 09:55:59 -0400 (EDT) Message-ID: <4A5B3CEF.8040102@cisco.com> Date: Mon, 13 Jul 2009 09:55:59 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: "Scott G. Kelly" References: <4A5B2B97.9000206@hyperthought.com> In-Reply-To: <4A5B2B97.9000206@hyperthought.com> X-Enigmail-Version: 0.95.7 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pmohapat@cisco.com, softwire-chairs@tools.ietf.org, iesg@ietf.org, cfilsfil@cisco.com, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-softwire-lb-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: Mon, 13 Jul 2009 13:55:32 -0000 Hello Scott, Thank you for your review. To your point in: > I think this is correct. If I were writing this, I might point back at > RFC 5512 here, or perhaps even cut/paste the brief security Ack -- we agree; we'd rather add a pointer and not copy/paste, and we have the following change (in the document's working copy queued up for the next revision) that addresses your comment: 4. Security Considerations + This document defines a new sub-TLV for the BGP Tunnel Encapsulation + Attribute. Security considerations for the BGP Encapsulation SAFI + and the BGP Tunnel Encapsulation Attribute are covered in [RFC5512]. There are no additional security risks introduced by this design. Thanks, -- Carlos. On 7/13/2009 8:41 AM, Scott G. Kelly wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > This document extends the ways in which flows are identified by routers > along the packet's path (other than the ingress/egress routers) by > adding a new encapsulation Subsequent Address Family Identifier (SAFI) > into the softwire binding. > > I have little experience with routing and softwires, so take this review > accordingly. > > The draft is very brief and assumes that the reader is very familiar > with softwires, routing, etc. It appears that it is simply extending > RFC5512, and that it adds no new security considerations. > > The current security considerations sections is one sentence: > > "There are no additional security risks introduced by this design." > > I think this is correct. If I were writing this, I might point back at > RFC 5512 here, or perhaps even cut/paste the brief security > considerations from that document into this one, just to be informative. > > --Scott > > From catherine.meadows@nrl.navy.mil Tue Jul 14 06:56:38 2009 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 1449E3A67A4; Tue, 14 Jul 2009 06:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 mNl192ps9L3R; Tue, 14 Jul 2009 06:56:37 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id 045013A6B94; Tue, 14 Jul 2009 06:56:36 -0700 (PDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.6/8.13.6) with ESMTP id n6EDu7BU013530; Tue, 14 Jul 2009 09:56:07 -0400 (EDT) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.6/8.13.6) with SMTP id n6EDu1HI025284; Tue, 14 Jul 2009 09:56:05 -0400 (EDT) Received: from gilgamesh.fw5540.net ([10.0.3.67]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009071409560326065 ; Tue, 14 Jul 2009 09:56:03 -0400 Message-Id: <73F6E47F-B165-4018-A822-F49908F8A8DD@nrl.navy.mil> From: Catherine Meadows To: secdir@ietf.org, iesg@ietf.org, Scott Hollenbeck Content-Type: multipart/alternative; boundary=Apple-Mail-5-837106205 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 14 Jul 2009 09:56:02 -0400 X-Mailer: Apple Mail (2.935.3) Subject: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-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, 14 Jul 2009 13:56:38 -0000 --Apple-Mail-5-837106205 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Note: I recently submitted a review of draft-hollenbeck- rfc4933bis-02. That was a mistake on my part; that was not the document I was supposed to review. Sandy Murphy is down for reviewing that one. I am supposed to review this one. This document is the update of the based specification of EPP, and so is related to rfc4933bis-02. I've also had some discussion with Sandy about the issue she raised with respect to draft-hollenbeck-rfc4933bis-02. That is actually what I first thought it was: EPP only does a weak form of authentication. So it depends on strong authentication done at the transport level or application level. However there is nothing in the document that I can see that says that the EPP ID must match the transport ID. Thus, if it is relying on the authentication being done at the transport level, there appears to be nothing to prevent the transport level channel being replaced by another one at some point. I am not enough of an expert on EPP to make a definite recommendation as to how or whether this needs to be addressed, but I feel that this is something that needs to be brought to the attention of the IESG and discussed in the next telechat. If the issue does need to be addressed, rfc4930bis is the place where it should be handled. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail-5-837106205 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.

Note:  I recently submitted = a review of draft-hollenbeck-rfc4933bis-02.  That was a = mistake on my part; that was not the document I was supposed to = review.
Sandy Murphy is down for reviewing that one.  I = am supposed to review this one.  This document is the update of the = based specification of  EPP, and so is related = to rfc4933bis-02.

I've also had some = discussion with Sandy about the issue she raised with respect = to draft-hollenbeck-rfc4933bis-02.  That is actually what I = first thought it was:  EPP only does a weak form of = authentication.
So it depends on strong authentication done at = the transport level or application = level.  However there is nothing in the=  document that I can = see
that says that the EPP ID must=  match the transport ID.  Thus, if it = is relying on the
authentication being done at the transport = level, there appears to be nothing to prevent the transport level = channel being replaced by another one at some point.  I am not = enough of an expert on EPP
to make a definite recommendation = as to how or whether this needs to be addressed, but I feel that this is = something that needs to be brought to the attention of the IESG and = discussed in the next telechat.   If the
issue does need = to be addressed, rfc4930bis is the place where it should be = handled. 

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

= --Apple-Mail-5-837106205-- From shollenbeck@verisign.com Tue Jul 14 09:22:25 2009 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 B77D63A6E44; Tue, 14 Jul 2009 09:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 ydm6g25IcSFr; Tue, 14 Jul 2009 09:22:24 -0700 (PDT) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id 8FFD23A68EC; Tue, 14 Jul 2009 09:22:24 -0700 (PDT) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n6EEMHVj006324; Tue, 14 Jul 2009 10:22:17 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 15:34:28 +0100 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_01CA0490.3183C49A" Date: Tue, 14 Jul 2009 10:34:28 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0702B8DD4F@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <73F6E47F-B165-4018-A822-F49908F8A8DD@nrl.navy.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secdir review of draft-hollenbeck-rfc4930bis-02 Thread-Index: AcoEivxuuqfvDOJxTFq72OhjLV1NNAABQylg References: <73F6E47F-B165-4018-A822-F49908F8A8DD@nrl.navy.mil> From: "Hollenbeck, Scott" To: "Catherine Meadows" , , X-OriginalArrivalTime: 14 Jul 2009 14:34:28.0935 (UTC) FILETIME=[31B6DD70:01CA0490] Cc: "Hollenbeck, Scott" Subject: Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-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, 14 Jul 2009 16:22:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0490.3183C49A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ________________________________ From: Catherine Meadows [mailto:catherine.meadows@nrl.navy.mil]=20 Sent: Tuesday, July 14, 2009 9:56 AM To: secdir@ietf.org; iesg@ietf.org; Hollenbeck, Scott Cc: Catherine Meadows Subject: Secdir review of draft-hollenbeck-rfc4930bis-02 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 Note: I recently submitted a review of draft-hollenbeck-rfc4933bis-02. That was a mistake on my part; that was not the document I was supposed to review. Sandy Murphy is down for reviewing that one. I am supposed to review this one. This document is the update of the based specification of EPP, and so is related to rfc4933bis-02. I've also had some discussion with Sandy about the issue she raised with respect to draft-hollenbeck-rfc4933bis-02. That is actually what I first thought it was: EPP only does a weak form of authentication. So it depends on strong authentication done at the transport level or application level. However there is nothing in the document that I can see that says that the EPP ID must match the transport ID. Thus, if it is relying on the authentication being done at the transport level, there appears to be nothing to prevent the transport level channel being replaced by another one at some point. I am not enough of an expert on EPP to make a definite recommendation as to how or whether this needs to be addressed, but I feel that this is something that needs to be brought to the attention of the IESG and discussed in the next telechat. If the issue does need to be addressed, rfc4930bis is the place where it should be handled.=20 =20 =20 Please help me understand what you mean by "EPP ID" and "transport ID". =20 -Scott- ------_=_NextPart_001_01CA0490.3183C49A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
From: Catherine Meadows=20 [mailto:catherine.meadows@nrl.navy.mil]
Sent: Tuesday, July = 14, 2009=20 9:56 AM
To: secdir@ietf.org; iesg@ietf.org; Hollenbeck,=20 Scott
Cc: Catherine Meadows
Subject: Secdir review = of=20 draft-hollenbeck-rfc4930bis-02

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. These=20 comments were written primarily for the benefit of the security area=20 directors.  Document editors and WG chairs should treat these = comments=20 just like any other last call comments.

Note:  I recently submitted a review=20 of draft-hollenbeck-rfc4933bis-02.  That was a mistake on my = part;=20 that was not the document I was supposed to review.
Sandy Murphy is down for reviewing that one.  I am supposed = to=20 review this one.  This document is the update of the based = specification=20 of  EPP, and so is related to rfc4933bis-02.

I've also had some discussion with Sandy about the issue she = raised with=20 respect to draft-hollenbeck-rfc4933bis-02.  That is actually = what I=20 first thought it was:  EPP only does a weak form of = authentication.
So it depends on strong authentication done at the transport = level or=20 application=20 = level.  However there is nothing in th= e document that=20 I can see
=
that says that the EPP ID must ma= tch the transport ID.  Thus, if=20 it is relying on the
authentication being done at the transport level, there appears = to be=20 nothing to prevent the transport level channel being replaced by = another one=20 at some point.  I am not enough of an expert on EPP
to make a definite recommendation as to how or whether this needs = to be=20 addressed, but I feel that this is something that needs to be brought = to the=20 attention of the IESG and discussed in the next telechat.   If = the
issue does need to be addressed, rfc4930bis is the place = where it=20 should be handled. 
 
 
Please=20 help me understand what you mean by "EPP ID" and "transport=20 ID".
 
-Scott-
------_=_NextPart_001_01CA0490.3183C49A-- From catherine.meadows@nrl.navy.mil Tue Jul 14 14:13:01 2009 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 BF4D13A677E; Tue, 14 Jul 2009 14:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 Bb+ph6EynyUT; Tue, 14 Jul 2009 14:13:00 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id 3A2043A6B2C; Tue, 14 Jul 2009 14:10:51 -0700 (PDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.6/8.13.6) with ESMTP id n6EL6DHM002668; Tue, 14 Jul 2009 17:06:13 -0400 (EDT) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.6/8.13.6) with SMTP id n6EL6AVt023002; Tue, 14 Jul 2009 17:06:10 -0400 (EDT) Received: from gilgamesh.fw5540.net ([10.0.3.67]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009071417060926918 ; Tue, 14 Jul 2009 17:06:09 -0400 Message-Id: From: Catherine Meadows To: "Hollenbeck, Scott" In-Reply-To: <046F43A8D79C794FA4733814869CDF0702B8DD4F@dul1wnexmb01.vcorp.ad.vrsn.com> Content-Type: multipart/alternative; boundary=Apple-Mail-6-862912848 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 14 Jul 2009 17:06:08 -0400 References: <73F6E47F-B165-4018-A822-F49908F8A8DD@nrl.navy.mil> <046F43A8D79C794FA4733814869CDF0702B8DD4F@dul1wnexmb01.vcorp.ad.vrsn.com> X-Mailer: Apple Mail (2.935.3) Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-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, 14 Jul 2009 21:13:01 -0000 --Apple-Mail-6-862912848 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Scott: By Transport ID, I would assume the identifer(s) associated with the transport level authentication key. For EPP ID I would assume whatever identification is associated with an EPP instance. II wasn't actually present at the discussion on channel binding so can't be more specific than this. If there is anyone in the secdir group listening who has some more information on this I'd appreciate hearing from them. Cathy On Jul 14, 2009, at 10:34 AM, Hollenbeck, Scott wrote: > From: Catherine Meadows [mailto:catherine.meadows@nrl.navy.mil] > Sent: Tuesday, July 14, 2009 9:56 AM > To: secdir@ietf.org; iesg@ietf.org; Hollenbeck, Scott > Cc: Catherine Meadows > Subject: Secdir review of draft-hollenbeck-rfc4930bis-02 > > 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. > > Note: I recently submitted a review of draft-hollenbeck- > rfc4933bis-02. That was a mistake on my part; that was not the > document I was supposed to review. > Sandy Murphy is down for reviewing that one. I am supposed to > review this one. This document is the update of the based > specification of EPP, and so is related to rfc4933bis-02. > > I've also had some discussion with Sandy about the issue she raised > with respect to draft-hollenbeck-rfc4933bis-02. That is actually > what I first thought it was: EPP only does a weak form of > authentication. > So it depends on strong authentication done at the transport level > or application level. However there is nothing in the document that > I can see > that says that the EPP ID must match the transport ID. Thus, if it > is relying on the > authentication being done at the transport level, there appears to > be nothing to prevent the transport level channel being replaced by > another one at some point. I am not enough of an expert on EPP > to make a definite recommendation as to how or whether this needs to > be addressed, but I feel that this is something that needs to be > brought to the attention of the IESG and discussed in the next > telechat. If the > issue does need to be addressed, rfc4930bis is the place where it > should be handled. > > > Please help me understand what you mean by "EPP ID" and "transport > ID". > > -Scott- Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail-6-862912848 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Hi = Scott:

By Transport ID, I would assume the =  identifer(s)  associated with the transport level = authentication key.  
For EPP ID I would assume whatever = identification is associated with an EPP instance.
II wasn't = actually present at the discussion on channel binding so can't be more = specific than this.
If there is anyone in the secdir group = listening who has some more information on this I'd = appreciate
hearing from = them.

Cathy
  
O= n Jul 14, 2009, at 10:34 AM, Hollenbeck, Scott wrote:

=
From: Catherine Meadows [mailto:catherine.meadows@nr= l.navy.mil]
Sent: Tuesday, July 14, 2009 9:56 = AM
To: secdir@ietf.org; = iesg@ietf.org; Hollenbeck, = Scott
Cc: Catherine Meadows
Subject: Secdir review = of draft-hollenbeck-rfc4930bis-02

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.

Note:  I = recently submitted a review of draft-hollenbeck-rfc4933bis-02. =  That was a mistake on my part; that was not the document I was = supposed to review.
Sandy Murphy is down for reviewing that = one.  I am supposed to review this one.  This document is = the update of the based specification of  EPP, and so is related = to rfc4933bis-02.

I've also had some = discussion with Sandy about the issue she raised with respect = to draft-hollenbeck-rfc4933bis-02.  That is actually what I = first thought it was:  EPP only does a weak form of = authentication.
So it depends on strong authentication done = at the transport level or application = level.  However there is nothing in the=  document that I can see
=
that says that the EPP ID must mat= ch the transport ID.  Thus, if it is = relying on the
authentication being done at the transport = level, there appears to be nothing to prevent the transport level = channel being replaced by another one at some point.  I am not = enough of an expert on EPP
to make a definite recommendation = as to how or whether this needs to be addressed, but I feel that this = is something that needs to be brought to the attention of the IESG and = discussed in the next telechat.   If the
issue does = need to be addressed, rfc4930bis is the place where it should be = handled. 
 
 
Please help me understand what you mean by "EPP ID" = and "transport ID".
 
-Scott-

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

= --Apple-Mail-6-862912848-- From shollenbeck@verisign.com Tue Jul 14 17:08:25 2009 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 2BE6B3A6AC2; Tue, 14 Jul 2009 17:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 3yBTz4K40e3b; Tue, 14 Jul 2009 17:08:23 -0700 (PDT) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id B16FE3A6803; Tue, 14 Jul 2009 17:08:23 -0700 (PDT) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n6ENuKg5005796; Tue, 14 Jul 2009 19:56:20 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 20:08:32 -0400 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_01CA04E0.636F613E" Date: Tue, 14 Jul 2009 20:08:32 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07025CD275@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-02 Thread-Index: AcoE2PY4qvMvIm8PTsmXGv86b8EDXgAB205s From: "Hollenbeck, Scott" To: "Sandy Murphy" , , , X-OriginalArrivalTime: 15 Jul 2009 00:08:32.0905 (UTC) FILETIME=[63EB9790:01CA04E0] Subject: Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-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, 15 Jul 2009 00:08:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA04E0.636F613E Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RG9lc24ndCBUTFMgcHJvdmlkZSBwcm90ZWN0aW9ucyBmb3IgdGhpcyBpc3N1ZT8NCg0KLVNjb3R0 LQ0KDQogLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IAlTYW5keSBNdXJwaHkgW21h aWx0bzpzYW5keUB0aXNsYWJzLmNvbV0NClNlbnQ6CVR1ZXNkYXksIEp1bHkgMTQsIDIwMDkgMDc6 MTUgUE0gRWFzdGVybiBTdGFuZGFyZCBUaW1lDQpUbzoJY2F0aGVyaW5lLm1lYWRvd3NAbnJsLm5h dnkubWlsOyBpZXNnQGlldGYub3JnOyBzYW5keUB0aXNsYWJzLmNvbTsgc2VjZGlyQGlldGYub3Jn OyBIb2xsZW5iZWNrLCBTY290dA0KU3ViamVjdDoJUmU6IFtzZWNkaXJdIFNlY2RpciByZXZpZXcg b2YgZHJhZnQtaG9sbGVuYmVjay1yZmM0OTMwYmlzLTAyDQoNCj5BIHNlY3VyZSBhdXRoZW50aWNU aGUgdGllIGlzIHdoYXQgaXMgY2FsbGVkIGNoYW5uZWwgYmluZGluZy4NCg0KT0ssIG9idmlvdXMg YmxpcCBoZXJlLg0KDQpBIHNlY3VyZSBhdXRoZW50aWNhdGVkIHRyYW5zcG9ydCBjb25uZWN0aW9u IGlzIGVzdGFibGlzaGVkIGJldHdlZW4NCjEwLjEuMC4wIHRvIHRoZSBvdGhlciBlbmQgd2hlcmUg dGhlIGxvZ2luIGlzIGJlaW5nIGF0dGVtcHRlZCwgc2F5DQoxMC4yLjAuMC4NCg0KVGhlIHRyb3Vi bGUgaXMgdGhhdCB0aGF0IDEwLjIuMC4wIG1pZ2h0IGJlIGEgbWFuIGluIHRoZSBtaWRkbGUuDQpU aGUgTUlUTSBoYXMgYW5vdGhlciBzZWN1cmUgYXV0aGVudGljYXRlZCB0cmFuc3BvcnQgY29ubmVj dGlvbiB0bw0KQm9iJ3MgaG9zdCwgMTAuMy4wLjAuDQoNCkJvYiBzZW5kcyB0aGUgImxvZ2luIEJv YiBib2JzY2xlYXJ0ZXh0cGFzc3dvcmQiIG92ZXIgaXRzIHNlY3VyZQ0KdHJhbnNwb3J0IGNvbm5l Y3Rpb24sIHdoaWNoIGVuZHMgYXQgdGhlIE1JVE0gYXQgMTAuMi4wLjAuDQoNClRoZSBNSVRNIHJl dHJhbnNtaXRzIHRoZSAibG9naW4gQm9iIGJvYnNjbGVhcnRleHRwYXNzd29yZCIgb3ZlciB0aGUN CnNlY3VyZSB0cmFuc3BvcnQgY29ubmVjdGlvbiB0byAxMC4xLjAuMCwgaW1wZXJzb25hdGluZyBC b2IuDQoNClRoaXMgaXMgcG9zc2libGUgYmVjYXVzZSB0aGVyZSBpcyBubyB0aWUgYmV0d2VlbiB0 aGUgRVBQIElEIG9mICJCb2IiDQphbmQgdGhlIHNlY3VyZSB0cmFuc3BvcnQgaWQgb2YgMTAuMi4w LjAuDQoNClRoZSB0aWUgaXMgd2hhdCBpcyBjYWxsZWQgY2hhbm5lbCBiaW5kaW5nLg0KDQpZb3Ug Y2FuIGxvb2sgYXQgUkZDNTA1NiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBvciBhdCANCmh0dHA6Ly93 d3cuc2F1bmFsYWh0aS5maS9+YXNva2FuL3Jlc2VhcmNoL21pdG0uaHRtbCBmb3IgYW5vdGhlcg0K ZGlzY3Vzc2lvbiB3aXRoIGEgcmF0aGVyIGRldGFpbGVkIGV4YW1wbGUgZm9yIFBFQVAuDQoNCkl0 IG1pZ2h0IGJlIHdvcnRoIHBvaW50aW5nIG91dCB0aGF0IGRyYWZ0LWlldGYtc2FzbC1nczItMTQg dGFsa3MNCmFib3V0IFVzaW5nIEdTUy1BUEkgTWVjaGFuaXNtcyBpbiBTQVNMLCBhbmQgc3VwcG9y dHMgY2hhbm5lbCBiaW5kaW5nLg0KDQotLVNhbmR5DQo= ------_=_NextPart_001_01CA04E0.636F613E Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTQuMTIiPg0KPFRJVExFPlJFOiBSZTogW3Nl Y2Rpcl0gU2VjZGlyIHJldmlldyBvZiBkcmFmdC1ob2xsZW5iZWNrLXJmYzQ5MzBiaXMtMDI8L1RJ VExFPg0KPC9IRUFEPg0KPEJPRFk+DQo8IS0tIENvbnZlcnRlZCBmcm9tIHRleHQvcGxhaW4gZm9y bWF0IC0tPg0KDQo8UD48Rk9OVCBTSVpFPTI+RG9lc24ndCBUTFMgcHJvdmlkZSBwcm90ZWN0aW9u cyBmb3IgdGhpcyBpc3N1ZT88QlI+DQo8QlI+DQotU2NvdHQtPEJSPg0KPEJSPg0KJm5ic3A7LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+DQpGcm9tOiAmbmJzcDsgU2FuZHkgTXVycGh5IFs8 QSBIUkVGPSJtYWlsdG86c2FuZHlAdGlzbGFicy5jb20iPm1haWx0bzpzYW5keUB0aXNsYWJzLmNv bTwvQT5dPEJSPg0KU2VudDombmJzcDsmbmJzcDsgVHVlc2RheSwgSnVseSAxNCwgMjAwOSAwNzox NSBQTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWU8QlI+DQpUbzombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgY2F0aGVyaW5lLm1lYWRvd3NAbnJsLm5hdnkubWlsOyBpZXNnQGlldGYub3JnOyBzYW5keUB0 aXNsYWJzLmNvbTsgc2VjZGlyQGlldGYub3JnOyBIb2xsZW5iZWNrLCBTY290dDxCUj4NClN1Ympl Y3Q6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlOiBbc2VjZGly XSBTZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWhvbGxlbmJlY2stcmZjNDkzMGJpcy0wMjxCUj4NCjxC Uj4NCiZndDtBIHNlY3VyZSBhdXRoZW50aWNUaGUgdGllIGlzIHdoYXQgaXMgY2FsbGVkIGNoYW5u ZWwgYmluZGluZy48QlI+DQo8QlI+DQpPSywgb2J2aW91cyBibGlwIGhlcmUuPEJSPg0KPEJSPg0K QSBzZWN1cmUgYXV0aGVudGljYXRlZCB0cmFuc3BvcnQgY29ubmVjdGlvbiBpcyBlc3RhYmxpc2hl ZCBiZXR3ZWVuPEJSPg0KMTAuMS4wLjAgdG8gdGhlIG90aGVyIGVuZCB3aGVyZSB0aGUgbG9naW4g aXMgYmVpbmcgYXR0ZW1wdGVkLCBzYXk8QlI+DQoxMC4yLjAuMC48QlI+DQo8QlI+DQpUaGUgdHJv dWJsZSBpcyB0aGF0IHRoYXQgMTAuMi4wLjAgbWlnaHQgYmUgYSBtYW4gaW4gdGhlIG1pZGRsZS48 QlI+DQpUaGUgTUlUTSBoYXMgYW5vdGhlciBzZWN1cmUgYXV0aGVudGljYXRlZCB0cmFuc3BvcnQg Y29ubmVjdGlvbiB0bzxCUj4NCkJvYidzIGhvc3QsIDEwLjMuMC4wLjxCUj4NCjxCUj4NCkJvYiBz ZW5kcyB0aGUgJnF1b3Q7bG9naW4gQm9iIGJvYnNjbGVhcnRleHRwYXNzd29yZCZxdW90OyBvdmVy IGl0cyBzZWN1cmU8QlI+DQp0cmFuc3BvcnQgY29ubmVjdGlvbiwgd2hpY2ggZW5kcyBhdCB0aGUg TUlUTSBhdCAxMC4yLjAuMC48QlI+DQo8QlI+DQpUaGUgTUlUTSByZXRyYW5zbWl0cyB0aGUgJnF1 b3Q7bG9naW4gQm9iIGJvYnNjbGVhcnRleHRwYXNzd29yZCZxdW90OyBvdmVyIHRoZTxCUj4NCnNl Y3VyZSB0cmFuc3BvcnQgY29ubmVjdGlvbiB0byAxMC4xLjAuMCwgaW1wZXJzb25hdGluZyBCb2Iu PEJSPg0KPEJSPg0KVGhpcyBpcyBwb3NzaWJsZSBiZWNhdXNlIHRoZXJlIGlzIG5vIHRpZSBiZXR3 ZWVuIHRoZSBFUFAgSUQgb2YgJnF1b3Q7Qm9iJnF1b3Q7PEJSPg0KYW5kIHRoZSBzZWN1cmUgdHJh bnNwb3J0IGlkIG9mIDEwLjIuMC4wLjxCUj4NCjxCUj4NClRoZSB0aWUgaXMgd2hhdCBpcyBjYWxs ZWQgY2hhbm5lbCBiaW5kaW5nLjxCUj4NCjxCUj4NCllvdSBjYW4gbG9vayBhdCBSRkM1MDU2IGZv ciBtb3JlIGluZm9ybWF0aW9uIG9yIGF0PEJSPg0KPEEgSFJFRj0iaHR0cDovL3d3dy5zYXVuYWxh aHRpLmZpL35hc29rYW4vcmVzZWFyY2gvbWl0bS5odG1sIj5odHRwOi8vd3d3LnNhdW5hbGFodGku ZmkvfmFzb2thbi9yZXNlYXJjaC9taXRtLmh0bWw8L0E+IGZvciBhbm90aGVyPEJSPg0KZGlzY3Vz c2lvbiB3aXRoIGEgcmF0aGVyIGRldGFpbGVkIGV4YW1wbGUgZm9yIFBFQVAuPEJSPg0KPEJSPg0K SXQgbWlnaHQgYmUgd29ydGggcG9pbnRpbmcgb3V0IHRoYXQgZHJhZnQtaWV0Zi1zYXNsLWdzMi0x NCB0YWxrczxCUj4NCmFib3V0IFVzaW5nIEdTUy1BUEkgTWVjaGFuaXNtcyBpbiBTQVNMLCBhbmQg c3VwcG9ydHMgY2hhbm5lbCBiaW5kaW5nLjxCUj4NCjxCUj4NCi0tU2FuZHk8QlI+DQo8L0ZPTlQ+ DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4= ------_=_NextPart_001_01CA04E0.636F613E-- From Sandra.Murphy@cobham.com Wed Jul 15 08:13:28 2009 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 173A23A6EA3; Wed, 15 Jul 2009 08:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 AxsUqiBfh6ab; Wed, 15 Jul 2009 08:13:26 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id B82423A6C86; Wed, 15 Jul 2009 08:13:26 -0700 (PDT) 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 n6FFDUQZ022408; Wed, 15 Jul 2009 10:13:30 -0500 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 n6FFDUO0002712; Wed, 15 Jul 2009 10:13:30 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.126]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 11:13:29 -0400 Date: Wed, 15 Jul 2009 11:13:29 -0400 (Eastern Daylight Time) From: Sandra Murphy To: "Hollenbeck, Scott" In-Reply-To: <046F43A8D79C794FA4733814869CDF07025CD275@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: References: <046F43A8D79C794FA4733814869CDF07025CD275@dul1wnexmb01.vcorp.ad.vrsn.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 15 Jul 2009 15:13:29.0749 (UTC) FILETIME=[CF5C7C50:01CA055E] Cc: secdir@ietf.org, iesg@ietf.org Subject: Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-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, 15 Jul 2009 15:13:28 -0000 (I sent multiple secdir related messages yesterday that were mangled or failed to deliver to the secdir and iesg lists. You could see an example in Scott's reply to one of the mangled messages. Here is the unmangled message, to keep us all in sync. My apologies to the recipients who are seeing this again.) >By Transport ID, I would assume the identifer(s) associated with the >transport level authentication key. >For EPP ID I would assume whatever identification is associated with >an EPP instance. In EPP, you do a simple login with user name and password: login Bob bobscleartextpassword The other end checks the password and says "Great to see you, Bob!" Underneath you have a stronger authentication system running. This is based on some transport id, like the ip addr/protocol/port or whatever id the secure transport uses. Lets say the transport id is ip addr, say 10.1.0.0 at the end doing the login authentication. A secure authenticated transport connection is established between 10.1.0.0 to the other end where the login is being attempted, say 10.2.0.0. The trouble is that that 10.2.0.0 might be a man in the middle. The MITM has another secure authenticated transport connection to Bob's host, 10.3.0.0. Bob sends the "login Bob bobscleartextpassword" over its secure transport connection, which ends at the MITM at 10.2.0.0. The MITM retransmits the "login Bob bobscleartextpassword" over the secure transport connection to 10.1.0.0, impersonating Bob. This is possible because there is no tie between the EPP ID of "Bob" and the secure transport id of 10.2.0.0. The tie is what is called channel binding. You can look at RFC5056 for more information or at http://www.saunalahti.fi/~asokan/research/mitm.html for another discussion with a rather detailed example for PEAP. It might be worth pointing out that draft-ietf-sasl-gs2-14 talks about Using GSS-API Mechanisms in SASL, and supports channel binding. --Sandy From Sandra.Murphy@cobham.com Wed Jul 15 08:26:19 2009 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 AD30628C116; Wed, 15 Jul 2009 08:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.073, 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 W3u6s4Q2n2XO; Wed, 15 Jul 2009 08:26:17 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id F390E3A6B9F; Wed, 15 Jul 2009 08:26:16 -0700 (PDT) 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 n6FFPv8T022694; Wed, 15 Jul 2009 10:25:57 -0500 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 n6FFPvJw003541; Wed, 15 Jul 2009 10:25:57 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.126]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 11:25:57 -0400 Date: Wed, 15 Jul 2009 11:25:56 -0400 (Eastern Daylight Time) From: Sandra Murphy To: "Hollenbeck, Scott" In-Reply-To: Message-ID: References: <046F43A8D79C794FA4733814869CDF07025CD275@dul1wnexmb01.vcorp.ad.vrsn.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 15 Jul 2009 15:25:57.0062 (UTC) FILETIME=[8CCB6660:01CA0560] Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-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, 15 Jul 2009 15:26:19 -0000 And now, to correct what I said below. The intent was to convey the difficulty of MITM when you don't bind the ID the application is using to the secure transport. As 5056 says: There may well be an MITM, particularly if either the lower network layer provides no authentication or there is no strong connection between the authentication or principals used at the application and those used at the lower network layer. But my example leaves the impression that the binding is to the identity exchanged in the sasl exchange. It isn't. It would be to the ID EPP uses to identify the other end of the EPP connection. Someone who knows this subject better than I would probably be of more use explaining things here. --Sandy On Wed, 15 Jul 2009, Sandra Murphy wrote: > (I sent multiple secdir related messages yesterday that were mangled or > failed to deliver to the secdir and iesg lists. You could see an example in > Scott's reply to one of the mangled messages. Here is the unmangled message, > to keep us all in sync. My apologies to the recipients who are seeing this > again.) > > > >> By Transport ID, I would assume the identifer(s) associated with the >> transport level authentication key. >> For EPP ID I would assume whatever identification is associated with >> an EPP instance. > > In EPP, you do a simple login with user name and password: > login Bob bobscleartextpassword > > The other end checks the password and says "Great to see you, Bob!" > > Underneath you have a stronger authentication system running. > This is based on some transport id, like the ip addr/protocol/port > or whatever id the secure transport uses. Lets say the transport > id is ip addr, say 10.1.0.0 at the end doing the login authentication. > > > A secure authenticated transport connection is established between > 10.1.0.0 to the other end where the login is being attempted, say > 10.2.0.0. > > The trouble is that that 10.2.0.0 might be a man in the middle. > The MITM has another secure authenticated transport connection to > Bob's host, 10.3.0.0. > > Bob sends the "login Bob bobscleartextpassword" over its secure > transport connection, which ends at the MITM at 10.2.0.0. > > The MITM retransmits the "login Bob bobscleartextpassword" over the > secure transport connection to 10.1.0.0, impersonating Bob. > > This is possible because there is no tie between the EPP ID of "Bob" > and the secure transport id of 10.2.0.0. > > The tie is what is called channel binding. > > You can look at RFC5056 for more information or at > http://www.saunalahti.fi/~asokan/research/mitm.html for another > discussion with a rather detailed example for PEAP. > > It might be worth pointing out that draft-ietf-sasl-gs2-14 talks > about Using GSS-API Mechanisms in SASL, and supports channel binding. > > --Sandy > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From Sandra.Murphy@cobham.com Wed Jul 15 08:39:49 2009 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 310B23A6AB0; Wed, 15 Jul 2009 08:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 1rpjch2JDARw; Wed, 15 Jul 2009 08:39:48 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 4448C28C0FA; Wed, 15 Jul 2009 08:38:55 -0700 (PDT) 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 n6FFbSfp022936; Wed, 15 Jul 2009 10:37:28 -0500 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 n6FFbSNi004327; Wed, 15 Jul 2009 10:37:28 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.126]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 11:37:28 -0400 Date: Wed, 15 Jul 2009 11:37:27 -0400 (Eastern Daylight Time) From: Sandra Murphy To: "Hollenbeck, Scott" In-Reply-To: <046F43A8D79C794FA4733814869CDF07025CD275@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: References: <046F43A8D79C794FA4733814869CDF07025CD275@dul1wnexmb01.vcorp.ad.vrsn.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 15 Jul 2009 15:37:28.0280 (UTC) FILETIME=[28CAE580:01CA0562] Cc: secdir@ietf.org, iesg@ietf.org Subject: Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-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, 15 Jul 2009 15:39:49 -0000 On Tue, 14 Jul 2009, Hollenbeck, Scott wrote: > Doesn't TLS provide protections for this issue? > > -Scott- (a) rfc4930 does not mandate use of TLS as a tranport connection, by design (so I don't know why you mention it): EPP is intended for use in diverse operating environments where transport and security requirements vary greatly. It is unlikely that a single transport or security specification will meet the needs of all anticipated operators, so EPP was designed for use in a layered protocol environment. Bindings to specific transport and security protocols are outside the scope of this specification. (b) There are defined channel bindings for TLS. See the recently published draft-altman-tls-channel-bindings-05.txt. This isn't a free ride, however -- note the places where that draft mentions the need to modify firmware or software: Therefore 'tls-unique' is generally better than 'tls-server-end- point'. However, 'tls-server-end-point' may be used with existing TLS server-side proxies ("concentrators") without modification to the proxies, whereas 'tls-unique' may require firmware or software updates to server-side proxies. Therefore there may be cases where 'tls-server-end-point' may interoperate but where 'tls-unique' may not. --Sandy From alexey.melnikov@isode.com Wed Jul 15 08:57:59 2009 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 5AF443A69B3; Wed, 15 Jul 2009 08:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 bisrEAVE5gCQ; Wed, 15 Jul 2009 08:57:58 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 61D6C3A6947; Wed, 15 Jul 2009 08:57:58 -0700 (PDT) Received: from [172.16.2.160] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 15 Jul 2009 16:47:03 +0100 Message-ID: <4A5DF9CA.9060304@isode.com> Date: Wed, 15 Jul 2009 16:46:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Sandra Murphy References: <046F43A8D79C794FA4733814869CDF07025CD275@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Hollenbeck, Scott" , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-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, 15 Jul 2009 15:57:59 -0000 Sandra Murphy wrote: > On Tue, 14 Jul 2009, Hollenbeck, Scott wrote: > >> Doesn't TLS provide protections for this issue? >> >> -Scott- > > (a) rfc4930 does not mandate use of TLS as a tranport connection, by > design (so I don't know why you mention it): rfc4934 (binding to TLS over TCP) mandates use of TLS. > EPP is intended for use in diverse operating environments where > transport and security requirements vary greatly. It is unlikely > that a single transport or security specification will meet the needs > of all anticipated operators, so EPP was designed for use in a > layered protocol environment. Bindings to specific transport and > security protocols are outside the scope of this specification. From Sandra.Murphy@cobham.com Wed Jul 15 09:00:04 2009 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 5CCA13A6D56; Wed, 15 Jul 2009 09:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 prcweMdde4BR; Wed, 15 Jul 2009 09:00:02 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 868363A6947; Wed, 15 Jul 2009 09:00:02 -0700 (PDT) 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 n6FEplsr021966; Wed, 15 Jul 2009 09:51:47 -0500 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 n6FEpkBf001458; Wed, 15 Jul 2009 09:51:47 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.126]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 10:51:46 -0400 Date: Wed, 15 Jul 2009 10:51:46 -0400 (Eastern Daylight Time) From: Sandra Murphy To: "Hollenbeck, Scott" In-Reply-To: <046F43A8D79C794FA4733814869CDF0702B8DA2E@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: References: <897517DC-2F59-440A-BD63-BD71E1AF4421@nrl.navy.mil> <046F43A8D79C794FA4733814869CDF0702B8DA2E@dul1wnexmb01.vcorp.ad.vrsn.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 15 Jul 2009 14:51:46.0655 (UTC) FILETIME=[C6A81EF0:01CA055B] Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] review of draft-hollenbeck-rfc4933bis-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, 15 Jul 2009 16:00:04 -0000 (Note to all. I sent multiple secdir related messages yesterday afternoon, and they all were mangled or ultimately not delivered. So this is a repeat that some og the recipients may already have seen. Apologies for the technology failure.) On Tue, 7 Jul 2009, Scott Hollenbeck said: >There was no follow-up, so I remain a little unsure of how to address >the comment. Similarly, I need a clarification to know if the text >change suggested below is best made in 4933bis. Yes, I am guilty of not following up. I was unsure of my understanding of channel binding issues, none of the other reviewers of the rfc493* suite made any notice of the issue, and, as you note here, the issue is really in the base spec, not 4933. I just had no idea what the right process would be, if any. Subsequent discussion and review of material make me more confident that there is, indeed, a channel binding issue here. The question is what to do about it. This is an established protocol. Would a security considerations section in 4930bis that pointed out that there's a MITM attack possible here, because of the lack of channel binding, be sufficient? Or would pointing to the sasl-gs2 work as a protection be mentioned? suggested? mandated? I sure would love to see AD or subject matter experts weigh in here on the technical and process aspects of this. --Sandy From shollenbeck@verisign.com Wed Jul 15 10:28:25 2009 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 18C823A6BF8; Wed, 15 Jul 2009 10:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFs0EhKRXGnL; Wed, 15 Jul 2009 10:28:24 -0700 (PDT) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id CDA073A6F42; Wed, 15 Jul 2009 10:28:23 -0700 (PDT) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n6FG3XK6023851; Wed, 15 Jul 2009 12:03:33 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 12:15:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Jul 2009 12:15:46 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0702B8DE40@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <4A5DF9CA.9060304@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-02 Thread-Index: AcoFY4LaqxB88+azRwS+MCNSUKZwRAAA2NJQ References: <046F43A8D79C794FA4733814869CDF07025CD275@dul1wnexmb01.vcorp.ad.vrsn.com> <4A5DF9CA.9060304@isode.com> From: "Hollenbeck, Scott" To: "Alexey Melnikov" , "Sandra Murphy" X-OriginalArrivalTime: 15 Jul 2009 16:15:47.0269 (UTC) FILETIME=[8318C750:01CA0567] Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-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, 15 Jul 2009 17:28:25 -0000 > -----Original Message----- > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 > Sent: Wednesday, July 15, 2009 11:46 AM > To: Sandra Murphy > Cc: Hollenbeck, Scott; secdir@ietf.org;=20 > catherine.meadows@nrl.navy.mil; iesg@ietf.org; Sandy Murphy > Subject: Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-02 >=20 > Sandra Murphy wrote: >=20 > > On Tue, 14 Jul 2009, Hollenbeck, Scott wrote: > > > >> Doesn't TLS provide protections for this issue? > >> > >> -Scott- > > > > (a) rfc4930 does not mandate use of TLS as a tranport=20 > connection, by=20 > > design (so I don't know why you mention it): >=20 > rfc4934 (binding to TLS over TCP) mandates use of TLS. >=20 > > EPP is intended for use in diverse operating environments where > > transport and security requirements vary greatly. It is unlikely > > that a single transport or security specification will=20 > meet the needs > > of all anticipated operators, so EPP was designed for use in a > > layered protocol environment. Bindings to specific transport and > > security protocols are outside the scope of this specification. As Alexey noted, I mentioned it because there's an EPP specification for transport over TLS. 4934bis is part of the document set that's being reviewed for progression to Standard status. That's why I'm having some trouble understanding if/how I should address the channel binding risk comments in 4930bis or one of the other documents. -Scott- From william.polk@nist.gov Wed Jul 15 11:36:14 2009 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 18CF53A6C0C; Wed, 15 Jul 2009 11:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.055 X-Spam-Level: X-Spam-Status: No, score=-6.055 tagged_above=-999 required=5 tests=[AWL=0.543, 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 0jZJ-dP2KUbH; Wed, 15 Jul 2009 11:36:09 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id EACD23A6AA4; Wed, 15 Jul 2009 11:36:07 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n6FHx7LA001209; Wed, 15 Jul 2009 13:59:07 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Wed, 15 Jul 2009 13:59:07 -0400 From: "Polk, William T." To: Sandra Murphy , "Hollenbeck, Scott" Date: Wed, 15 Jul 2009 13:59:05 -0400 Thread-Topic: [secdir] review of draft-hollenbeck-rfc4933bis-02 Thread-Index: AcoFZXnEUGL5r6YURci2FQADJAXtMgAEHd0k Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6839129119DCwilliampolknistgov_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov X-Mailman-Approved-At: Wed, 15 Jul 2009 11:38:26 -0700 Cc: "iesg@ietf.org" , Nicolas Williams , "secdir@ietf.org" Subject: Re: [secdir] review of draft-hollenbeck-rfc4933bis-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, 15 Jul 2009 18:36:14 -0000 --_000_C6839129119DCwilliampolknistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm a little late to the party, but I have been quietly mulling over this p= roblem as well. Now that Sandy has explicitly asked for an AD to step in, = I figured I should participate more actively. I have also added Nico Willi= ams to the CC list (my apologies, Nico) since channel bindings is really hi= s area of expertise. I think there is a real need for channel bindings with some applications of= EPP, but may not always be strictly necessary in other cases. For example= , the e-Automation project for the administration of DNS root zone uses EPP= but if I recall correctly most of the objects that are transferred are dig= itally signed objects. In this case, channel bindings are perhaps less imp= ortant since we aren't relying solely on the EPP authentication mechanism. = So, in my opinion we should encourage their use but should not require cha= nnel bindings. However, if the application is relying on EPP in combination with transport= for security, channel bindings would provide significantly enhanced securi= ty. That says channel bindings deserves to be mentioned and a little guida= nce on (1) implementing channel bindings and (2) determining when channel b= indings is required. That begs a new question of course - where does this = information go? I am starting to believe that the security considerations section of 4930bi= s should note that enhanced security SHOULD be achieved through channel bin= dings unless the application involves digitally signed objects, and that th= e TLS usage section of 4934bis (section 9) should include a pointer to tech= niques for implementing channel bindings with TLS. I am still mulling this= over, and will probably not enter any discuss until tomorrow, but this see= ms the best approach. (Hopefully Nico will weigh in before then and keep m= e straight on this one...) Tim Polk On 7/15/09 10:51 AM, "Sandra Murphy" wrote: (Note to all. I sent multiple secdir related messages yesterday afternoon, and they all were mangled or ultimately not delivered. So this is a repeat that some og the recipients may already have seen. Apologies for the technology failure.) On Tue, 7 Jul 2009, Scott Hollenbeck said: >There was no follow-up, so I remain a little unsure of how to address >the comment. Similarly, I need a clarification to know if the text >change suggested below is best made in 4933bis. Yes, I am guilty of not following up. I was unsure of my understanding of channel binding issues, none of the other reviewers of the rfc493* suite made any notice of the issue, and, as you note here, the issue is really in the base spec, not 4933. I just had no idea what the right process would be, if any. Subsequent discussion and review of material make me more confident that there is, indeed, a channel binding issue here. The question is what to do about it. This is an established protocol. Would a security considerations section in 4930bis that pointed out that there's a MITM attack possible here, because of the lack of channel binding, be sufficient? Or would pointing to the sasl-gs2 work as a protection be mentioned? suggested? mandated? I sure would love to see AD or subject matter experts weigh in here on the technical and process aspects of this. --Sandy --_000_C6839129119DCwilliampolknistgov_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [secdir] review of draft-hollenbeck-rfc4933bis-02 I’m a little late to the party, but I have been quietly mulling= over this problem as well.  Now that Sandy has explicitly asked for a= n AD to step in, I figured I should participate more actively.  I have= also added Nico Williams to the CC list (my apologies, Nico) since channel= bindings is really his area of expertise.

I think there is a real need for channel bindings with some applications of= EPP, but may not always be strictly necessary in other cases.  For ex= ample, the e-Automation project for the administration of DNS root zone use= s EPP but if I recall correctly most of the objects that are transferred ar= e digitally signed objects.  In this case, channel bindings are perhap= s less important since we aren’t relying solely on the EPP authentica= tion mechanism.  So, in my opinion we should encourage their use but s= hould not require channel bindings.  

However, if the application is relying on EPP in combination with transport= for security, channel bindings would provide significantly enhanced securi= ty.  That says channel bindings deserves to be mentioned and a little = guidance on (1) implementing channel bindings and (2) determining when chan= nel bindings is required.  That begs a new question of course – = where does this information go?

I am starting to believe that the security considerations section of 4930bi= s should note that enhanced security SHOULD be achieved through channel bin= dings unless the application involves digitally signed objects, and that th= e TLS usage section of 4934bis (section 9) should include a pointer to tech= niques for implementing channel bindings with TLS.  I am still mulling= this over, and will probably not enter any discuss until tomorrow, but thi= s seems the best approach.  (Hopefully Nico will weigh in before then = and keep me straight on this one...)

Tim Polk


On 7/15/09 10:51 AM, "Sandra Murphy" <sandy@sparta.com> wrote:

(Note to all.  I sent multiple secdir = related messages yesterday
afternoon, and they all were mangled or ultimately not delivered.  So = this
is a repeat that some og the recipients may already have seen.
Apologies for the technology failure.)



On Tue, 7 Jul 2009, Scott Hollenbeck said:


>There was no follow-up, so I remain a little unsure of how to address >the comment.  Similarly, I need a clarification to know if the tex= t
>change suggested below is best made in 4933bis.

Yes, I am guilty of not following up.  I was unsure of my understandin= g
of channel binding issues, none of the other reviewers of the rfc493*
suite made any notice of the issue, and, as you note here, the
issue is really in the base spec, not 4933.  I just had no idea
what the right process would be, if any.

Subsequent discussion and review of material make me more confident
that there is, indeed, a channel binding issue here.

The question is what to do about it.  This is an established protocol.=
Would a security considerations section in 4930bis that pointed out
that there's a MITM attack possible here, because of the lack of
channel binding, be sufficient?  Or would pointing to the sasl-gs2
work as a protection be mentioned?  suggested?  mandated?

I sure would love to see AD or subject matter experts weigh in here
on the technical and process aspects of this.

--Sandy



--_000_C6839129119DCwilliampolknistgov_-- From Nicolas.Williams@sun.com Wed Jul 15 11:48:20 2009 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 B04EB3A6F3D; Wed, 15 Jul 2009 11:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.758 X-Spam-Level: X-Spam-Status: No, score=-5.758 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 ZmTC-9MmUtTr; Wed, 15 Jul 2009 11:48:19 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 5149A3A693A; Wed, 15 Jul 2009 11:48:19 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6FHjTxw006566; Wed, 15 Jul 2009 17:45:29 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6FHjT7P020940; Wed, 15 Jul 2009 11:45:29 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n6FHZ6XM008775; Wed, 15 Jul 2009 12:35:06 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6FHZ2iS008774; Wed, 15 Jul 2009 12:35:02 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 15 Jul 2009 12:35:02 -0500 From: Nicolas Williams To: "Hollenbeck, Scott" Message-ID: <20090715173502.GO1274@Sun.COM> References: <046F43A8D79C794FA4733814869CDF07025CD275@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF07025CD275@dul1wnexmb01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.7i Cc: secdir@ietf.org, iesg@ietf.org Subject: Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-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, 15 Jul 2009 18:48:20 -0000 On Tue, Jul 14, 2009 at 08:08:32PM -0400, Hollenbeck, Scott wrote: > Doesn't TLS provide protections for this issue? Provided you authenticate the server, yes. > -----Original Message----- > From: Sandy Murphy [mailto:sandy@tislabs.com] > Sent: Tuesday, July 14, 2009 07:15 PM Eastern Standard Time > To: catherine.meadows@nrl.navy.mil; iesg@ietf.org; sandy@tislabs.com; secdir@ietf.org; Hollenbeck, Scott > Subject: Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-02 > > >A secure authenticThe tie is what is called channel binding. > > OK, obvious blip here. > > A secure authenticated transport connection is established between > 10.1.0.0 to the other end where the login is being attempted, say > 10.2.0.0. > > The trouble is that that 10.2.0.0 might be a man in the middle. > The MITM has another secure authenticated transport connection to > Bob's host, 10.3.0.0. If the channel authenticates the server, then there can be no MITM (assuming the channel's security is not broken). > Bob sends the "login Bob bobscleartextpassword" over its secure > transport connection, which ends at the MITM at 10.2.0.0. > > The MITM retransmits the "login Bob bobscleartextpassword" over the > secure transport connection to 10.1.0.0, impersonating Bob. > > This is possible because there is no tie between the EPP ID of "Bob" > and the secure transport id of 10.2.0.0. > > The tie is what is called channel binding. If the channel does not authenticate the server, then yes, you have this problem, and channel binding is one way to solve it. But any authentication mechanism that depends on sending a password in cleartext (or cleartext equivalent) cannot be used with channel binding. The other solution is to have the channel authenticate the server. > You can look at RFC5056 for more information or at > http://www.saunalahti.fi/~asokan/research/mitm.html for another > discussion with a rather detailed example for PEAP. > > It might be worth pointing out that draft-ietf-sasl-gs2-14 talks > about Using GSS-API Mechanisms in SASL, and supports channel binding. I don't know anything about EPP, but it may very well be the case that an open set of authentication mechanisms would be useful to have in EPP, in which case I'd recommend SASL or the GSS-API. Where authentication mechanisms are used that support channel binding then channel binding should be used: it allows you to use anon-anon channels, it allows you to not worry about the strength of authentication infrastructures for the channels, and it allows you to not have to worry about making sure that the server ID is equivalent in the channel as in the authentication mechanism. Nico -- From Nicolas.Williams@sun.com Wed Jul 15 13:19:49 2009 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 28A523A6A3E; Wed, 15 Jul 2009 13:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.763 X-Spam-Level: X-Spam-Status: No, score=-5.763 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 C4ETjaLBEnwT; Wed, 15 Jul 2009 13:19:47 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 8F86F28C165; Wed, 15 Jul 2009 13:19:20 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6FKISmj001139; Wed, 15 Jul 2009 20:18:28 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6FKIS3e022271; Wed, 15 Jul 2009 14:18:28 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n6FK8859008893; Wed, 15 Jul 2009 15:08:08 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6FK87Ti008892; Wed, 15 Jul 2009 15:08:07 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 15 Jul 2009 15:08:07 -0500 From: Nicolas Williams To: "Hollenbeck, Scott" Message-ID: <20090715200807.GS1274@Sun.COM> References: <046F43A8D79C794FA4733814869CDF07025CD275@dul1wnexmb01.vcorp.ad.vrsn.com> <20090715173502.GO1274@Sun.COM> <046F43A8D79C794FA4733814869CDF0702B8DE7A@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF0702B8DE7A@dul1wnexmb01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.7i Cc: secdir@ietf.org, iesg@ietf.org Subject: Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-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, 15 Jul 2009 20:19:49 -0000 On Wed, Jul 15, 2009 at 03:44:04PM -0400, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] > > Sent: Wednesday, July 15, 2009 1:35 PM > > To: Hollenbeck, Scott > > Cc: Sandy Murphy; catherine.meadows@nrl.navy.mil; > > iesg@ietf.org; secdir@ietf.org > > Subject: Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-02 > > > > On Tue, Jul 14, 2009 at 08:08:32PM -0400, Hollenbeck, Scott wrote: > > > Doesn't TLS provide protections for this issue? > > > > Provided you authenticate the server, yes. > > Good, because server authentication is a requirement specified in > section 9 of 4934bis. And provided we're talking about a two-party, client-server type of application. Specifically, that the username and cleartext password are not being sent to more than one party and never in cleartext. Nico -- From shollenbeck@verisign.com Wed Jul 15 15:12:20 2009 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 806823A6B66; Wed, 15 Jul 2009 15:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e48UEN2BhTtV; Wed, 15 Jul 2009 15:12:19 -0700 (PDT) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id 1D04D3A6B45; Wed, 15 Jul 2009 15:12:19 -0700 (PDT) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n6FLxLQq011765; Wed, 15 Jul 2009 17:59:21 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 23:11:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Jul 2009 18:11:35 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0702B8DE91@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <20090715200807.GS1274@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-02 Thread-Index: AcoFjJFe9m81ua2hS/CYixixcSOlzgADJChQ References: <046F43A8D79C794FA4733814869CDF07025CD275@dul1wnexmb01.vcorp.ad.vrsn.com> <20090715173502.GO1274@Sun.COM> <046F43A8D79C794FA4733814869CDF0702B8DE7A@dul1wnexmb01.vcorp.ad.vrsn.com> <20090715200807.GS1274@Sun.COM> From: "Hollenbeck, Scott" To: "Nicolas Williams" X-OriginalArrivalTime: 15 Jul 2009 22:11:36.0144 (UTC) FILETIME=[38049500:01CA0599] Cc: secdir@ietf.org, iesg@ietf.org Subject: Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-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, 15 Jul 2009 22:12:20 -0000 > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 > Sent: Wednesday, July 15, 2009 4:08 PM > To: Hollenbeck, Scott > Cc: Sandy Murphy; catherine.meadows@nrl.navy.mil;=20 > iesg@ietf.org; secdir@ietf.org > Subject: Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-02 >=20 > On Wed, Jul 15, 2009 at 03:44:04PM -0400, Hollenbeck, Scott wrote: > > > -----Original Message----- > > > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] > > > Sent: Wednesday, July 15, 2009 1:35 PM > > > To: Hollenbeck, Scott > > > Cc: Sandy Murphy; catherine.meadows@nrl.navy.mil; iesg@ietf.org;=20 > > > secdir@ietf.org > > > Subject: Re: [secdir] Secdir review of=20 > > > draft-hollenbeck-rfc4930bis-02 > > >=20 > > > On Tue, Jul 14, 2009 at 08:08:32PM -0400, Hollenbeck, Scott wrote: > > > > Doesn't TLS provide protections for this issue? > > >=20 > > > Provided you authenticate the server, yes. > >=20 > > Good, because server authentication is a requirement specified in=20 > > section 9 of 4934bis. >=20 > And provided we're talking about a two-party, client-server=20 > type of application. Specifically, that the username and=20 > cleartext password are not being sent to more than one party=20 > and never in cleartext. That's exactly how it works right now. -Scott- From shollenbeck@verisign.com Wed Jul 15 15:19:53 2009 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 E7BAA3A6F4C; Wed, 15 Jul 2009 15:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tP8sKe8k2NZH; Wed, 15 Jul 2009 15:19:53 -0700 (PDT) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id 2A0F13A69BF; Wed, 15 Jul 2009 15:19:53 -0700 (PDT) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n6FJVoh8003034; Wed, 15 Jul 2009 15:31:50 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 20:44:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Jul 2009 15:44:04 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0702B8DE7A@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <20090715173502.GO1274@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-02 Thread-Index: AcoFdzYL/rIe8wI/ToCP2cn8/I7N6AADL2Tw References: <046F43A8D79C794FA4733814869CDF07025CD275@dul1wnexmb01.vcorp.ad.vrsn.com> <20090715173502.GO1274@Sun.COM> From: "Hollenbeck, Scott" To: "Nicolas Williams" X-OriginalArrivalTime: 15 Jul 2009 19:44:05.0095 (UTC) FILETIME=[9C61AF70:01CA0584] Cc: secdir@ietf.org, iesg@ietf.org Subject: Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-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, 15 Jul 2009 22:19:54 -0000 > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 > Sent: Wednesday, July 15, 2009 1:35 PM > To: Hollenbeck, Scott > Cc: Sandy Murphy; catherine.meadows@nrl.navy.mil;=20 > iesg@ietf.org; secdir@ietf.org > Subject: Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-02 >=20 > On Tue, Jul 14, 2009 at 08:08:32PM -0400, Hollenbeck, Scott wrote: > > Doesn't TLS provide protections for this issue? >=20 > Provided you authenticate the server, yes. Good, because server authentication is a requirement specified in section 9 of 4934bis. -Scott- From shollenbeck@verisign.com Wed Jul 15 17:41:01 2009 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 B6BA23A685B; Wed, 15 Jul 2009 17:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 F5lB7l-sWyEU; Wed, 15 Jul 2009 17:40:54 -0700 (PDT) Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by core3.amsl.com (Postfix) with ESMTP id 3A2E13A69B6; Wed, 15 Jul 2009 17:40:54 -0700 (PDT) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id n6FJc9Ln013232; Wed, 15 Jul 2009 15:38:09 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 20:49:14 +0100 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_01CA0585.54A630B6" Date: Wed, 15 Jul 2009 15:49:13 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0702B8DE7B@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] review of draft-hollenbeck-rfc4933bis-02 Thread-Index: AcoFZXnEUGL5r6YURci2FQADJAXtMgAEHd0kAAOyU5A= References: From: "Hollenbeck, Scott" To: "Polk, William T." , "Sandra Murphy" X-OriginalArrivalTime: 15 Jul 2009 19:49:14.0589 (UTC) FILETIME=[54DAB8D0:01CA0585] Cc: iesg@ietf.org, Nicolas Williams , secdir@ietf.org Subject: Re: [secdir] review of draft-hollenbeck-rfc4933bis-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: Thu, 16 Jul 2009 00:41:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0585.54A630B6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't have an issue with adding appropriate text to 4934bis. Help in coming up with something that's appropriate would be appreciated. =20 I'm a little concerned about adding text to 4930bis unless the text is generic enough to apply to all potential transport protocols. A specific addition proposal would be very helpful. =20 -Scott- ________________________________ From: Polk, William T. [mailto:william.polk@nist.gov]=20 Sent: Wednesday, July 15, 2009 1:59 PM To: Sandra Murphy; Hollenbeck, Scott Cc: Catherine Meadows; iesg@ietf.org; secdir@ietf.org; Nicolas Williams Subject: Re: [secdir] review of draft-hollenbeck-rfc4933bis-02 =09 =09 I'm a little late to the party, but I have been quietly mulling over this problem as well. Now that Sandy has explicitly asked for an AD to step in, I figured I should participate more actively. I have also added Nico Williams to the CC list (my apologies, Nico) since channel bindings is really his area of expertise. =09 I think there is a real need for channel bindings with some applications of EPP, but may not always be strictly necessary in other cases. For example, the e-Automation project for the administration of DNS root zone uses EPP but if I recall correctly most of the objects that are transferred are digitally signed objects. In this case, channel bindings are perhaps less important since we aren't relying solely on the EPP authentication mechanism. So, in my opinion we should encourage their use but should not require channel bindings. =20 =09 However, if the application is relying on EPP in combination with transport for security, channel bindings would provide significantly enhanced security. That says channel bindings deserves to be mentioned and a little guidance on (1) implementing channel bindings and (2) determining when channel bindings is required. That begs a new question of course - where does this information go? =09 I am starting to believe that the security considerations section of 4930bis should note that enhanced security SHOULD be achieved through channel bindings unless the application involves digitally signed objects, and that the TLS usage section of 4934bis (section 9) should include a pointer to techniques for implementing channel bindings with TLS. I am still mulling this over, and will probably not enter any discuss until tomorrow, but this seems the best approach. (Hopefully Nico will weigh in before then and keep me straight on this one...) =09 Tim Polk =09 =09 On 7/15/09 10:51 AM, "Sandra Murphy" wrote: =09 =09 (Note to all. I sent multiple secdir related messages yesterday afternoon, and they all were mangled or ultimately not delivered. So this is a repeat that some og the recipients may already have seen. Apologies for the technology failure.) =09 =09 =09 On Tue, 7 Jul 2009, Scott Hollenbeck said: =09 =09 >There was no follow-up, so I remain a little unsure of how to address >the comment. Similarly, I need a clarification to know if the text >change suggested below is best made in 4933bis. =09 Yes, I am guilty of not following up. I was unsure of my understanding of channel binding issues, none of the other reviewers of the rfc493* suite made any notice of the issue, and, as you note here, the issue is really in the base spec, not 4933. I just had no idea what the right process would be, if any. =09 Subsequent discussion and review of material make me more confident that there is, indeed, a channel binding issue here. =09 The question is what to do about it. This is an established protocol. Would a security considerations section in 4930bis that pointed out that there's a MITM attack possible here, because of the lack of channel binding, be sufficient? Or would pointing to the sasl-gs2 work as a protection be mentioned? suggested? mandated? =09 I sure would love to see AD or subject matter experts weigh in here on the technical and process aspects of this. =09 --Sandy =09 =09 =09 =09 ------_=_NextPart_001_01CA0585.54A630B6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [secdir] review of = draft-hollenbeck-rfc4933bis-02
I don't have an issue with adding appropriate text to=20 4934bis.  Help in coming up with something that's appropriate would = be=20 appreciated.
 
I'm a little concerned about adding text to 4930bis = unless the=20 text is generic enough to apply to all potential transport = protocols.  A=20 specific addition proposal would be very helpful.
 
-Scott-

From: Polk, William T.=20 [mailto:william.polk@nist.gov]
Sent: Wednesday, July 15, = 2009 1:59=20 PM
To: Sandra Murphy; Hollenbeck, Scott
Cc: = Catherine=20 Meadows; iesg@ietf.org; secdir@ietf.org; Nicolas = Williams
Subject:=20 Re: [secdir] review of = draft-hollenbeck-rfc4933bis-02

I’m a little late to the party, but I = have been=20 quietly mulling over this problem as well.  Now that Sandy has = explicitly=20 asked for an AD to step in, I figured I should participate more = actively.=20  I have also added Nico Williams to the CC list (my apologies, = Nico)=20 since channel bindings is really his area of expertise.

I think = there=20 is a real need for channel bindings with some applications of EPP, but = may not=20 always be strictly necessary in other cases.  For example, the=20 e-Automation project for the administration of DNS root zone uses EPP = but if I=20 recall correctly most of the objects that are transferred are = digitally signed=20 objects.  In this case, channel bindings are perhaps less = important since=20 we aren’t relying solely on the EPP authentication mechanism. =  So, in my=20 opinion we should encourage their use but should not require channel = bindings.=20  

However, if the application is relying on EPP in = combination=20 with transport for security, channel bindings would provide = significantly=20 enhanced security.  That says channel bindings deserves to be = mentioned=20 and a little guidance on (1) implementing channel bindings and (2) = determining=20 when channel bindings is required.  That begs a new question of = course –=20 where does this information go?

I am starting to believe that = the=20 security considerations section of 4930bis should note that enhanced = security=20 SHOULD be achieved through channel bindings unless the application = involves=20 digitally signed objects, and that the TLS usage section of 4934bis = (section=20 9) should include a pointer to techniques for implementing channel = bindings=20 with TLS.  I am still mulling this over, and will probably not = enter any=20 discuss until tomorrow, but this seems the best approach. =  (Hopefully=20 Nico will weigh in before then and keep me straight on this = one...)

Tim=20 Polk


On 7/15/09 10:51 AM, "Sandra Murphy" <sandy@sparta.com> = wrote:
(Note to all.  I sent multiple secdir = related=20 messages yesterday
afternoon, and they all were mangled or = ultimately not=20 delivered.  So this
is a repeat that some og the recipients = may=20 already have seen.
Apologies for the technology=20 failure.)



On Tue, 7 Jul 2009, Scott Hollenbeck=20 said:


>There was no follow-up, so I remain a little = unsure of=20 how to address
>the comment.  Similarly, I need a = clarification=20 to know if the text
>change suggested below is best made in=20 4933bis.

Yes, I am guilty of not following up.  I was = unsure of=20 my understanding
of channel binding issues, none of the other = reviewers=20 of the rfc493*
suite made any notice of the issue, and, as you = note here,=20 the
issue is really in the base spec, not 4933.  I just had = no=20 idea
what the right process would be, if any.

Subsequent=20 discussion and review of material make me more confident
that = there is,=20 indeed, a channel binding issue here.

The question is what to = do=20 about it.  This is an established protocol.
Would a security = considerations section in 4930bis that pointed out
that there's a = MITM=20 attack possible here, because of the lack of
channel binding, be=20 sufficient?  Or would pointing to the sasl-gs2
work as a = protection=20 be mentioned?  suggested?  mandated?

I sure would = love to=20 see AD or subject matter experts weigh in here
on the technical = and=20 process aspects of=20 = this.

--Sandy



------_=_NextPart_001_01CA0585.54A630B6-- From julien.laganier.ietf@googlemail.com Wed Jul 15 18:01:07 2009 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 E45AC3A69D6 for ; Wed, 15 Jul 2009 18:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 jFWM+CWmzY0Y for ; Wed, 15 Jul 2009 18:01:07 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id C10573A6F96 for ; Wed, 15 Jul 2009 18:01:06 -0700 (PDT) Received: by bwz28 with SMTP id 28so1755332bwz.37 for ; Wed, 15 Jul 2009 18:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=vnLxxnGKFUr6+oTf1NS+yxbJDgxekZ77HgWfzCJM9Ss=; b=jsM6UYPAJhBelS4XBV6/QEA0FF+IJq0NOVFaPjjt2R3gvUmCA2dUaNKAEkfFBDwHw3 kDFLYYBoqxzgBt+ldvGrIckU1+IuJhxQu2Gqv2hnQ7TFUUhmYJNtiRW6FvMxHT+Mtijp WR9zeZTRFOq2r18uIXUuRalMnW8pyAVs5YGxc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=WLXeWQivN7XuwRFJwRYxXM9skt5tf5heMN2nWLUJ4URNsos6csoG+OckwNzr9iQGEF 9FyG7JYixaZb9gWnwGqoYtyOfsW+6zR1waeBiSDMsPtQllyFyTkeC8N1SpNavFmYpwAi TbuoKGS4VtUYlLkS424HyIGi+JKKBb+6Ba1+U= MIME-Version: 1.0 Received: by 10.204.79.20 with SMTP id n20mr8135026bkk.78.1247706095956; Wed, 15 Jul 2009 18:01:35 -0700 (PDT) Date: Wed, 15 Jul 2009 18:01:35 -0700 Message-ID: <7ad6d6db0907151801k71bcb9b9o4170715d61af3f2c@mail.gmail.com> From: Julien Laganier To: secdir@ietf.org, shollenbeck@verisign.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] SECDIR review of draft-hollenbeck-rfc4934bis-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: Thu, 16 Jul 2009 01:01:08 -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. Abstract: This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document is intended to obsolete RFC 4934. I have no security concerns with the draft. --julien From julien.laganier.ietf@googlemail.com Wed Jul 15 18:26:19 2009 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 B13C43A6C95 for ; Wed, 15 Jul 2009 18:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 fhtkKz6+N0q5 for ; Wed, 15 Jul 2009 18:26:19 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 95EFB3A68BB for ; Wed, 15 Jul 2009 18:26:18 -0700 (PDT) Received: by bwz28 with SMTP id 28so1762077bwz.37 for ; Wed, 15 Jul 2009 18:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=o2QEL3RbnBf0tx2xvbbW5E91jS7FXgas7zIGEYa9rL8=; b=rqKcWg3S24KjRZxVCtJDXB3mMcW/5FUlUCumUWV+PALKPGmcpyLLtz/9+IxidRH3n4 ouCnR0aZ6wwc2Rz31t7hOhNzzpk/JkpTZL6+md7TcFsmqcI4CbxWmFhjsk7BtIm13qph SkH2qub+hHVI2mkazKjB+ZuPWiKs7CZaar57s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=PP96LEvBTUvpKrLSvylTJowkIixRPJnk/4mCwpBDZfzGEkulEPEhX3R54fFd+b/Gzf TwOewYu71p1y2Xuj7ilnZ5xK4gVlWZbrUCL5oNbgyLZGi0U7yo66+4OkGfCSLOXC1KBu OuQMqp1AhDE1EYq27Xs+4Bt4ADh9bk0KHYt20= MIME-Version: 1.0 Received: by 10.204.115.130 with SMTP id i2mr8231410bkq.162.1247707608082; Wed, 15 Jul 2009 18:26:48 -0700 (PDT) Date: Wed, 15 Jul 2009 18:26:48 -0700 Message-ID: <7ad6d6db0907151826j1807bb14w37e15ab3415d2172@mail.gmail.com> From: Julien Laganier To: secdir@ietf.org, yakov@juniper.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] SECDIR review of draft-ietf-l3vpn-v6-ext-communities-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: Thu, 16 Jul 2009 01:26:19 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Abstract: Current specifications of BGP Extended Communities [RFC4360] support IPv4 Address Specific Extended Community, but do not support IPv6 Address Specific Extended Community. The lack of IPv6 Address Specific Extended Community may be a problem when an application uses IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, IPv6 Address Specific Extended Community that addresses this problem. The IPv6 Address Specific Extended Community is similar to the IPv4 Address Specific Extended Community, except that it carries an IPv6 address rather than an IPv4 address. The security considerations section states that "All the security considerations for BGP Extended Communities apply" which I think is reasonable given the scope of the document. As a result I have no security concerns with this document. --julien From alexey.melnikov@isode.com Thu Jul 16 04:24:30 2009 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 C55883A6986; Thu, 16 Jul 2009 04:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 dsVkiZQ5Mhyo; Thu, 16 Jul 2009 04:24:29 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 497713A6CE1; Thu, 16 Jul 2009 04:24:29 -0700 (PDT) Received: from [172.16.2.156] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 16 Jul 2009 12:19:07 +0100 Message-ID: <4A5F0C80.10504@isode.com> Date: Thu, 16 Jul 2009 12:18:24 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "Polk, William T." References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: quoted-printable Cc: Nicolas Williams , "secdir@ietf.org" , "Hollenbeck, Scott" , "iesg@ietf.org" Subject: Re: [secdir] review of draft-hollenbeck-rfc4933bis-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: Thu, 16 Jul 2009 11:24:30 -0000 Hi Tim, Polk, William T. wrote: > I=92m a little late to the party, but I have been quietly mulling over=20 > this problem as well. Now that Sandy has explicitly asked for an AD to=20 > step in, I figured I should participate more actively. I have also=20 > added Nico Williams to the CC list (my apologies, Nico) since channel=20 > bindings is really his area of expertise. > > I think there is a real need for channel bindings with some=20 > applications of EPP, but may not always be strictly necessary in other=20 > cases. For example, the e-Automation project for the administration of=20 > DNS root zone uses EPP but if I recall correctly most of the objects=20 > that are transferred are digitally signed objects. In this case,=20 > channel bindings are perhaps less important since we aren=92t relying=20 > solely on the EPP authentication mechanism. So, in my opinion we=20 > should encourage their use but should not require channel bindings. > > However, if the application is relying on EPP in combination with=20 > transport for security, channel bindings would provide significantly=20 > enhanced security. That says channel bindings deserves to be mentioned=20 > and a little guidance on (1) implementing channel bindings and (2)=20 > determining when channel bindings is required. That begs a new=20 > question of course =96 where does this information go? Nico's response confirmed what I was thinking about this myself: for EPP=20 running over TLS over TCP (4934bis), channel bindings are not required,=20 because TLS authentication is mandatory and because TLS server=20 certificate verification procedure is also mandatory. So I don't think there is an issue with 4934bis document. > I am starting to believe that the security considerations section of=20 > 4930bis should note that enhanced security SHOULD be achieved through=20 > channel bindings unless the application involves digitally signed objects, I think another alternative can be to require mutual TLS authentication=20 in a transport protocol mapping document. > and that the TLS usage section of 4934bis (section 9) should include a=20 > pointer to techniques for implementing channel bindings with TLS. As per my coment above, I don't think this is needed. Besides adding channel bindings to EPP would require an extension to EPP=20 itself. > I am still mulling this over, and will probably not enter any discuss=20 > until tomorrow, but this seems the best approach. (Hopefully Nico will=20 > weigh in before then and keep me straight on this one...) From william.polk@nist.gov Thu Jul 16 07:55:44 2009 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 99F7F3A6876; Thu, 16 Jul 2009 07:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.084 X-Spam-Level: X-Spam-Status: No, score=-6.084 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599, 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 B+Yesu6c7fTN; Thu, 16 Jul 2009 07:55:43 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id D77593A6D91; Thu, 16 Jul 2009 07:54:37 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n6GEsQHA002219; Thu, 16 Jul 2009 10:54:26 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Thu, 16 Jul 2009 10:54:26 -0400 From: "Polk, William T." To: Alexey Melnikov , "Polk, William T." Date: Thu, 16 Jul 2009 10:54:24 -0400 Thread-Topic: [secdir] review of draft-hollenbeck-rfc4933bis-02 Thread-Index: AcoGB0s9WTyFR0ThSV6ypjTdqj4AvgAHgOeK Message-ID: In-Reply-To: <4A5F0C80.10504@isode.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov X-Mailman-Approved-At: Thu, 16 Jul 2009 08:12:31 -0700 Cc: Nicolas, Williams , "secdir@ietf.org" , "Hollenbeck, Scott" , "iesg@ietf.org" Subject: Re: [secdir] review of draft-hollenbeck-rfc4933bis-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: Thu, 16 Jul 2009 14:55:44 -0000 Hi Alexey, On 7/16/09 7:18 AM, "Alexey Melnikov" wrote: > Hi Tim, >=20 > Polk, William T. wrote: >=20 >> I=B9m a little late to the party, but I have been quietly mulling over >> this problem as well. Now that Sandy has explicitly asked for an AD to >> step in, I figured I should participate more actively. I have also >> added Nico Williams to the CC list (my apologies, Nico) since channel >> bindings is really his area of expertise. >>=20 >> I think there is a real need for channel bindings with some >> applications of EPP, but may not always be strictly necessary in other >> cases. For example, the e-Automation project for the administration of >> DNS root zone uses EPP but if I recall correctly most of the objects >> that are transferred are digitally signed objects. In this case, >> channel bindings are perhaps less important since we aren=B9t relying >> solely on the EPP authentication mechanism. So, in my opinion we >> should encourage their use but should not require channel bindings. >=20 >>=20 >> However, if the application is relying on EPP in combination with >> transport for security, channel bindings would provide significantly >> enhanced security. That says channel bindings deserves to be mentioned >> and a little guidance on (1) implementing channel bindings and (2) >> determining when channel bindings is required. That begs a new >> question of course =AD where does this information go? >=20 > Nico's response confirmed what I was thinking about this myself: for EPP > running over TLS over TCP (4934bis), channel bindings are not required, > because TLS authentication is mandatory and because TLS server > certificate verification procedure is also mandatory. > So I don't think there is an issue with 4934bis document. >=20 I'm not so sure... TLS server certificate verification protects the client against a MITM attack. The server has no way of knowing whether this procedure has been implemented. So, the server does not have all the protection it needs unless the TLS connection uses client certificate authentication as well. Channel bindings would extend the level of assurance for the server. Alternatively, mutual authentication using certificates would resolve the problem as well. >> I am starting to believe that the security considerations section of >> 4930bis should note that enhanced security SHOULD be achieved through >> channel bindings unless the application involves digitally signed object= s, >=20 > I think another alternative can be to require mutual TLS authentication > in a transport protocol mapping document. I think that would be a great solution, and it wouldn't need to tamper with EPP or 4934bis. Any new EPP transport protocol mappings in the works? >=20 >> and that the TLS usage section of 4934bis (section 9) should include a >> pointer to techniques for implementing channel bindings with TLS. >=20 > As per my coment above, I don't think this is needed. > Besides adding channel bindings to EPP would require an extension to EPP > itself. That has been part of my concern from the beginning. Since we are progressing to Full Standard, extending EPP is pretty much a non-starter. That is why I would prefer to restrict my discuss or comment to raising issues in the security considerations of 4930bis. >=20 >> I am still mulling this over, and will probably not enter any discuss >> until tomorrow, but this seems the best approach. (Hopefully Nico will >> weigh in before then and keep me straight on this one...) >=20 >=20 >=20 From william.polk@nist.gov Thu Jul 16 08:01:41 2009 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 F17943A6D8C; Thu, 16 Jul 2009 08:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599, 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 JxPECovanr+T; Thu, 16 Jul 2009 08:01:41 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id BA7843A6964; Thu, 16 Jul 2009 08:01:40 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n6GF2AAu006814; Thu, 16 Jul 2009 11:02:10 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Thu, 16 Jul 2009 11:01:58 -0400 From: "Polk, William T." To: Alexey Melnikov Date: Thu, 16 Jul 2009 11:01:57 -0400 Thread-Topic: [secdir] review of draft-hollenbeck-rfc4933bis-02 Thread-Index: AcoGB0s9WTyFR0ThSV6ypjTdqj4AvgAHgOeKAABDgbQ= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov X-Mailman-Approved-At: Thu, 16 Jul 2009 08:12:31 -0700 Cc: Nicolas, Williams , "secdir@ietf.org" , "Hollenbeck, Scott" , "iesg@ietf.org" Subject: Re: [secdir] review of draft-hollenbeck-rfc4933bis-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: Thu, 16 Jul 2009 15:01:42 -0000 Alexey, I just went back and looked at 4934bis... You were right, there is no channel bindings problem there. I missed the fact that client certs are *required*, since the bulk of the section specified how the client should verify the server identity, but no such text exists for the client cert. Probably should correct that oversight, but there is no systemic problem. Still mulling over 4930... Any reason we can't make 4934bis the mandatory to implement transport? Tim=20 On 7/16/09 10:54 AM, "Polk, Tim" wrote: > Hi Alexey, >=20 >=20 > On 7/16/09 7:18 AM, "Alexey Melnikov" wrote: >=20 >> Hi Tim, >>=20 >> Polk, William T. wrote: >>=20 >>> I=B9m a little late to the party, but I have been quietly mulling over >>> this problem as well. Now that Sandy has explicitly asked for an AD to >>> step in, I figured I should participate more actively. I have also >>> added Nico Williams to the CC list (my apologies, Nico) since channel >>> bindings is really his area of expertise. >>>=20 >>> I think there is a real need for channel bindings with some >>> applications of EPP, but may not always be strictly necessary in other >>> cases. For example, the e-Automation project for the administration of >>> DNS root zone uses EPP but if I recall correctly most of the objects >>> that are transferred are digitally signed objects. In this case, >>> channel bindings are perhaps less important since we aren=B9t relying >>> solely on the EPP authentication mechanism. So, in my opinion we >>> should encourage their use but should not require channel bindings. >>=20 >>>=20 >>> However, if the application is relying on EPP in combination with >>> transport for security, channel bindings would provide significantly >>> enhanced security. That says channel bindings deserves to be mentioned >>> and a little guidance on (1) implementing channel bindings and (2) >>> determining when channel bindings is required. That begs a new >>> question of course =AD where does this information go? >>=20 >> Nico's response confirmed what I was thinking about this myself: for EPP >> running over TLS over TCP (4934bis), channel bindings are not required, >> because TLS authentication is mandatory and because TLS server >> certificate verification procedure is also mandatory. >> So I don't think there is an issue with 4934bis document. >>=20 >=20 > I'm not so sure... TLS server certificate verification protects the clien= t > against a MITM attack. The server has no way of knowing whether this > procedure has been implemented. So, the server does not have all the > protection it needs unless the TLS connection uses client certificate > authentication as well. >=20 > Channel bindings would extend the level of assurance for the server. > Alternatively, mutual authentication using certificates would resolve the > problem as well. >=20 >>> I am starting to believe that the security considerations section of >>> 4930bis should note that enhanced security SHOULD be achieved through >>> channel bindings unless the application involves digitally signed objec= ts, >>=20 >> I think another alternative can be to require mutual TLS authentication >> in a transport protocol mapping document. >=20 > I think that would be a great solution, and it wouldn't need to tamper wi= th > EPP or 4934bis. Any new EPP transport protocol mappings in the works? >=20 >>=20 >>> and that the TLS usage section of 4934bis (section 9) should include a >>> pointer to techniques for implementing channel bindings with TLS. >>=20 >> As per my coment above, I don't think this is needed. >> Besides adding channel bindings to EPP would require an extension to EPP >> itself. >=20 > That has been part of my concern from the beginning. Since we are progre= ssing > to Full Standard, extending EPP is pretty much a non-starter. >=20 > That is why I would prefer to restrict my discuss or comment to raising > issues in the security considerations of 4930bis. >=20 >>=20 >>> I am still mulling this over, and will probably not enter any discuss >>> until tomorrow, but this seems the best approach. (Hopefully Nico will >>> weigh in before then and keep me straight on this one...) >>=20 >>=20 >>=20 From Nicolas.Williams@sun.com Thu Jul 16 08:26:54 2009 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 C435928C180; Thu, 16 Jul 2009 08:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.767 X-Spam-Level: X-Spam-Status: No, score=-5.767 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 OUd5SBj-mQMB; Thu, 16 Jul 2009 08:26:53 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 3B5EB3A6D8F; Thu, 16 Jul 2009 08:26:53 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6GFREoJ016707; Thu, 16 Jul 2009 15:27:14 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6GFREuZ015833; Thu, 16 Jul 2009 09:27:14 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n6GFGtdF009378; Thu, 16 Jul 2009 10:16:55 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6GFGslg009377; Thu, 16 Jul 2009 10:16:54 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 16 Jul 2009 10:16:54 -0500 From: Nicolas Williams To: "Polk, William T." Message-ID: <20090716151653.GX1274@Sun.COM> References: <4A5F0C80.10504@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "secdir@ietf.org" , "Hollenbeck, Scott" , "iesg@ietf.org" Subject: Re: [secdir] review of draft-hollenbeck-rfc4933bis-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: Thu, 16 Jul 2009 15:26:54 -0000 On Thu, Jul 16, 2009 at 10:54:24AM -0400, Polk, William T. wrote: > > Nico's response confirmed what I was thinking about this myself: for EPP > > running over TLS over TCP (4934bis), channel bindings are not required, > > because TLS authentication is mandatory and because TLS server > > certificate verification procedure is also mandatory. > > So I don't think there is an issue with 4934bis document. > > I'm not so sure... TLS server certificate verification protects the client > against a MITM attack. The server has no way of knowing whether this > procedure has been implemented. So, the server does not have all the > protection it needs unless the TLS connection uses client certificate > authentication as well. > > Channel bindings would extend the level of assurance for the server. > Alternatively, mutual authentication using certificates would resolve the > problem as well. The client can always just post the username & password in a very public place, spam people with it, ... Channel binding doesn't protect against that! ;) From Sandra.Murphy@cobham.com Thu Jul 16 09:02:02 2009 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 512573A69D9; Thu, 16 Jul 2009 09:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 cbjQMDgsS7qM; Thu, 16 Jul 2009 09:02:01 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 043E93A67AC; Thu, 16 Jul 2009 09:02:00 -0700 (PDT) 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 n6GG1Cet007132; Thu, 16 Jul 2009 11:01:12 -0500 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 n6GG1CRN016977; Thu, 16 Jul 2009 11:01:12 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.126]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 12:01:11 -0400 Date: Thu, 16 Jul 2009 12:01:09 -0400 (Eastern Daylight Time) From: Sandra Murphy To: "Polk, William T." In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="74044448-22167-1247760069=:4816" X-OriginalArrivalTime: 16 Jul 2009 16:01:11.0568 (UTC) FILETIME=[A38D2900:01CA062E] Cc: Nicolas Williams , "secdir@ietf.org" , "Hollenbeck, Scott" , "iesg@ietf.org" Subject: Re: [secdir] review of draft-hollenbeck-rfc4933bis-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: Thu, 16 Jul 2009 16:02:02 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --74044448-22167-1247760069=:4816 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 16 Jul 2009, Polk, William T. wrote: > Hi Alexey, > > > On 7/16/09 7:18 AM, "Alexey Melnikov" wrote: > >> Hi Tim, >> >> Polk, William T. wrote: >> >>> I=B9m a little late to the party, but I have been quietly mulling over >>> this problem as well. Now that Sandy has explicitly asked for an AD to >>> step in, I figured I should participate more actively. I have also >>> added Nico Williams to the CC list (my apologies, Nico) since channel >>> bindings is really his area of expertise. >>> >>> I think there is a real need for channel bindings with some >>> applications of EPP, but may not always be strictly necessary in other >>> cases. For example, the e-Automation project for the administration of >>> DNS root zone uses EPP but if I recall correctly most of the objects >>> that are transferred are digitally signed objects. In this case, >>> channel bindings are perhaps less important since we aren=B9t relying >>> solely on the EPP authentication mechanism. So, in my opinion we >>> should encourage their use but should not require channel bindings. >> >>> >>> However, if the application is relying on EPP in combination with >>> transport for security, channel bindings would provide significantly >>> enhanced security. That says channel bindings deserves to be mentioned >>> and a little guidance on (1) implementing channel bindings and (2) >>> determining when channel bindings is required. That begs a new >>> question of course =AD where does this information go? >> >> Nico's response confirmed what I was thinking about this myself: for EPP >> running over TLS over TCP (4934bis), channel bindings are not required, >> because TLS authentication is mandatory and because TLS server >> certificate verification procedure is also mandatory. >> So I don't think there is an issue with 4934bis document. >> > > I'm not so sure... TLS server certificate verification protects the clien= t > against a MITM attack. The server has no way of knowing whether this > procedure has been implemented. So, the server does not have all the > protection it needs unless the TLS connection uses client certificate > authentication as well. > > Channel bindings would extend the level of assurance for the server. > Alternatively, mutual authentication using certificates would resolve the > problem as well. > >>> I am starting to believe that the security considerations section of >>> 4930bis should note that enhanced security SHOULD be achieved through >>> channel bindings unless the application involves digitally signed objec= ts, >> >> I think another alternative can be to require mutual TLS authentication >> in a transport protocol mapping document. > > I think that would be a great solution, and it wouldn't need to tamper wi= th > EPP or 4934bis. Any new EPP transport protocol mappings in the works? rfc4930bis mentions a couple of others in sect 2.1 Transport Mapping=20 Considerations - The transport mapping MUST be onto a transport such as TCP [RFC0793] or Stream Control Transmission Protocol (SCTP) [RFC4960] that provides congestion avoidance that follows RFC 2914 [RFC2914], or if it maps onto a protocol such as SMTP [RFC5321] or Blocks Extensible Exchange Protocol (BEEP) [RFC3080], then the performance issues need to take into account issues of overload, server availability, and so forth. I don't know how close to "in the works" those other suggested examples=20 are. Later it says that EPP can be carried over both connection-less and=20 connection oriented transports. And the security considerations section says that EPP instances MUST be protected using a transport mechanism or application protocol that provides integrity, confidentiality, and mutual strong client-server authentication. --Sandy > >> >>> and that the TLS usage section of 4934bis (section 9) should include a >>> pointer to techniques for implementing channel bindings with TLS. >> >> As per my coment above, I don't think this is needed. >> Besides adding channel bindings to EPP would require an extension to EPP >> itself. > > That has been part of my concern from the beginning. Since we are > progressing to Full Standard, extending EPP is pretty much a non-starter. > > That is why I would prefer to restrict my discuss or comment to raising > issues in the security considerations of 4930bis. > >> >>> I am still mulling this over, and will probably not enter any discuss >>> until tomorrow, but this seems the best approach. (Hopefully Nico will >>> weigh in before then and keep me straight on this one...) >> >> >> > > --74044448-22167-1247760069=:4816-- From shollenbeck@verisign.com Thu Jul 16 09:07:06 2009 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 C58F53A6930; Thu, 16 Jul 2009 09:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id est7esOJmn4H; Thu, 16 Jul 2009 09:07:05 -0700 (PDT) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id B40903A6DB9; Thu, 16 Jul 2009 09:07:05 -0700 (PDT) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n6GFsa2c003771; Thu, 16 Jul 2009 11:54:36 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 12:06:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Jul 2009 12:06:51 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0702B8DF05@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] review of draft-hollenbeck-rfc4933bis-02 Thread-Index: AcoGLuISCQv7N5l1ThuUAr1OH9enpwAADFhA References: From: "Hollenbeck, Scott" To: "Sandra Murphy" , "Polk, William T." X-OriginalArrivalTime: 16 Jul 2009 16:06:52.0767 (UTC) FILETIME=[6EEBFEF0:01CA062F] Cc: iesg@ietf.org, Nicolas Williams , secdir@ietf.org Subject: Re: [secdir] review of draft-hollenbeck-rfc4933bis-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: Thu, 16 Jul 2009 16:07:06 -0000 > -----Original Message----- > From: Sandra Murphy [mailto:sandy@sparta.com]=20 > Sent: Thursday, July 16, 2009 12:01 PM > To: Polk, William T. > Cc: Alexey Melnikov; Hollenbeck, Scott; Catherine Meadows;=20 > iesg@ietf.org; Nicolas Williams; secdir@ietf.org > Subject: Re: [secdir] review of draft-hollenbeck-rfc4933bis-02 >=20 >=20 > On Thu, 16 Jul 2009, Polk, William T. wrote: >=20 > > Hi Alexey, > > > > > > On 7/16/09 7:18 AM, "Alexey Melnikov"=20 > wrote: > > > >> Hi Tim, > >> > >> Polk, William T. wrote: > >> > >>> I=B9m a little late to the party, but I have been quietly=20 > mulling over=20 > >>> this problem as well. Now that Sandy has explicitly asked=20 > for an AD=20 > >>> to step in, I figured I should participate more actively. I have=20 > >>> also added Nico Williams to the CC list (my apologies,=20 > Nico) since=20 > >>> channel bindings is really his area of expertise. > >>> > >>> I think there is a real need for channel bindings with some=20 > >>> applications of EPP, but may not always be strictly necessary in=20 > >>> other cases. For example, the e-Automation project for the=20 > >>> administration of DNS root zone uses EPP but if I recall=20 > correctly=20 > >>> most of the objects that are transferred are digitally signed=20 > >>> objects. In this case, channel bindings are perhaps less=20 > important=20 > >>> since we aren=B9t relying solely on the EPP authentication=20 > mechanism.=20 > >>> So, in my opinion we should encourage their use but=20 > should not require channel bindings. > >> > >>> > >>> However, if the application is relying on EPP in combination with=20 > >>> transport for security, channel bindings would provide=20 > significantly=20 > >>> enhanced security. That says channel bindings deserves to be=20 > >>> mentioned and a little guidance on (1) implementing=20 > channel bindings=20 > >>> and (2) determining when channel bindings is required.=20 > That begs a=20 > >>> new question of course =AD where does this information go? > >> > >> Nico's response confirmed what I was thinking about this=20 > myself: for=20 > >> EPP running over TLS over TCP (4934bis), channel bindings are not=20 > >> required, because TLS authentication is mandatory and because TLS=20 > >> server certificate verification procedure is also mandatory. > >> So I don't think there is an issue with 4934bis document. > >> > > > > I'm not so sure... TLS server certificate verification protects the=20 > > client against a MITM attack. The server has no way of knowing=20 > > whether this procedure has been implemented. So, the=20 > server does not=20 > > have all the protection it needs unless the TLS connection=20 > uses client=20 > > certificate authentication as well. > > > > Channel bindings would extend the level of assurance for the server. > > Alternatively, mutual authentication using certificates=20 > would resolve=20 > > the problem as well. > > > >>> I am starting to believe that the security considerations=20 > section of=20 > >>> 4930bis should note that enhanced security SHOULD be achieved=20 > >>> through channel bindings unless the application involves=20 > digitally=20 > >>> signed objects, > >> > >> I think another alternative can be to require mutual TLS=20 > >> authentication in a transport protocol mapping document. > > > > I think that would be a great solution, and it wouldn't=20 > need to tamper=20 > > with EPP or 4934bis. Any new EPP transport protocol=20 > mappings in the works? >=20 > rfc4930bis mentions a couple of others in sect 2.1 Transport=20 > Mapping Considerations >=20 > - The transport mapping MUST be onto a transport such as TCP > [RFC0793] or Stream Control Transmission Protocol=20 > (SCTP) [RFC4960] > that provides congestion avoidance that follows RFC 2914 > [RFC2914], or if it maps onto a protocol such as SMTP=20 > [RFC5321] or > Blocks Extensible Exchange Protocol (BEEP) [RFC3080], then the > performance issues need to take into account issues of=20 > overload, > server availability, and so forth. >=20 > I don't know how close to "in the works" those other=20 > suggested examples are. >=20 > Later it says that EPP can be carried over both=20 > connection-less and connection oriented transports. >=20 > And the security considerations section says that >=20 > EPP instances MUST be protected using > a transport mechanism or application protocol that provides > integrity, confidentiality, and mutual strong client-server > authentication. I'm not aware of any other IETF work to develop a standards-track = transport mapping for EPP. I have heard that other transports are being = used by ccTLDs (they often "roll their own" when it comes to how they = operate), but I don't have specific info on-hand. -Scott- From Nicolas.Williams@sun.com Thu Jul 16 10:59:45 2009 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 2C7873A6DBC; Thu, 16 Jul 2009 10:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.771 X-Spam-Level: X-Spam-Status: No, score=-5.771 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 esXSUoTacqiV; Thu, 16 Jul 2009 10:59:44 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 4F26B28C20A; Thu, 16 Jul 2009 10:59:38 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6GI08uA011138; Thu, 16 Jul 2009 18:00:08 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6GI074a008297; Thu, 16 Jul 2009 12:00:08 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n6GHnkuH009431; Thu, 16 Jul 2009 12:49:46 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6GHnj0h009430; Thu, 16 Jul 2009 12:49:45 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 16 Jul 2009 12:49:45 -0500 From: Nicolas Williams To: Sandra Murphy Message-ID: <20090716174945.GZ1274@Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "Hollenbeck, Scott" , "Polk, William T." , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] review of draft-hollenbeck-rfc4933bis-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: Thu, 16 Jul 2009 17:59:45 -0000 On Thu, Jul 16, 2009 at 12:01:09PM -0400, Sandra Murphy wrote: > rfc4930bis mentions a couple of others in sect 2.1 Transport Mapping > Considerations > > - The transport mapping MUST be onto a transport such as TCP > [RFC0793] or Stream Control Transmission Protocol (SCTP) [RFC4960] > that provides congestion avoidance that follows RFC 2914 > [RFC2914], or if it maps onto a protocol such as SMTP [RFC5321] or > Blocks Extensible Exchange Protocol (BEEP) [RFC3080], then the > performance issues need to take into account issues of overload, > server availability, and so forth. Incidentally, that text is not clear. How do "performance issues" take anything into account? Someone should be taking "issues of overload" (uncomfortable wording, that), and so on, but who? The implementor? Designers of new transport mappings? Who? > And the security considerations section says that > > EPP instances MUST be protected using > a transport mechanism or application protocol that provides > integrity, confidentiality, and mutual strong client-server > authentication. Which means TLS, DTLS (for connection-less transports), and maybe SASL (for BEEP? SMTP should use TLS). Note that "mutual strong client-server authentication" needs definition. In particular the adjective "mutual" as applied to "authentication" can mean one of two things: a) Each party's identities are authenticated to the other OR b) Authentication does not complete until the party being authenticated sends a message that proves it. For example, say you're using RSA key transport to encrypt a session key in the server's public key. The server's ability to decrypt the session key authenticates the server, but the client won't know that the server successfully decrypted the session key until the server sends back a message proving it knows the session key. TLS includes such a message. This meaning of "mutual authentication" comes from Kerberos, where it means that the server will send an AP-REP reply to a client's AP-REQ message. Here I suspect that EPP wants (b), since it will send a username and password over the secure channel to authenticate the user. If TLS were authenticating the user in the first place (as in (a)), then there would be no need for username and password authentication. The "strong" adjective also needs some explanation. I suspect that what's really desired here is that the _server_ be authenticated via certificates, while the client will be authenticated by sending a username and password over the secure channel. As opposed to both, the client and server being authenticated to the other via certificates. Perhaps this would be clearer text: EPP instances MUST be protected using a secure, end-to-end channel, at a suitable layer, that provides integrity and confidentiality protection, and strong server authentication. Authentication of the server to the client MUST be "mutual" in the Kerberos V5 [RFC4120] sense: the secure channel must require that the server send a message establishing that key exchange and authentication are complete and that the server has access to its authentication credentials and knows the session key. Nico -- From weiler+secdir@watson.org Fri Jul 17 18:55:44 2009 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 83C363A6782 for ; Fri, 17 Jul 2009 18:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q73YP67wn6Ta for ; Fri, 17 Jul 2009 18:55:43 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 662133A677D for ; Fri, 17 Jul 2009 18:55:41 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n6I1uEr3022123 for ; Fri, 17 Jul 2009 21:56:14 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n6I1uDgx022118 for ; Sat, 18 Jul 2009 02:56:14 +0100 (BST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 18 Jul 2009 02:56:13 +0100 (BST) 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.0.1 (fledge.watson.org [127.0.0.1]); Sat, 18 Jul 2009 02:56:14 +0100 (BST) Subject: [secdir] Assignments for July 24th 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, 18 Jul 2009 01:55:44 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2009-08-13 Dave Cridland T draft-ietf-behave-nat-behavior-discovery-07 Tobias Gondrom T draft-ietf-nea-pa-tnc-04 Phillip Hallam-Baker T draft-ietf-nea-pb-tnc-04 Chris Newman T draft-ietf-mpls-tp-requirements-09 Radia Perlman T draft-ietf-pwe3-mpls-transport-04 Stefan Santesson T draft-freed-sieve-in-xml-05 Last calls and special requests: Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 Steve Hanna draft-peterson-rai-rfc3427bis-02 Steve Hanna draft-ietf-netconf-partial-lock-09 Love Hornquist-Astrand draft-ietf-ipfix-mib-07 Love Hornquist-Astrand draft-ietf-opsawg-smi-datatypes-in-xsd-05 Charlie Kaufman draft-ietf-ipsecme-ikev2-redirect-11 Julien Laganier draft-ietf-sip-certs-08 Barry Leiba draft-ietf-simple-interdomain-scaling-analysis-07 Catherine Meadows draft-ietf-speechsc-mrcpv2-19 Sandy Murphy draft-ietf-speermint-voip-consolidated-usecases-13 Vidya Narayanan draft-ietf-sip-saml-06 Vidya Narayanan draft-ietf-enum-3761bis-04 Vidya Narayanan draft-ietf-opsawg-syslog-snmp-03 Magnus Nystrom draft-ietf-opsawg-syslog-msg-mib-04 Hilarie Orman draft-ietf-ospf-hmac-sha-05 Eric Rescorla draft-ietf-enum-iax-05 Eric Rescorla draft-ietf-simple-xcap-diff-13 Joe Salowey draft-ietf-geopriv-lis-discovery-11 Joe Salowey draft-ietf-sipping-service-identification-03 Juergen Schoenwaelder draft-harkins-emu-eap-pwd-04 Yaron Sheffer draft-ietf-msec-tesla-for-alc-norm-07 Hannes Tschofenig draft-ietf-pce-monitoring-05 Hannes Tschofenig draft-ietf-pkix-ta-format-03 Sean Turner draft-nottingham-http-link-header-06 Carl Wallace draft-solinas-rfc4753bis-00 Sam Weiler draft-chown-v6ops-rogue-ra-03 Sam Weiler draft-seokung-msec-mikey-seed-02 Nico Williams draft-ietf-v6ops-ra-guard-03 Larry Zhu draft-thaler-v6ops-teredo-extensions-03 Larry Zhu draft-ietf-ecrit-location-hiding-req-02 From barryleiba@gmail.com Sat Jul 18 18:51:29 2009 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 1EB803A6B9F; Sat, 18 Jul 2009 18:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 R7AenZ7K9kcD; Sat, 18 Jul 2009 18:51:28 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id F3BAB3A68A3; Sat, 18 Jul 2009 18:51:27 -0700 (PDT) Received: by ewy26 with SMTP id 26so1630331ewy.37 for ; Sat, 18 Jul 2009 18:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qz0c5jBcZdgO3+PRzXZLVpft13Yk9F+upjs3+81eAjg=; b=TF0x4xmVYwZYFAWc1S6A6LlH5Zn2JgmwZY77U/CpuJQKPuK6KRI0vxJWBzaOW8Tfo+ 8XKSgLXd4sJ5nJHB+eT+W14y+6DhguBkANV/Mh0As3S/z5Z/dg6onqn5RBoUyPOn4CRx pQqG4zj3Jn2sxBpzl1Y4H86TvD3pew17YDanw= 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:content-transfer-encoding; b=ibVGCWnqBuW1P94zFs59BrohRo80s7UDblnuNNlmt1/Vd12NjCXtKaPzZU/uHDcIKF moQ4bkNJq4V0JCPgQ4mhqMzQCdcNlgMc5i/9yoWcXaHr/rLnAEkyAirMvKY9Jfd40uUr pkoPnxU3EurpARDIeM7tZNoL2cIZ8IJKMLVNA= MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.210.19.7 with SMTP id 7mr1799764ebs.7.1247968284748; Sat, 18 Jul 2009 18:51:24 -0700 (PDT) Date: Sat, 18 Jul 2009 21:51:24 -0400 X-Google-Sender-Auth: a927b13c7008d616 Message-ID: <9abf48a60907181851v242e094erc77336e3a6f71cca@mail.gmail.com> From: Barry Leiba To: draft-ietf-simple-interdomain-scaling-analysis@tools.ietf.org, simple-chairs@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-simple-interdomain-scaling-analysis 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, 19 Jul 2009 01:51: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. There are no security issues with this document. It's a survey and analysis of current implementation, and correctly notes in its Security Considerations section that security issues will certainly come up in the subsequent work that follows up on the results and analysis presented here. I reviewed the -06 version, and found that its English was *far* worse than usual for documents sent to last call -- I wonder how it got that far in that state. As I decided how to handle that with last-call comments, an -07 version was put out. That version fixes many of the problems, and makes the document tolerable... though it still needs quite a bit of editing. It might need more editing than is reasonable to pass last call and IESG, and expect the RFC editor to handle. If the authors would like, I'm willing to take an editing pass through the document. If they want me to do that, they should send me, privately, the XML source, and I'll have a go. Barry -- Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ From stefan@aaa-sec.com Sun Jul 19 05:26:14 2009 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 4DBFB3A6C40 for ; Sun, 19 Jul 2009 05:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.649 X-Spam-Level: * X-Spam-Status: No, score=1.649 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_50=0.001, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 XAzpH+M+38CX for ; Sun, 19 Jul 2009 05:26:14 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id A95F03A6986 for ; Sun, 19 Jul 2009 05:26:12 -0700 (PDT) Received: (qmail 76762 invoked from network); 19 Jul 2009 12:19:33 -0000 Received: from s34.loopia.se (HELO s29.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 19 Jul 2009 12:19:33 -0000 Received: (qmail 73549 invoked from network); 19 Jul 2009 12:19:29 -0000 Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.9]) (stefan@fiddler.nu@[213.64.142.97]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 19 Jul 2009 12:19:29 -0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Sun, 19 Jul 2009 14:19:27 +0200 From: Stefan Santesson To: , Message-ID: Thread-Topic: Secdir review of draft-freed-sieve-in-xml-05 Thread-Index: AcoIayimrtyG5fR61ku8pvUcn96RSg== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3330857969_13076935" Cc: cyrus@daboo.name, Srinivas.Sv@Sun.COM, aaron@serendipity.cx, ned.freed@mrochek.com, lisa.dusseault@gmail.com Subject: [secdir] Secdir review of draft-freed-sieve-in-xml-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: Sun, 19 Jul 2009 12:26:14 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3330857969_13076935 Content-type: text/plain; charset="ISO-8859-1" 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. This document describes a way to represent Sieve email filtering language scripts in XML. Representing sieves in XML is intended not as an alternate storage format for Sieve but rather as a means to facilitate manipulation o= f scripts using XML tools. As such , this draft does not define a new protocol, but rather a way to wrap and handle an existing protocol. As this draft concludes, the security considerations of this draft equals reasonably to those of the Sieve protocol and those of using XML to represent information. Proper references to relevant security considerations seems to be present in this document an= d I can=B9t find any additional issues that I think the Security Area Directors should be aware of. Stefan Santesson AAA-sec.com --B_3330857969_13076935 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Secdir review of draft-freed-sieve-in-xml-05 I have reviewed this document as part of the security directorate's ongoin= g effort to review all IETF documents being processed by the IESG.  The= se comments were written primarily for the benefit of the security area dire= ctors.  Document editors and WG chairs should treat these comments just= like any other last call comments.

This document describes a way to represent Sieve email filtering language s= cripts in XML.  Representing sieves in XML is intended not as an altern= ate storage format for Sieve but rather as a means to facilitate manipulatio= n of scripts using XML tools.

As such , this draft does not define a new protocol, but rather a way to wr= ap and handle an existing protocol. As this draft concludes, the security co= nsiderations of this draft equals reasonably to those of the Sieve protocol = and those of using XML to represent information. Proper references to releva= nt security considerations seems to be present in this document and I can= 217;t find any additional issues that I think the Security Area Directors sh= ould be aware of.

Stefan Santesson
AAA-sec.com



 --B_3330857969_13076935-- From AVSHALOM@il.ibm.com Sun Jul 19 11:35:45 2009 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 648433A6C55; Sun, 19 Jul 2009 11:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 UEcFipm2hWgy; Sun, 19 Jul 2009 11:35:44 -0700 (PDT) Received: from mtagate1.de.ibm.com (mtagate1.de.ibm.com [195.212.17.161]) by core3.amsl.com (Postfix) with ESMTP id E92C03A6C12; Sun, 19 Jul 2009 11:35:40 -0700 (PDT) Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81]) by mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id n6JIYw4I015194; Sun, 19 Jul 2009 18:34:58 GMT Received: from d12av05.megacenter.de.ibm.com (d12av05.megacenter.de.ibm.com [9.149.165.216]) by d12nrmr1707.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n6JIYqOq1282134; Sun, 19 Jul 2009 20:34:58 +0200 Received: from d12av05.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av05.megacenter.de.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n6JIYpFk021327; Sun, 19 Jul 2009 20:34:52 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av05.megacenter.de.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n6JIYpCP021324; Sun, 19 Jul 2009 20:34:51 +0200 In-Reply-To: <9abf48a60907181851v242e094erc77336e3a6f71cca@mail.gmail.com> References: <9abf48a60907181851v242e094erc77336e3a6f71cca@mail.gmail.com> To: Barry Leiba MIME-Version: 1.0 X-KeepSent: 62258324:4441D926-C22575F8:00659969; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Avshalom Houri Message-ID: Date: Sun, 19 Jul 2009 21:34:50 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 19/07/2009 21:34:51, Serialize complete at 19/07/2009 21:34:51 Content-Type: multipart/alternative; boundary="=_alternative 0065B84CC22575F8_=" X-Mailman-Approved-At: Mon, 20 Jul 2009 00:38:47 -0700 Cc: simple-chairs@tools.ietf.org, secdir@ietf.org, draft-ietf-simple-interdomain-scaling-analysis@tools.ietf.org, barryleiba@gmail.com, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-simple-interdomain-scaling-analysis 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, 19 Jul 2009 18:35:45 -0000 This is a multipart message in MIME format. --=_alternative 0065B84CC22575F8_= Content-Type: text/plain; charset="US-ASCII" Hi Barry, Thanks a lot for the review. I will send you the XML for an editing pass. --Avshalom From: Barry Leiba To: draft-ietf-simple-interdomain-scaling-analysis@tools.ietf.org, simple-chairs@tools.ietf.org Cc: iesg@ietf.org, secdir@ietf.org Date: 19/07/2009 06:10 PM Subject: secdir review of draft-ietf-simple-interdomain-scaling-analysis Sent by: barryleiba@gmail.com 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 are no security issues with this document. It's a survey and analysis of current implementation, and correctly notes in its Security Considerations section that security issues will certainly come up in the subsequent work that follows up on the results and analysis presented here. I reviewed the -06 version, and found that its English was *far* worse than usual for documents sent to last call -- I wonder how it got that far in that state. As I decided how to handle that with last-call comments, an -07 version was put out. That version fixes many of the problems, and makes the document tolerable... though it still needs quite a bit of editing. It might need more editing than is reasonable to pass last call and IESG, and expect the RFC editor to handle. If the authors would like, I'm willing to take an editing pass through the document. If they want me to do that, they should send me, privately, the XML source, and I'll have a go. Barry -- Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ --=_alternative 0065B84CC22575F8_= Content-Type: text/html; charset="US-ASCII" Hi Barry,

Thanks a lot for the review. I will send you the XML for an editing pass.

--Avshalom


From: Barry Leiba <barryleiba@computer.org>
To: draft-ietf-simple-interdomain-scaling-analysis@tools.ietf.org, simple-chairs@tools.ietf.org
Cc: iesg@ietf.org, secdir@ietf.org
Date: 19/07/2009 06:10 PM
Subject: secdir review of draft-ietf-simple-interdomain-scaling-analysis
Sent by: barryleiba@gmail.com




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 are no security issues with this document.  It's a survey and
analysis of current implementation, and correctly notes in its
Security Considerations section that security issues will certainly
come up in the subsequent work that follows up on the results and
analysis presented here.

I reviewed the -06 version, and found that its English was *far* worse
than usual for documents sent to last call -- I wonder how it got that
far in that state.  As I decided how to handle that with last-call
comments, an -07 version was put out.  That version fixes many of the
problems, and makes the document tolerable... though it still needs
quite a bit of editing.  It might need more editing than is reasonable
to pass last call and IESG, and expect the RFC editor to handle.

If the authors would like, I'm willing to take an editing pass through
the document.  If they want me to do that, they should send me,
privately, the XML source, and I'll have a go.

Barry
--
Barry Leiba  (barryleiba@computer.org)
http://internetmessagingtechnology.org/
--=_alternative 0065B84CC22575F8_=-- From weiler@watson.org Mon Jul 20 07:51:07 2009 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 EDCB13A6D75; Mon, 20 Jul 2009 07:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJyVOTDbc41P; Mon, 20 Jul 2009 07:51:07 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 25C243A69F8; Mon, 20 Jul 2009 07:51:06 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n6KEoxDU035909; Mon, 20 Jul 2009 10:50:59 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n6KEoxlA035906; Mon, 20 Jul 2009 15:50:59 +0100 (BST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 20 Jul 2009 15:50:59 +0100 (BST) From: Samuel Weiler To: draft-seokung-msec-mikey-seed@tools.ietf.org, secdir@ietf.org, iesg@ietf.org, bew@cisco.com 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.0.1 (fledge.watson.org [127.0.0.1]); Mon, 20 Jul 2009 15:50:59 +0100 (BST) Subject: [secdir] secdir review of draft-seokung-msec-mikey-seed-02 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, 20 Jul 2009 14:51:08 -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 see no problems with this draft -- it adds a few entries to IANA registries that have an assignment metric of IETF Consensus. It has a dependency on a draft that was on telechat in June; all Discuss positions on that doc have been cleared. The only questions I might ask are really out of scope: 1) does MIKEY deal with algoritm agility gracefully (e.g. is it subject to downgrade or DOS attacks)? But that's out of scope for this review and this document. And... 2) for the fields being changed (and others), 3830 says "a one byte length is enough" and establishes an IANA registry for the values 0-255, but those fields appear to be encoded on the wire using a TLV scheme. I have fear of future interop issues if some implementations hardcode the one byte length, and the text in 3830 makes it pretty clear that hardcoding would be justified. But, again, that's beyond the scope of this draft to fix. -- Sam From magnus@rsa.com Mon Jul 20 08:30:03 2009 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 9BA0B28C18F; Mon, 20 Jul 2009 08:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 cmfiHdRayGu9; Mon, 20 Jul 2009 08:30:01 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 9C4AC3A6C9B; Mon, 20 Jul 2009 08:29:27 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id n6KFTOGh000795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2009 11:29:24 -0400 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si04.isus.emc.com (Tablus Interceptor); Mon, 20 Jul 2009 11:29:17 -0400 Received: from corpussmtp2.corp.emc.com (corpussmtp2.corp.emc.com [128.221.14.146]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n6KFTClT022690; Mon, 20 Jul 2009 11:29:16 -0400 Received: from CORPUSMX50B.corp.emc.com ([128.221.62.39]) by corpussmtp2.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 11:29:14 -0400 Received: from W-JNISBETTEST-1 ([10.100.100.103]) by CORPUSMX50B.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 11:29:14 -0400 Date: Mon, 20 Jul 2009 11:29:35 -0400 (Eastern Daylight Time) From: =?iso-8859-1?Q?Magnus_Nystr=F6m?= To: iesg@ietf.org, secdir@ietf.org, secdir-secretary@mit.edu, j.schoenwalder@jacobs-university.de, alex@cisco.com, akarmaka@cisco.com, sob@harvard.edu, ted.a.seely@sprint.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 20 Jul 2009 15:29:14.0272 (UTC) FILETIME=[D6680200:01CA094E] X-EMM-EM: Active Subject: [secdir] SecDir review of draft-ietf-opsawg-syslog-msg-mib-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: Mon, 20 Jul 2009 15:30:03 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Background ---------- This document defines a MIB module for use when mapping SYSLOG messages to SNMP notifications. Comments -------- - In the SYSLOG-MSG-MIB module, the syslogMsgSDTable is defined with the syntax SEQUENCE OF SyslogMsgSDEntry Would it make sense to restrict this with an upper (and perhaps lower) bound to reduce the risk of either non-interop or potential attacks? E.g. like SEQUENCE SIZE (1..) OF SyslogMsgSDEntry where is replaced with something reasonable? - (Editorial) In the Security Considerations section, there is a paragraph recommending against deployment of earlier versions of SNMP. For clarity and correctness ("NOT RECOMMENDED" is not a key word) I suggest this paragraph is rewritten to (several changes in the below): Further, SNMP versions prior to SNMPv3 SHOULD NOT be deployed. Instead, SNMPv3 with enabled cryptographic security SHOULD be deployed. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that indeed have legitimate rights to GET or SET (change/create/delete) them. -- Magnus From dromasca@avaya.com Mon Jul 20 08:39:32 2009 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 3B1983A6CB4; Mon, 20 Jul 2009 08:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, MIME_8BIT_HEADER=0.3] 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 UGF4h5A6EiZa; Mon, 20 Jul 2009 08:39:31 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 2C1433A6D73; Mon, 20 Jul 2009 08:39:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,235,1246852800"; d="scan'208";a="167674943" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 20 Jul 2009 11:39:18 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 20 Jul 2009 11:39:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jul 2009 17:38:59 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SecDir review of draft-ietf-opsawg-syslog-msg-mib-04 thread-index: AcoJTwcx+YlkteSeTHmF8EELzA4AZwAAF71w References: From: "Romascanu, Dan (Dan)" To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= , , , , , , , , Subject: Re: [secdir] SecDir review of draft-ietf-opsawg-syslog-msg-mib-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: Mon, 20 Jul 2009 15:39:32 -0000 Hi Magnus, Thank you for the review.=20 I will let the authors respond on the rest, but I have one comment about = the following:=20 =20 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > Behalf Of Magnus Nystr?m >=20 > - (Editorial) In the Security Considerations section, there=20 > is a paragraph > recommending against deployment of earlier versions of SNMP. For > clarity and correctness ("NOT RECOMMENDED" is not a key=20 > word) I suggest > this paragraph is rewritten to (several changes in the below): Actually RFC 2119 says:=20 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. NOT RECOMMENDED is thus accepted as a synonim to SHOULD NOT if the = syntax of the phrase demands it.=20 The current boilerplate for Security Considerations sections described = at http://www.ops.ietf.org/mib-security.html was carefully crafted by = the Security AD's and OPS AD's a few years ago, and is used since in all = RFCs that define MIB modules. I would not recommend using a different = wording, unless there is a good reason and the current AD's agree on the = change.=20 Thanks and Regards, Dan >=20 > Further, SNMP versions prior to SNMPv3 SHOULD NOT be deployed. > Instead, SNMPv3 with enabled cryptographic security=20 > SHOULD be deployed. > It is then a customer/operator responsibility to ensure=20 > that the SNMP > entity giving access to an instance of this MIB module is properly > configured to give access to the objects only to those principals > (users) that indeed have legitimate rights to GET or SET > (change/create/delete) them. >=20 > -- Magnus >=20 From hilarie@purplestreak.com Mon Jul 20 13:00:00 2009 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 05E1F3A6DB1; Mon, 20 Jul 2009 13:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGlSXYJBG1KB; Mon, 20 Jul 2009 12:59:53 -0700 (PDT) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by core3.amsl.com (Postfix) with ESMTP id 1BB363A6A22; Mon, 20 Jul 2009 12:59:53 -0700 (PDT) Received: from mx02.mta.xmission.com ([166.70.13.212]) by out01.mta.xmission.com with esmtp (Exim 4.62) (envelope-from ) id 1MSz1P-0005S0-TF; Mon, 20 Jul 2009 13:59:39 -0600 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=localhost.localdomain) by mx02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MSz17-00083N-Q1; Mon, 20 Jul 2009 13:59:22 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.12.10) with ESMTP id n6KJvkko016676; Mon, 20 Jul 2009 13:57:46 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id n6KJvjQv016672; Mon, 20 Jul 2009 13:57:45 -0600 Date: Mon, 20 Jul 2009 13:57:45 -0600 Message-Id: <200907201957.n6KJvjQv016672@localhost.localdomain> X-Authentication-Warning: localhost.localdomain: ho set sender to hilarie using -f From: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx02.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-DomainKey: sender_domain=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=no signature X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Thu, 25 Oct 2007 00:26:12 +0000) X-SA-Exim-Scanned: Yes (on mx02.mta.xmission.com) Cc: rja@extremenetworks.com, mjbarnes@cisco.com, mfanto@aegisdatasecurity.com, tony.li@tony.li, acee@redback.com, manav@alcatel-lucent.com, akr@cisco.com, riw@cisco.com Subject: [secdir] Review of draft-ietf-ospf-hmac-sha-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 20:00:00 -0000 Review of draft-ietf-ospf-hmac-sha-05.txt Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. OSPFv2 is a routing protocol, and its specification includes a description of using a cryptographic key with a hash function for the purpose of message authentication. This draft specifies the use of different hash algorithms and a different way of combining the key with the data in order to form the authentication value sent with the messages. "Introduction The creation of this addition to OSPFv2 was driven by operator requests that they be able to use the NIST SHS family of algorithms in the NIST HMAC mode, instead of being forced to use the Keyed-MD5 algorithm and mode with OSPFv2 Cryptographic Authentication." A reference (minutes of a NANOG meeting?) would be helpful. Section 3 gives SHA-1 a "should". Why? I can see a "should" on MD5 for backward compatibility, but SHA-1 should have died aborning. Section 3.1 says that the combining method is described in section 3.2, but 3.3 is the actual location. Section 3.2, in the paragraph about authentication keys, refers to "K in section 3.2 above". This makes no sense; the reference should probably be deleted. In section 3.3: "K is the selected OSPFv2 key". The statement should use the terminology of section 3.2 and say "K is the authentication key for the OSPFv2 security association". Section 3.3: "B is the block size of H, measured in octets, rather than bits". Two problems: 1. the indentation format is irregular, 2. nothing has suggested measuring in bits, so the "rather than" is gratuitous. The same holds for the comment regarding the length of L. Section 4, Security Considerations. The second paragraph, while correct in the sense that it says nothing wrong, does not do a good job of explaining the numerous "concerns". There should be a plausible argument about the value of switching to the SHA family, and a little more about the value of HMAC over prepended key. Is there a reference for the US govmt's preference for the SHA family? I don't think the section does justice to the problem of replay. It's my (perhaps flawed) understanding that RFC2838 strongly recommends using a random initial sequence number, so the comments about always starting from zero seem wrong (unless there is some reason to believe that implementations do not adhere to the RFC2838 guidance). Further, a passive observer of two sessions can insert replay packets, with appropriate sequence numbers, at any time, because the authentication key is static. RFC2838 seems to mandate a tear-down on any sequence number mismatch. Altogether, this seems more serious to me than the MD5 collisions. I think that a stronger statement about IPsec (I think that is what is meant by the penultimate paragraph in section 4; there is no reference) could be made. I'm not sure that "full digital signatures" would be a stronger authentication method. The number of authors exceeds the RFC editor's guidelines. I approve. From ietfdbh@comcast.net Mon Jul 20 13:40:31 2009 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 85CF03A6AF8 for ; Mon, 20 Jul 2009 13:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 WIVrM6AsNX5p for ; Mon, 20 Jul 2009 13:40:30 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 732AA3A6802 for ; Mon, 20 Jul 2009 13:40:29 -0700 (PDT) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA08.westchester.pa.mail.comcast.net with comcast id JKyh1c0040SCNGk58LdrUa; Mon, 20 Jul 2009 20:37:51 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA09.westchester.pa.mail.comcast.net with comcast id JLdq1c0070UQ6dC3VLdqko; Mon, 20 Jul 2009 20:37:51 +0000 From: "David Harrington" To: =?iso-8859-1?Q?'Magnus_Nystr=F6m'?= , , , , , , , , References: Date: Mon, 20 Jul 2009 16:37:49 -0400 Message-ID: <1c7b01ca0979$f2c0b9d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: Thread-Index: AcoJTwVURrAVHFgARtaldH15otnGHAAKrloA Subject: Re: [secdir] SecDir review of draft-ietf-opsawg-syslog-msg-mib-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: Mon, 20 Jul 2009 20:40:31 -0000 Hi, MIBs arewritten using SMIv2. I don't believe SMIv2 supports the range on a SEQUENCE. As Dan pointed out, the recommendation of SNMP versions is boilerplate that was worked out between Security and OPS ADs. dbh=20 > -----Original Message----- > From: secdir-bounces@ietf.org=20 > [mailto:secdir-bounces@ietf.org] On Behalf Of Magnus Nystr=F6m > Sent: Monday, July 20, 2009 11:30 AM > To: iesg@ietf.org; secdir@ietf.org; secdir-secretary@mit.edu;=20 > j.schoenwalder@jacobs-university.de; alex@cisco.com;=20 > akarmaka@cisco.com; sob@harvard.edu; ted.a.seely@sprint.com > Subject: [secdir] SecDir review of draft-ietf-opsawg-syslog-msg-mib-04 >=20 > I have reviewed this document as part of the security=20 > directorate's ongoing=20 > effort to review all IETF documents being processed by the=20 > IESG. These=20 > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these=20 > comments just=20 > like any other last call comments. >=20 > Background > ---------- > This document defines a MIB module for use when mapping=20 > SYSLOG messages to=20 > SNMP notifications. >=20 > Comments > -------- >=20 > - In the SYSLOG-MSG-MIB module, the syslogMsgSDTable is=20 > defined with the > syntax >=20 > SEQUENCE OF SyslogMsgSDEntry >=20 > Would it make sense to restrict this with an upper (and=20 > perhaps lower) > bound to reduce the risk of either non-interop or=20 > potential attacks? > E.g. like >=20 > SEQUENCE SIZE (1..) OF SyslogMsgSDEntry >=20 > where is replaced with something reasonable? >=20 > - (Editorial) In the Security Considerations section, there=20 > is a paragraph > recommending against deployment of earlier versions of SNMP. For > clarity and correctness ("NOT RECOMMENDED" is not a key=20 > word) I suggest > this paragraph is rewritten to (several changes in the below): >=20 > Further, SNMP versions prior to SNMPv3 SHOULD NOT be deployed. > Instead, SNMPv3 with enabled cryptographic security=20 > SHOULD be deployed. > It is then a customer/operator responsibility to ensure=20 > that the SNMP > entity giving access to an instance of this MIB module is properly > configured to give access to the objects only to those principals > (users) that indeed have legitimate rights to GET or SET > (change/create/delete) them. >=20 > -- Magnus > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir >=20 From Pasi.Eronen@nokia.com Tue Jul 21 05:33:02 2009 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 156E13A6897 for ; Tue, 21 Jul 2009 05:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.752 X-Spam-Level: X-Spam-Status: No, score=-5.752 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 yrdJZcqG24MF for ; Tue, 21 Jul 2009 05:33:01 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 5C4FF3A67A6 for ; Tue, 21 Jul 2009 05:33:01 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6LCVpds026457 for ; Tue, 21 Jul 2009 07:32:01 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 15:31:57 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 15:31:56 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 21 Jul 2009 14:31:56 +0200 From: To: Date: Tue, 21 Jul 2009 14:31:55 +0200 Thread-Topic: Security Directorate lunch on Tuesday Thread-Index: AcoJ/zvRkb57tK9tRU+qOY47pZWQOQ== Message-ID: <808FD6E27AD4884E94820BC333B2DB773A713C6714@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Jul 2009 12:31:57.0091 (UTC) FILETIME=[3C90BF30:01CA09FF] X-Nokia-AV: Clean Subject: [secdir] Security Directorate lunch on Tuesday 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, 21 Jul 2009 12:33:02 -0000 We'll have the Security Directorate lunch on Tuesday as before; the room is 202. As usual, bring your own lunch and we will=20 discuss what's going on in the area and around the IETF. (And yes, we're aware that ISOC is (again) organizing a panel overlapping with our lunch...) Best regards, Pasi & Tim From phoffman@imc.org Tue Jul 21 09:35:06 2009 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 9E74A3A684F for ; Tue, 21 Jul 2009 09:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaAwe-o3YFnH for ; Tue, 21 Jul 2009 09:35:06 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 90F643A6831 for ; Tue, 21 Jul 2009 09:35:05 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6LGZ2ol051110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jul 2009 09:35:03 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A713C6714@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB773A713C6714@NOK-EUMSG-01.mgdnok.nokia.com> Date: Tue, 21 Jul 2009 09:35:01 -0700 To: , From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [secdir] Security Directorate lunch on Tuesday 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, 21 Jul 2009 16:35:06 -0000 At 2:31 PM +0200 7/21/09, wrote: >We'll have the Security Directorate lunch on Tuesday as before; >the room is 202. As usual, bring your own lunch and we will >discuss what's going on in the area and around the IETF. Knowing where sandwich places are ahead of time would help us start reasonably on time. >(And yes, we're aware that ISOC is (again) organizing a panel >overlapping with our lunch...) I suspect that will happen consistently in the future. I sure hope it does. The amount of publicity value from the one in San Francisco was *huge*, and this one should be no different. From jhutz@cmu.edu Tue Jul 21 10:49:40 2009 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 764563A6996 for ; Tue, 21 Jul 2009 10:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QD65fzXfarwf for ; Tue, 21 Jul 2009 10:49:39 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id ABA2B3A67D9 for ; Tue, 21 Jul 2009 10:49:39 -0700 (PDT) Received: from [10.0.0.4] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n6LHnOeP028790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jul 2009 13:49:30 -0400 (EDT) Date: Tue, 21 Jul 2009 13:49:23 -0400 From: Jeffrey Hutzelman To: Paul Hoffman , Pasi.Eronen@nokia.com, secdir@ietf.org Message-ID: <96FFA21F50F96E866F0FB2D5@atlantis.pc.cs.cmu.edu> In-Reply-To: <31570_1248194109_n6LGZ8g0005271_p06240892c68b9e5cdb51@[10.20.30.158]> References: <808FD6E27AD4884E94820BC333B2DB773A713C6714@NOK-EUMSG-01.mgdnok.nokia.com> <31570_1248194109_n6LGZ8g0005271_p06240892c68b9e5cdb51@[10.20.30.158]> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Subject: Re: [secdir] Security Directorate lunch on Tuesday 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, 21 Jul 2009 17:49:40 -0000 --On Tuesday, July 21, 2009 09:35:01 AM -0700 Paul Hoffman wrote: >> (And yes, we're aware that ISOC is (again) organizing a panel >> overlapping with our lunch...) > > I suspect that will happen consistently in the future. I sure hope it > does. The amount of publicity value from the one in San Francisco was > *huge*, and this one should be no different. Surely we can hope that ISOC continues to hold such panels while also hoping they pick someone else to overlap with? From phoffman@imc.org Tue Jul 21 11:42:10 2009 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 4BC633A69C4 for ; Tue, 21 Jul 2009 11:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnAB6SGBCa+1 for ; Tue, 21 Jul 2009 11:42:09 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C2B623A69A7 for ; Tue, 21 Jul 2009 11:42:08 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6LIg6Yd060862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Jul 2009 11:42:07 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <96FFA21F50F96E866F0FB2D5@atlantis.pc.cs.cmu.edu> References: <808FD6E27AD4884E94820BC333B2DB773A713C6714@NOK-EUMSG-01.mgdnok.nokia.com> <31570_1248194109_n6LGZ8g0005271_p06240892c68b9e5cdb51@[10.20.30.158]> <96FFA21F50F96E866F0FB2D5@atlantis.pc.cs.cmu.edu> Date: Tue, 21 Jul 2009 11:42:05 -0700 To: secdir@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [secdir] Security Directorate lunch on Tuesday 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, 21 Jul 2009 18:42:10 -0000 At 1:49 PM -0400 7/21/09, Jeffrey Hutzelman wrote: >--On Tuesday, July 21, 2009 09:35:01 AM -0700 Paul Hoffman wrote: > >>>(And yes, we're aware that ISOC is (again) organizing a panel >>>overlapping with our lunch...) >> >>I suspect that will happen consistently in the future. I sure hope it >>does. The amount of publicity value from the one in San Francisco was >>*huge*, and this one should be no different. > >Surely we can hope that ISOC continues to hold such panels while also hoping they pick someone else to overlap with? You may be overestimating the importance of the secdir lunch in the larger scheme of things. The kind of publicity that ISOC is garnering for important IETF protocols vastly outweighs the value of our discussions over sandwiches. For example, look at how much press about IPv6 appeared the day after the ISOC presentation in San Francisco. If need be, we can move our lunch to a different day. OTOH, we are not the target audience for the presentations, so I don't see a reason to do so. From secdir-bounces@mit.edu Tue Jul 21 10:40:11 2009 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 903D228C2EB for ; Tue, 21 Jul 2009 10:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.469 X-Spam-Level: X-Spam-Status: No, score=-105.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 3gT2PWPWf-QW for ; Tue, 21 Jul 2009 10:40:10 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id F3D2728C1FC for ; Tue, 21 Jul 2009 10:40:09 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n6LHdkvY006912 for ; Tue, 21 Jul 2009 13:39:46 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n6LHdjM3006894 for ; Tue, 21 Jul 2009 13:39:45 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n6LHdYpK010446 for ; Tue, 21 Jul 2009 13:39:34 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 0FCF218CBECB for ; Tue, 21 Jul 2009 13:31:05 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id IsmHqcp2WEzhx86m for ; Tue, 21 Jul 2009 13:31:05 -0400 (EDT) Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org; Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93A2828C3D8; Tue, 21 Jul 2009 10:30:07 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 203BC28C3BB; Tue, 21 Jul 2009 10:30:01 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090721173002.203BC28C3BB@core3.amsl.com> Date: Tue, 21 Jul 2009 10:30:02 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Tue, 21 Jul 2009 12:14:38 -0700 Subject: [secdir] [New-work] WG Review: Recharter of Mobility for IPv4 (mip4) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 17:40:11 -0000 A modified charter has been submitted for the Mobility for IPv4 (mip4) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by July 28, 2009. Recharter of Mobility for IPv4 (mip4) --------------------------------------------------- Current Status: Active Working Group Last Modified: 2009-07-07 Additional information is available at http://tools.ietf.org/wg/mip4 Chair(s): Henrik Levkowetz Pete McCann Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: mip4@ietf.org To Subscribe: mip4-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/mip4/index.html Description of Working Group: IP mobility support for IPv4 nodes (hosts and routers) is specified in RFC3344. RFC 3344 mobility allows a node to continue using its "permanent" home address as it moves around the Internet. The Mobile IP protocols support transparency above the IP layer, including maintenance of active TCP connections and UDP port bindings. Besides the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns such as optimization, security, extensions, AAA support, and deployment issues. MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 networks). The scope of the deployment is on a fairly large scale and accordingly, the MIP4 WG will focus on deployment issues and on addressing known deficiencies and shortcomings in the protocol that have come up as a result of deployment experience. Specifically, the working group will complete the work items to facilitate interactions with AAA environments, interactions with enterprise environments when MIPv4 is used therein, and updating existing protocol specifications in accordance with deployment needs and advancing those protocols that are on the standards track. Work expected to be done by the MIP4 WG as proposed by this charter is as follows: 1. MIPv4 has been a Proposed Standard for several years. It has been adopted by other standard development organizations and has been deployed commercially. One of the next steps for the WG is to advance the protocol to draft standard status. As part of advancing base Mobile IP specs to Draft Standard, the MIPv4 NAI RFC (2794) will be revised to reflect implementation experience. 2. The WG will complete the MIB specifications for the Mobile IPv4 base protocol and the UDP tunneling extension. 3. A requirements document for RADIUS MIP4 support was previously completed and published as RFC 5030. Based on these requirements, the WG will complete the specification of MIPv4 RADIUS attributes, solicit feedback from the RADEXT WG, adjust, and submit this for publication. Note that the work may require extensions to the RADIUS attribute space which will be handled outside the MIP4 WG. 4. Like fixed nodes, mobile nodes sometimes need to be dynamically configured with parameters such as DNS server IP addresses. Previous work in the WG proposed to put a generic container for host configuration options into Mobile IPv4 signaling. However, it may be easier for mobile nodes to implement the already existing DHCP specification, and to run DHCP over the tunnel established with an initial registration. The WG will take on a draft describing any modifications to Mobile IPv4 that may be needed to facilitate this mode of operation, and submit for publication as a Proposed Standard or Best Current Practice as appropriate. 5. The proliferation of devices with multiple interface technologies and the desire to use each interface for the type of traffic most appropriate to it (even simultaneously with other interfaces active at the same time) has led to requirements for supporting multiple simultaneous tunnels between the Home Agent and Mobile Node. The WG will adopt and take to publication as Proposed Standard one draft that describes how to manage such tunnels and how to direct traffic to use the appropriate tunnel when multiple choices are available. 6. The WG has published a basic Network Mobility (NEMO) specification as RFC 5177. The WG has taken up an extension to NEMO that will allow for dynamic home network prefix allocation to a moving network. The WG will finish work on this draft and publish as a Proposed Standard. 7. Route optimization has been the focus of a large amount of effort in the Mobile IPv6 WG. For Mobile IPv4, however, the usage case is less clear due to a variety of factors, including the inability to modify already deployed correspondent nodes. Recently a specific use case has been proposed involving route optimization for a more closed network where modifications are made to site routers and a centralized Home Agent to enable offloading of traffic from the Home Agent. The WG will take on and publish a draft on this topic as a Proposed Standard RFC. 8. The use of GRE tunneling with Mobile IPv4 enables support for multiple overlapping private address spaces within the same mobility agent. However, to distinguish flows from two different mobile nodes that happen to share the same (private) IP address, the GRE Key field needs to be populated with a unique identifier that will enable the mobility agent to demultiplex the flows. The value used for the Key needs to be signaled at the time of tunnel establishment, which means a new Mobile IPv4 extension is needed for this purpose. The WG will take on an publish a draft on this topic as a Proposed Standard. Goals and Milestones: Done AAA Keys for MIPv4 to IESG Done MIPv4 VPN interaction problem statement to IESG Done Low latency handover to experimental Done Experimental MIPv4 message and extensions draft to IESG Done Dynamic Home Agent assignment protocol solution to IESG Done Revised MIPv4 Challenge/Response (3012bis) to IESG Done Regional registration document to IESG Done Generic Strings for MIPv4 (Proposed Std.) to the IESG Done MIPv4 Mobike interaction (BCP) to the IESG Done MIPv4 RADIUS Extensions Requirements to the IESG Done MIPv4 Extension for Config. Options (Proposed Std.) to the IESG Done FMIPv4 (Experimental) to the IESG Done MIPv4 VPN interaction (BCP) to the IESG Done Base MIPv4 Mobile Network Support (Draft Std.) to IESG Done Dual-stack MIPv4 (Draft Std.) to IESG Done Notification Mechanism (Draft Std.) to IESG Jul 2009 Revised MIPv4 specification (Proposed Std.) to IESG Jul 2009 Revised MIB for MIPv4 (Proposed Std.) to IESG Aug 2009 NEMO Dynamic Address Assignment (Proposed Std.) to IESG Nov 2009 GRE Key Extension (Proposed Std.) to IESG Nov 2009 Revised rfc2794bis (NAI extension) (Proposed Std.) to the IESG Nov 2009 RADIUS Extensions for MIPv4 to the RADEXT WG for comment Feb 2010 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG Mar 2010 Home Agent Assisted Route Optimization (Proposed Std.) to the IESG _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From glenzorn@comcast.net Wed Jul 22 00:25:51 2009 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 03D143A69AE for ; Wed, 22 Jul 2009 00:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.208 X-Spam-Level: X-Spam-Status: No, score=-0.208 tagged_above=-999 required=5 tests=[AWL=1.261, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 8mXF7gmubwxc for ; Wed, 22 Jul 2009 00:25:50 -0700 (PDT) Received: from QMTA13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by core3.amsl.com (Postfix) with ESMTP id EEBFF3A6B8B for ; Wed, 22 Jul 2009 00:25:49 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA13.emeryville.ca.mail.comcast.net with comcast id JvPi1c0010FhH24ADvQbsA; Wed, 22 Jul 2009 07:24:35 +0000 Received: from gwzPC ([124.120.223.104]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id JvQJ1c0012FljHG8UvQQrn; Wed, 22 Jul 2009 07:24:33 +0000 From: "Glen Zorn" To: "'Paul Hoffman'" , References: <808FD6E27AD4884E94820BC333B2DB773A713C6714@NOK-EUMSG-01.mgdnok.nokia.com> <31570_1248194109_n6LGZ8g0005271_p06240892c68b9e5cdb51@[10.20.30.158]> <96FFA21F50F96E866F0FB2D5@atlantis.pc.cs.cmu.edu> In-Reply-To: Date: Wed, 22 Jul 2009 14:19:51 +0700 Message-ID: <009301ca0a9c$d6d241c0$8476c540$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoKMvZHfiMwcnMWSdahvfU63OhsSwAaKiOQ Content-Language: en-us Subject: Re: [secdir] Security Directorate lunch on Tuesday 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, 22 Jul 2009 07:25:51 -0000 Paul Hoffman [mailto://phoffman@imc.org] writes: ... > If need be, we can move our lunch to a different day. I would like it, since the RFC Editorial Board typically lunches on Tuesday. ... From weiler+secdir@watson.org Wed Jul 22 07:17:17 2009 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 5BF6A3A686D for ; Wed, 22 Jul 2009 07:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9yqK9MLnyUc for ; Wed, 22 Jul 2009 07:17:16 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 447133A67EA for ; Wed, 22 Jul 2009 07:17:16 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n6ME6ZiQ078853 for ; Wed, 22 Jul 2009 10:06:35 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n6ME6Zeq078850 for ; Wed, 22 Jul 2009 15:06:35 +0100 (BST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 22 Jul 2009 15:06:35 +0100 (BST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Wed, 22 Jul 2009 15:06:35 +0100 (BST) Subject: Re: [secdir] Assignments for July 24th 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, 22 Jul 2009 14:17:17 -0000 Just sending a reminder of outstanding secdir assignments before I go get on an airplane. There are no new assignments below; one document moved from last call list to the telechat list. Brian Weis is next in the rotation. For telechat 2009-08-13 Dave Cridland T draft-ietf-behave-nat-behavior-discovery-07 Tobias Gondrom T draft-ietf-nea-pa-tnc-04 Phillip Hallam-Baker T draft-ietf-nea-pb-tnc-04 Steve Hanna T draft-ietf-netconf-partial-lock-09 Chris Newman T draft-ietf-mpls-tp-requirements-09 Radia Perlman T draft-ietf-pwe3-mpls-transport-04 Last calls and special requests: Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 Steve Hanna draft-peterson-rai-rfc3427bis-02 Love Hornquist-Astrand draft-ietf-ipfix-mib-07 Love Hornquist-Astrand draft-ietf-opsawg-smi-datatypes-in-xsd-05 Charlie Kaufman draft-ietf-ipsecme-ikev2-redirect-11 Julien Laganier draft-ietf-sip-certs-08 Catherine Meadows draft-ietf-speechsc-mrcpv2-19 Sandy Murphy draft-ietf-speermint-voip-consolidated-usecases-13 Vidya Narayanan draft-ietf-sip-saml-06 Vidya Narayanan draft-ietf-enum-3761bis-04 Vidya Narayanan draft-ietf-opsawg-syslog-snmp-03 Eric Rescorla draft-ietf-enum-iax-05 Eric Rescorla draft-ietf-simple-xcap-diff-13 Joe Salowey draft-ietf-geopriv-lis-discovery-11 Joe Salowey draft-ietf-sipping-service-identification-03 Juergen Schoenwaelder draft-harkins-emu-eap-pwd-04 Yaron Sheffer draft-ietf-msec-tesla-for-alc-norm-07 Hannes Tschofenig draft-ietf-pce-monitoring-05 Hannes Tschofenig draft-ietf-pkix-ta-format-03 Sean Turner draft-nottingham-http-link-header-06 Carl Wallace draft-solinas-rfc4753bis-00 Sam Weiler draft-chown-v6ops-rogue-ra-03 Nico Williams draft-ietf-v6ops-ra-guard-03 Larry Zhu draft-thaler-v6ops-teredo-extensions-03 Larry Zhu draft-ietf-ecrit-location-hiding-req-02 On Sat, 18 Jul 2009, Samuel Weiler wrote: > Review instructions and related resources are at: > http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > > For telechat 2009-08-13 > > Dave Cridland T draft-ietf-behave-nat-behavior-discovery-07 > Tobias Gondrom T draft-ietf-nea-pa-tnc-04 > Phillip Hallam-Baker T draft-ietf-nea-pb-tnc-04 > Chris Newman T draft-ietf-mpls-tp-requirements-09 > Radia Perlman T draft-ietf-pwe3-mpls-transport-04 > Stefan Santesson T draft-freed-sieve-in-xml-05 > > Last calls and special requests: > > Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 > Steve Hanna draft-peterson-rai-rfc3427bis-02 > Steve Hanna draft-ietf-netconf-partial-lock-09 > Love Hornquist-Astrand draft-ietf-ipfix-mib-07 > Love Hornquist-Astrand draft-ietf-opsawg-smi-datatypes-in-xsd-05 > Charlie Kaufman draft-ietf-ipsecme-ikev2-redirect-11 > Julien Laganier draft-ietf-sip-certs-08 > Barry Leiba > draft-ietf-simple-interdomain-scaling-analysis-07 > Catherine Meadows draft-ietf-speechsc-mrcpv2-19 > Sandy Murphy > draft-ietf-speermint-voip-consolidated-usecases-13 > Vidya Narayanan draft-ietf-sip-saml-06 > Vidya Narayanan draft-ietf-enum-3761bis-04 > Vidya Narayanan draft-ietf-opsawg-syslog-snmp-03 > Magnus Nystrom draft-ietf-opsawg-syslog-msg-mib-04 > Hilarie Orman draft-ietf-ospf-hmac-sha-05 > Eric Rescorla draft-ietf-enum-iax-05 > Eric Rescorla draft-ietf-simple-xcap-diff-13 > Joe Salowey draft-ietf-geopriv-lis-discovery-11 > Joe Salowey > draft-ietf-sipping-service-identification-03 > Juergen Schoenwaelder draft-harkins-emu-eap-pwd-04 > Yaron Sheffer draft-ietf-msec-tesla-for-alc-norm-07 > Hannes Tschofenig draft-ietf-pce-monitoring-05 > Hannes Tschofenig draft-ietf-pkix-ta-format-03 > Sean Turner draft-nottingham-http-link-header-06 > Carl Wallace draft-solinas-rfc4753bis-00 > Sam Weiler draft-chown-v6ops-rogue-ra-03 > Sam Weiler draft-seokung-msec-mikey-seed-02 > Nico Williams draft-ietf-v6ops-ra-guard-03 > Larry Zhu draft-thaler-v6ops-teredo-extensions-03 > Larry Zhu draft-ietf-ecrit-location-hiding-req-02 From ietfdbh@comcast.net Wed Jul 22 07:53:24 2009 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 548C73A67EA for ; Wed, 22 Jul 2009 07:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.183 X-Spam-Level: X-Spam-Status: No, score=-1.183 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_05=-1.11] 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 ui0XGKjymyt8 for ; Wed, 22 Jul 2009 07:53:23 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 6228C3A68B2 for ; Wed, 22 Jul 2009 07:53:23 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA03.westchester.pa.mail.comcast.net with comcast id JzNj1c0090vyq2s532r0cs; Wed, 22 Jul 2009 14:51:00 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA05.westchester.pa.mail.comcast.net with comcast id K2qz1c00y0UQ6dC3R2qzQF; Wed, 22 Jul 2009 14:51:00 +0000 From: "David Harrington" To: "'Glen Zorn'" , "'Paul Hoffman'" , References: <808FD6E27AD4884E94820BC333B2DB773A713C6714@NOK-EUMSG-01.mgdnok.nokia.com> <31570_1248194109_n6LGZ8g0005271_p06240892c68b9e5cdb51@[10.20.30.158]> <96FFA21F50F96E866F0FB2D5@atlantis.pc.cs.cmu.edu> <009301ca0a9c$d6d241c0$8476c540$@net> Date: Wed, 22 Jul 2009 10:50:58 -0400 Message-ID: <1dd701ca0adb$d357c260$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: <009301ca0a9c$d6d241c0$8476c540$@net> Thread-Index: AcoKMvZHfiMwcnMWSdahvfU63OhsSwAaKiOQABAH1bA= Subject: Re: [secdir] Security Directorate lunch on Tuesday 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, 22 Jul 2009 14:53:24 -0000 I would like to avoid conflict with the OPSDIR lunch (Monday) and the WG Chairs lunch (Wednesday). dbh > -----Original Message----- > From: secdir-bounces@ietf.org > [mailto:secdir-bounces@ietf.org] On Behalf Of Glen Zorn > Sent: Wednesday, July 22, 2009 3:20 AM > To: 'Paul Hoffman'; secdir@ietf.org > Subject: Re: [secdir] Security Directorate lunch on Tuesday > > Paul Hoffman [mailto://phoffman@imc.org] writes: > ... > > > If need be, we can move our lunch to a different day. > > I would like it, since the RFC Editorial Board typically > lunches on Tuesday. > > ... > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From turners@ieca.com Wed Jul 22 08:02:48 2009 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 C5C1A3A6B0A for ; Wed, 22 Jul 2009 08:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTW0PD4SMM03 for ; Wed, 22 Jul 2009 08:02:48 -0700 (PDT) Received: from smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by core3.amsl.com (Postfix) with SMTP id DD6D83A6B18 for ; Wed, 22 Jul 2009 08:02:47 -0700 (PDT) Received: (qmail 90843 invoked from network); 22 Jul 2009 14:55:17 -0000 Received: from unknown (HELO thunderfish.local) (turners@96.241.3.124 with plain) by smtp105.biz.mail.re2.yahoo.com with SMTP; 22 Jul 2009 14:55:16 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: xIRx8LAVM1lSt_Gruj6MwM4gzDOVQrGXRyx7JwcNl0f2rDRk9SkFS84TQbU29t5R060360yCbER8uzZ7hzIJNY4asm8kEZQsiCmZPhsVgv64xAPcBZLI52w4lBZvuHAXE2CRnmWcL97GCKqA5lDmMOIRCPwMu64wPeVsX1z7PsTf.3dVDFvScMm7luaWn8Oqy7qwyRfks0qTOsTeuOok1yPy3WoHVPFJs8JDtvzVhzAr.56OglToHYgSq511KWwesXZtJjw6RD42r7.__EGCsoQo5Q2o7b4mgGw1yxqIEPGMe5q7QR4sv7Abi9LyxOAXoMC5f9UIIub_i._s6hJJjHyIi14yBdkAGf4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A672854.3030206@ieca.com> Date: Wed, 22 Jul 2009 10:55:16 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: secdir@ietf.org References: <808FD6E27AD4884E94820BC333B2DB773A713C6714@NOK-EUMSG-01.mgdnok.nokia.com> <31570_1248194109_n6LGZ8g0005271_p06240892c68b9e5cdb51@[10.20.30.158]> <96FFA21F50F96E866F0FB2D5@atlantis.pc.cs.cmu.edu> <009301ca0a9c$d6d241c0$8476c540$@net> <1dd701ca0adb$d357c260$0600a8c0@china.huawei.com> In-Reply-To: <1dd701ca0adb$d357c260$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [secdir] Security Directorate lunch on Tuesday 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, 22 Jul 2009 15:02:48 -0000 I think the GEN ART lunch is going to be Thursday. spt David Harrington wrote: > I would like to avoid conflict with the OPSDIR lunch (Monday) and the > WG Chairs lunch (Wednesday). > > dbh > >> -----Original Message----- >> From: secdir-bounces@ietf.org >> [mailto:secdir-bounces@ietf.org] On Behalf Of Glen Zorn >> Sent: Wednesday, July 22, 2009 3:20 AM >> To: 'Paul Hoffman'; secdir@ietf.org >> Subject: Re: [secdir] Security Directorate lunch on Tuesday >> >> Paul Hoffman [mailto://phoffman@imc.org] writes: >> ... >> >>> If need be, we can move our lunch to a different day. >> I would like it, since the RFC Editorial Board typically >> lunches on Tuesday. >> >> ... >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From phoffman@imc.org Wed Jul 22 08:11:55 2009 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 9BA973A6A2A for ; Wed, 22 Jul 2009 08:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYtuskFDKdam for ; Wed, 22 Jul 2009 08:11:55 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 88C3D3A6882 for ; Wed, 22 Jul 2009 08:11:54 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MFBo9x041926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Jul 2009 08:11:51 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1dd701ca0adb$d357c260$0600a8c0@china.huawei.com> References: <808FD6E27AD4884E94820BC333B2DB773A713C6714@NOK-EUMSG-01.mgdnok.nokia.com> <31570_1248194109_n6LGZ8g0005271_p06240892c68b9e5cdb51@[10.20.30.158]> <96FFA21F50F96E866F0FB2D5@atlantis.pc.cs.cmu.edu> <009301ca0a9c$d6d241c0$8476c540$@net> <1dd701ca0adb$d357c260$0600a8c0@china.huawei.com> Date: Wed, 22 Jul 2009 08:11:48 -0700 To: From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [secdir] Security Directorate lunch on Tuesday 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, 22 Jul 2009 15:11:55 -0000 Just a note that I wasn't suggesting that we change our lunch *this week*, but maybe consider it for the future. However, it is clear that "regular" lunches already occupy Monday and Wednesday, so there might be a permanent conflict. From j.schoenwaelder@jacobs-university.de Wed Jul 22 08:57:08 2009 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 771873A681E; Wed, 22 Jul 2009 08:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6] 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 VfWeO-CD-Dlh; Wed, 22 Jul 2009 08:57:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6358D28C287; Wed, 22 Jul 2009 08:57:07 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7739FC001B; Wed, 22 Jul 2009 17:55:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SDthMoUQoB7c; Wed, 22 Jul 2009 17:55:47 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43C54C0007; Wed, 22 Jul 2009 17:55:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 38B24B69435; Wed, 22 Jul 2009 17:55:46 +0200 (CEST) Date: Wed, 22 Jul 2009 17:55:46 +0200 From: Juergen Schoenwaelder To: dharkins@arubanetworks.com, gwz@netcube.com Message-ID: <20090722155546.GA6013@elstar.local> Mail-Followup-To: dharkins@arubanetworks.com, gwz@netcube.com, iesg@ietf.org, secdir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-harkins-emu-eap-pwd-04.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 15:57:08 -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 defines an EAP authentication method using a password. Not being a cryptography expert, I reviewed the document form the perspective of an informed outsider but I did not try to verify whether the cryptographic claims are all correct. That said, I found the document well written and the security discussion convincing. Editorial nits: a) On page 6, you use the acronym PRF and it will help readability if you spell it out here since it has not been introduced yet: s/and a PRF/and a pseudo-random function PRF/ b) In figure 1, you could replace res = PRF(key, i | label | L) K(1) = res with K(1) = PRF(key, i | label | L) res = K(1) since this makes the assignments before the loop and in the loop body symmetric and thus perhaps things easier to read. c) There are two places where IANA assigned values need to be filled into the text; perhaps add more explicit RFC editor instructions so the editor knows what to fill in for 'TBD1'. d) s/DIffie-/Diffie-/ e) You may want to complete reference [BMP00] - the proceedings were published by Springer-Verlag in LNCS 1807. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From yaronf@checkpoint.com Wed Jul 22 16:20:13 2009 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 084223A6BF8; Wed, 22 Jul 2009 16:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.565, 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 1jRK10F5qKeU; Wed, 22 Jul 2009 16:20:12 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 697523A6972; Wed, 22 Jul 2009 16:20:11 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 3D04029C004; Wed, 22 Jul 2009 22:28:05 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D760429C002; Wed, 22 Jul 2009 22:28:04 +0300 (IDT) X-CheckPoint: {4A676729-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n6MJRm3d004699; Wed, 22 Jul 2009 22:27:48 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 22 Jul 2009 22:27:47 +0300 From: Yaron Sheffer To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-msec-tesla-for-alc-norm@tools.ietf.org" , "msec-chairs@tools.ietf.org" Date: Wed, 22 Jul 2009 22:27:45 +0300 Thread-Topic: SecDir review of draft-ietf-msec-tesla-for-alc-norm-07 Thread-Index: AcoLAn0n3492akjzRjKj37C625ayJQ== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8012953655E08@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00CF_01CA0B1B.A2794700" MIME-Version: 1.0 Subject: [secdir] SecDir review of draft-ietf-msec-tesla-for-alc-norm-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: Wed, 22 Jul 2009 23:20:13 -0000 ------=_NextPart_000_00CF_01CA0B1B.A2794700 Content-Type: text/plain; charset="windows-1255" 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.=A0 = These comments were written primarily for the benefit of the security area directors.=A0 Document editors and WG chairs should treat these comments = just like any other last call comments. This document applies the TESLA multicast authentication protocol to ALC = and NORM, two reliable multicast protocols. It is very much a security = document, and must have been reviewed by numerous security experts - and it shows. General Overall this is a good document, but I suspect that it has too many = options and leaves too many things open as to be truly interoperable. So Experimental is the right designation. From a security point of view, = things seem to be well covered, but see my two comments below. Security Issues 4.2.2.2: it is far from clear that if I trust you to send me packets (a movie, say), I also trust you to configure my NTP client (list of = servers and trust anchors for them). So I wonder if using one of the offered NTP servers should really be MUST. Or are we really expecting a separate application level NTP layer, on top of that maintained by the OS? 6. The Security Considerations have no discussion at all of the security = of the back channel. I understand that such a channel does exist, at least = for NORM. This channel remains unprotected (or its protection remains unspecified, see Sec. 1.1). Can it be used to DOS the sender? Other receivers? Are additional attacks possible? Other Comments 2.2: leaving the bootstrapping step implementation-dependent means that = the protocol is non-interoperable. 3.1.2.2: this section implies (last paragraph) that the use of periodic bootstrap information is only applicable for the case where direct time synchronization is used. Is this required by the TESLA protocol? 3.4.3: the description of the =93Disclosed Key=94 field says it must be = 0 in the first d intervals, which contradicts the last paragraph of the section, where it is forbidden to use this tag in those intervals. 3.4.7 (and elsewhere): I wonder about the design choice of making the = length of the NSB (and hence, the explicit part of the interval index) depend = on the size of the truncated MAC. The considerations for selecting one are primarily security-related, while for the other they are primarily about bandwidth and reliability. Why make them dependent? 4.1: the text =93verify the Group MAC if present=94 is misleading (an = attacker might remove it from the packet). It should be =93if the G bit is set in = the Bootstrap message=94. 4.3, step 5: when doing congestion control, isn=92t there value in = keeping key-disclosure packets, even when other packets are dropped? The effect = of key-disclosure packets being dropped may be dozens of other packets that = are lost. 4.3: I find this text self-contradictory: =93In this specification, a = receiver using TESLA MUST immediately drop unsafe packets. But the receiver MAY = also decide, at any time, to continue an ALC or NORM session in unsafe mode, ignoring TESLA extensions.=94 I would have felt somewhat better about it = if the text said something like =93there SHOULD be explicit user action to = move to unsafe (insecure) mode=94. ------=_NextPart_000_00CF_01CA0B1B.A2794700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDcyMjE5Mjc0NVowIwYJKoZIhvcNAQkEMRYEFKnklzqQaDVo GOk2hgyUUikSkj59MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA dMQTSCBX2QQDWEzos32Zg9JNqUySepWzj1X75JKZmeBibDqCIgVVSWPHdQMzjE/RYgWcKCyI6i/G XeikR5T0Gr/uwR2Z9PGl7mb9UDPpxEOP99JCD84VaxK/gjwTwNYfQibKI4gIavw1dGQEXd2St7z/ uuRrtBCukfQorqTBSWTrf6vRqyWFDNSUJ/pfrIP1jIIwCn5+qVXt4kf9O4BIg4mNc1SPIpZYx+85 XCJglNBZV3WHDZD1etthcYxtZSvQRm7UZqD+B/M/jyA9tOPgqBy651X13qD6UgH6y0rqpUaGjwap P6zk/vw6DW4lsoN/ycb7dB85krmTl9qzx24dmwAAAAAAAA== ------=_NextPart_000_00CF_01CA0B1B.A2794700-- From secdir-bounces@mit.edu Wed Jul 22 08:56:04 2009 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 CE8E93A6B58 for ; Wed, 22 Jul 2009 08:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.034 X-Spam-Level: X-Spam-Status: No, score=-8.034 tagged_above=-999 required=5 tests=[AWL=-1.435, BAYES_00=-2.599, 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 c3bO8Sy73aQd for ; Wed, 22 Jul 2009 08:56:03 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id BBB823A68F6 for ; Wed, 22 Jul 2009 08:56:03 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n6MFhuVg015331 for ; Wed, 22 Jul 2009 11:43:56 -0400 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n6MFht5E015328 for ; Wed, 22 Jul 2009 11:43:55 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n6MFhket024793 for ; Wed, 22 Jul 2009 11:43:46 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 5C6F621A69C5 for ; Wed, 22 Jul 2009 11:08:15 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id TPH6DEK07YP50rXh for ; Wed, 22 Jul 2009 11:08:15 -0400 (EDT) Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org; Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4F633A6807; Wed, 22 Jul 2009 08:08:13 -0700 (PDT) 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 254773A6B61 for ; Tue, 21 Jul 2009 07:56:18 -0700 (PDT) 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 CaceFJUiF0yM for ; Tue, 21 Jul 2009 07:56:17 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 1AB7F3A6E7D for ; Tue, 21 Jul 2009 07:56:17 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1MTGkf-0002ah-Jg for public-new-work-dist@listhub.w3.org; Tue, 21 Jul 2009 14:55:33 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1MTGke-0002a5-VC for public-new-work@listhub.w3.org; Tue, 21 Jul 2009 14:55:32 +0000 Received: from homer.w3.org ([128.30.52.30]) by bart.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1MTGkW-00011Z-Jv; Tue, 21 Jul 2009 14:55:32 +0000 Received: from [IPv6:::1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 8B4A14EEE7; Tue, 21 Jul 2009 10:55:23 -0400 (EDT) Message-Id: <4A601336-8A16-4304-B8C6-6BC3B9E64655@w3.org> From: Ian Jacobs To: public-new-work@w3.org Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 21 Jul 2009 09:55:22 -0500 X-Mailer: Apple Mail (2.935.3) X-W3C-Hub-Spam-Status: No, score=-3.3 X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1.8, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13 X-W3C-Scan-Sig: bart.w3.org 1MTGkW-00011Z-Jv ca6bfa3377f55a8a1c0129e1bf5be551 X-Original-To: public-new-work@w3.org Archived-At: Resent-From: public-new-work@w3.org X-Mailing-List: archive/latest/47 X-Loop: public-new-work@w3.org Resent-Sender: public-new-work-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Tue, 21 Jul 2009 14:55:33 +0000 X-Mailman-Approved-At: Wed, 22 Jul 2009 08:08:12 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Wed, 22 Jul 2009 23:14:12 -0700 Subject: [secdir] [New-work] Proposed W3C Charter: SPARQL Working Group (until 2009-09-04) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 15:56:04 -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 the SPARQL Working Group: http://www.w3.org/2009/05/sparql-phase-II-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2009-09-04 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact 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 _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From Pasi.Eronen@nokia.com Thu Jul 23 01:10:50 2009 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 98F5A3A68D5; Thu, 23 Jul 2009 01:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.316 X-Spam-Level: X-Spam-Status: No, score=-6.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, 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 0gIC5cdsiLfW; Thu, 23 Jul 2009 01:10:49 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 5EE0D3A6817; Thu, 23 Jul 2009 01:10:49 -0700 (PDT) Received: from mgw-mx09.nokia.com ([192.100.105.134]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6N88RcS017352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Jul 2009 11:08:29 +0300 Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6N82pwU030517; Thu, 23 Jul 2009 03:03:03 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 11:02:56 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 11:02:50 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 23 Jul 2009 10:02:36 +0200 From: "Pasi.Eronen@nokia.com" To: Date: Thu, 23 Jul 2009 10:02:35 +0200 Thread-Topic: Email statistics for SEC WGs Thread-Index: AcoLa/B7QEbZfdxRQLi8FADTZx0tAA== Message-ID: <808FD6E27AD4884E94820BC333B2DB773A7141A98B@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jul 2009 08:02:50.0023 (UTC) FILETIME=[F8FD3370:01CA0B6B] X-Nokia-AV: Clean Subject: [secdir] Email statistics for SEC WGs 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, 23 Jul 2009 08:10:50 -0000 FYI: Here's some data about how active the WG mailing lists in security area have been in 2009. I'm not sure what conclusions can be drawn from this -- different WGs are in different phases of their work, have different number of work items, and communication styles are different. But perhaps someone finds these interesting... Emails on WG mailing list from 2009-01-01 to 2009-07-21 (some spam excluded manually when it would have had a big effect on the numbers): WG messages/month =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D dkim 240 ipsecme 139 sasl 103 pkix 88 krb-wg 83 isms 82 tls 65 hokey 47 keyprov 36 smime 25 emu 23 kitten 15 syslog 11 nea 7 btns 4 ltans 2 msec 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D total 971 Best regards, Pasi From dharkins@lounge.org Thu Jul 23 12:10:39 2009 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 DC8B33A688A; Thu, 23 Jul 2009 12:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.611 X-Spam-Level: X-Spam-Status: No, score=-5.611 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, 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 JjxZiCReKX39; Thu, 23 Jul 2009 12:10:38 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 1800F3A69C5; Thu, 23 Jul 2009 12:10:38 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id AABF810224074; Thu, 23 Jul 2009 12:09:05 -0700 (PDT) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 23 Jul 2009 12:09:05 -0700 (PDT) Message-ID: In-Reply-To: <20090722155546.GA6013@elstar.local> References: <20090722155546.GA6013@elstar.local> Date: Thu, 23 Jul 2009 12:09:05 -0700 (PDT) From: "Dan Harkins" To: dharkins@arubanetworks.com, gwz@netcube.com, iesg@ietf.org, secdir@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: Re: [secdir] secdir review of draft-harkins-emu-eap-pwd-04.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: Thu, 23 Jul 2009 19:10:39 -0000 Hi Juergen, Thank you for your review of our draft and your helpful suggestions for improving it. I am in the process of editing the draft to incorporate other Last Call comments and will include your comments as well. regards, Dan. On Wed, July 22, 2009 8:55 am, Juergen Schoenwaelder wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The draft defines an EAP authentication method using a password. Not > being a cryptography expert, I reviewed the document form the > perspective of an informed outsider but I did not try to verify > whether the cryptographic claims are all correct. That said, I found > the document well written and the security discussion convincing. > > Editorial nits: > > a) On page 6, you use the acronym PRF and it will help readability if > you spell it out here since it has not been introduced yet: > > s/and a PRF/and a pseudo-random function PRF/ > > b) In figure 1, you could replace > > res = PRF(key, i | label | L) > K(1) = res > with > K(1) = PRF(key, i | label | L) > res = K(1) > > since this makes the assignments before the loop and in the loop > body symmetric and thus perhaps things easier to read. > > c) There are two places where IANA assigned values need to be filled > into the text; perhaps add more explicit RFC editor instructions so > the editor knows what to fill in for 'TBD1'. > > d) s/DIffie-/Diffie-/ > > e) You may want to complete reference [BMP00] - the proceedings were > published by Springer-Verlag in LNCS 1807. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From alexey.melnikov@isode.com Fri Jul 24 03:19:16 2009 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 00B433A6B72 for ; Fri, 24 Jul 2009 03:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[AWL=0.861, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 t7oVh7iTklEe for ; Fri, 24 Jul 2009 03:19:15 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 1741A3A6A56 for ; Fri, 24 Jul 2009 03:19:15 -0700 (PDT) Received: from [10.88.5.30] ((unknown) [212.175.117.115]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 24 Jul 2009 11:19:14 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4A698A7E.2070602@isode.com> Date: Fri, 24 Jul 2009 13:18:38 +0300 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "Pasi.Eronen@nokia.com" References: <808FD6E27AD4884E94820BC333B2DB773A7141A98B@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A7141A98B@NOK-EUMSG-01.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org Subject: Re: [secdir] Email statistics for SEC WGs 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, 24 Jul 2009 10:19:16 -0000 Pasi.Eronen@nokia.com wrote: >FYI: Here's some data about how active the WG mailing lists in >security area have been in 2009. > >I'm not sure what conclusions can be drawn from this -- different >WGs are in different phases of their work, have different number >of work items, and communication styles are different. But perhaps >someone finds these interesting... > >Emails on WG mailing list from 2009-01-01 to 2009-07-21 >(some spam excluded manually when it would have had a big >effect on the numbers): > >WG messages/month >========= ============== >dkim 240 >ipsecme 139 >sasl 103 > > Wow. Do we get prises for the number of emails posted :-)? >pkix 88 >krb-wg 83 >isms 82 >tls 65 >hokey 47 >keyprov 36 >smime 25 >emu 23 >kitten 15 >syslog 11 >nea 7 >btns 4 >ltans 2 >msec 1 >============== >total 971 > >Best regards, >Pasi > From stephen.farrell@cs.tcd.ie Fri Jul 24 03:59:00 2009 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 39BB53A68FC for ; Fri, 24 Jul 2009 03:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9Rmm29bOx1p for ; Fri, 24 Jul 2009 03:58:59 -0700 (PDT) Received: from SG2EHSOBE003.bigfish.com (sg2ehsobe003.messaging.microsoft.com [207.46.51.77]) by core3.amsl.com (Postfix) with ESMTP id 158E23A6A0F for ; Fri, 24 Jul 2009 03:58:54 -0700 (PDT) Received: from mail91-sin-R.bigfish.com (10.210.100.254) by SG2EHSOBE003.bigfish.com (10.210.112.23) with Microsoft SMTP Server id 8.1.340.0; Fri, 24 Jul 2009 10:43:02 +0000 Received: from mail91-sin (localhost.localdomain [127.0.0.1]) by mail91-sin-R.bigfish.com (Postfix) with ESMTP id 54B0F151020E; Fri, 24 Jul 2009 10:42:56 +0000 (UTC) X-SpamScore: -26 X-BigFish: VPS-26(zz1432R98dN936eM1b0bMzz1202hzzz2dh6bh87h61h) X-Spam-TCS-SCL: 0:0 X-FB-DOMAIN-IP-MATCH: fail Received: by mail91-sin (MessageSwitch) id 1248432174763617_19829; Fri, 24 Jul 2009 10:42:54 +0000 (UCT) Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by mail91-sin.bigfish.com (Postfix) with ESMTP id 3DE09C0046; Fri, 24 Jul 2009 10:42:54 +0000 (UTC) Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 18E9268003; Fri, 24 Jul 2009 11:42:59 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A042D51441E; Fri, 24 Jul 2009 11:42:59 +0100 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id 07B9768004; Fri, 24 Jul 2009 11:42:59 +0100 (IST) Message-ID: <4A699034.3030504@cs.tcd.ie> Date: Fri, 24 Jul 2009 11:43:00 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Alexey Melnikov References: <808FD6E27AD4884E94820BC333B2DB773A7141A98B@NOK-EUMSG-01.mgdnok.nokia.com> <4A698A7E.2070602@isode.com> In-Reply-To: <4A698A7E.2070602@isode.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A142D51441E X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.109.8) Cc: "Pasi.Eronen@nokia.com" , secdir@ietf.org Subject: Re: [secdir] Email statistics for SEC WGs 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, 24 Jul 2009 10:59:00 -0000 Alexey Melnikov wrote: > Pasi.Eronen@nokia.com wrote: > >> FYI: Here's some data about how active the WG mailing lists in >> security area have been in 2009. >> >> I'm not sure what conclusions can be drawn from this -- different >> WGs are in different phases of their work, have different number >> of work items, and communication styles are different. But perhaps >> someone finds these interesting... >> >> Emails on WG mailing list from 2009-01-01 to 2009-07-21 >> (some spam excluded manually when it would have had a big >> effect on the numbers): >> >> WG messages/month >> ========= ============== >> dkim 240 >> ipsecme 139 >> sasl 103 >> >> > Wow. Do we get prises for the number of emails posted :-)? Only the sensible ones. That might well take our WG off the top of the list;-) S. From weiler@watson.org Sun Jul 26 02:00:38 2009 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 513853A689E for ; Sun, 26 Jul 2009 02:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] 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 va-UVSy7T4Fx for ; Sun, 26 Jul 2009 02:00:37 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 8D5183A6882 for ; Sun, 26 Jul 2009 02:00:37 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n6Q90bdE013401; Sun, 26 Jul 2009 05:00:37 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n6Q90bOR013398; Sun, 26 Jul 2009 10:00:37 +0100 (BST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sun, 26 Jul 2009 10:00:37 +0100 (BST) From: Samuel Weiler To: Ray Pelletier In-Reply-To: Message-ID: References: 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.0.1 (fledge.watson.org [127.0.0.1]); Sun, 26 Jul 2009 10:00:37 +0100 (BST) Cc: secdir@ietf.org Subject: Re: [secdir] [75all] Welcome to Stockholm! 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, 26 Jul 2009 09:00:38 -0000 On Sun, 26 Jul 2009, Ray Pelletier wrote: > ***** NOTE: NO outside food is permitted in the Conference Centre. ****** It occurs to me that we have some organized events (e.g. the secdir lunch) that have, in recent years, been "bring your own lunch". Being turned away at the door could be an unpleasant surprise. Rather than have fourty security geeks looking for some creative way around the building security guards, will the IAOC buy us lunch? -- Sam From rbarnes@bbn.com Sun Jul 26 02:26:00 2009 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 AF1CE3A68C6 for ; Sun, 26 Jul 2009 02:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] 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 c3d-a3DcWmbj for ; Sun, 26 Jul 2009 02:26:00 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E94E43A689E for ; Sun, 26 Jul 2009 02:25:59 -0700 (PDT) Received: from [128.89.253.222] (helo=host-78-64-88-202.homerun.telia.com) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MUzzS-0001PQ-9t; Sun, 26 Jul 2009 05:25:58 -0400 Message-ID: <4A6C2125.6040805@bbn.com> Date: Sun, 26 Jul 2009 11:25:57 +0200 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Samuel Weiler References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ray Pelletier , secdir@ietf.org Subject: Re: [secdir] [75all] Welcome to Stockholm! 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, 26 Jul 2009 09:26:00 -0000 I'd be willing to pay for lunch to be provided at the venue. Perhaps the IAOC could arrange it and we could chip in? Samuel Weiler wrote: > On Sun, 26 Jul 2009, Ray Pelletier wrote: > >> ***** NOTE: NO outside food is permitted in the Conference Centre. >> ****** > > It occurs to me that we have some organized events (e.g. the secdir > lunch) that have, in recent years, been "bring your own lunch". Being > turned away at the door could be an unpleasant surprise. Rather than > have fourty security geeks looking for some creative way around the > building security guards, will the IAOC buy us lunch? > > -- Sam > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From fred@cisco.com Mon Jul 27 04:37:03 2009 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 B8C1A28C215 for ; Mon, 27 Jul 2009 04:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.683 X-Spam-Level: X-Spam-Status: No, score=-109.683 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 8ZMR4KRAOu6a for ; Mon, 27 Jul 2009 04:37:02 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0518628C1BA for ; Mon, 27 Jul 2009 04:37:00 -0700 (PDT) X-Files: Recommendation of IPv6 Security work--on the flight-2.ppt : 32256 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0AAMMtbUqQ/uCLe2dsb2JhbACBUZguAQEWJAaeE4gojWQFhA2BTQ X-IronPort-AV: E=Sophos;i="4.43,276,1246838400"; d="ppt'32?scan'32,208,32";a="45902173" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 27 Jul 2009 11:37:01 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6RBb0IU031900; Mon, 27 Jul 2009 13:37:00 +0200 Received: from dhcp-56c8.meeting.ietf.org (dhcp-10-61-101-160.cisco.com [10.61.101.160]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6RBaxGQ014558; Mon, 27 Jul 2009 11:37:00 GMT Message-Id: <633E561F-48D1-42DE-A310-9E77DB0A87F1@cisco.com> From: Fred Baker To: Tina TSOU In-Reply-To: Content-Type: multipart/mixed; boundary=Apple-Mail-40--195521586 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 13:36:57 +0200 References: X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=46607; t=1248694620; x=1249558620; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Discussion=20from=20the=20Security=20Directorat e |Sender:=20; bh=xOalm+peeFE/s1aFM/GtQhy7SirzpmUFSxgE1uBNuYU=; b=vdrTJpWPAIKxN545DqRLJOtPNP9T6gWkQ3/vvyZvxLRARNMi6zL2NFFTUf mWAr3Y8rZptRakMvJRmkM20JHi0ZHhx/rbALdtBwpRrgdoFBWWFqzKF9WkId rvKL6jjMni; Authentication-Results: ams-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Joe Abley , 6man-ads@tools.ietf.org, secdir@ietf.org, Kurt Erik Lindqvist , Joel Jaeggli , Softwire Chairs , v6ops-ads@tools.ietf.org, softwire-ads@tools.ietf.org, behave-ads@tools.ietf.org, Behave Chairs Subject: [secdir] Discussion from the Security Directorate 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, 27 Jul 2009 11:37:03 -0000 --Apple-Mail-40--195521586 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Thanks, Tina. I will add this to the IPv6 Operations agenda, probably during our second session Tuesday. You will note that I am copying the chairs and ADs from several working groups. The reason is that the primary thrust of the comments you are making apply to work being done in those working groups. Slide 5 specifically requests a threat analysis, security assessment, and "function recommendation" on each transition technology; these are in fact being done in behave and softwires. I mention 6man because marketing blather from the IPv6 form makes security claims for IPv6, which it would be good if that working group clarified. I do have to ask specifically what the Security Directorate hopes to find in the three documents that have been requested for each of these various technologies. What, specifically, is a "function recommendation"? A threat analysis is a statement that there exist a set of possible threats. Is a security assessment a statement about how those threats are responded to? What, if the WGs don't produce it, is going to leave the Security Directorate feeling ill-used? On Jul 27, 2009, at 12:56 PM, Tina TSOU wrote: > > B. R. > ">http://tinatsou.weebly.com/contact.html > Begin forwarded message: > >> From: "Romascanu, Dan (Dan)" >> Date: July 27, 2009 7:52:20 AM GMT+02:00 >> To: Ron Bonica >> Cc: Tina TSOU >> Subject: FW: [OPS-DIR] Reminder: OPS-DIR working lunch >> >> Ron, >> >> This looks more like an opsec (who are not meeting this time) or >> v6ops >> subject. >> >> Dan >> >> >> -----Original Message----- >> From: Tina TSOU [mailto:tena@huawei.com] >> Sent: Monday, July 27, 2009 12:02 AM >> To: Romascanu, Dan (Dan) >> Subject: Re: [OPS-DIR] Reminder: OPS-DIR working lunch >> >> Hi Dan, >> Could this be discussed at OPS-DIR working lunch? > > > --Apple-Mail-40--195521586 Content-Disposition: attachment; filename="Recommendation of IPv6 Security work--on the flight-2.ppt" Content-Type: application/vnd.ms-powerpoint; x-unix-mode=0644; name="Recommendation of IPv6 Security work--on the flight-2.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAALwAAAAAAAAAA EAAANwAAAAEAAAD+////AAAAAC4AAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8P AOgDDgwAAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAABwAAAAAAAAABAAAAAAAAAQ8A 8gNgAQAALwDIDwwAAAAwANIPBAAAAAAAAAAPANUHmAAAAAAAtw9EAAAAQQByAGkAYQBsAAAAWJcT ANHGDDBYlxMAAAAAADAA0g/wqRMA8KkTACAX7AF4lxMAT8UMMHiXEwAAAAAADwDVBwAABAAQALcP RAAAAItbU08AAGEAbAAAAFiXEwDRxgwwWJcTAAAAAAAwANIP8KkTAPCpEwAgF+wBeJcTAE/FDDB4 lxMAAAAAAA8A1QeGAAQAAACkDwgAAACAAEAAAAAAAAAApQ8MAAAAAAAACC4AAAAHAAAAAACpDwoA AAAHAAAAAgAECAkEQACjD24AAAAFAP/9PwAAACIgAABkAAAAAP8AAGQAAAAAAAAAAABAAgAAAAAH AAAA///vAAAAAAABAAAA//8SAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2AD AAAAAAAFAACABIAEAAAAAA8ACwS4AAAADwAA8LAAAAAAAAbwWAAAAAQkAAAKAAAAIgAAAAkAAAAB AAAABwAAAAIAAAAEAAAAAwAAAAQAAAAEAAAABAAAAAUAAAAEAAAABgAAAAQAAAAHAAAABAAAAAgA AAAIAAAACQAAAAQAAACDAAvwMAAAAIEBBAAACIMBAAAACIZBAAAAAL8BEAAQAMABAQAACMVBAAAA AP8BCAAIAAECAgAACEAAHvEQAAAABAAACAEAAAgCAAAI9wAAEB8A8A8cAAAAAADzAxQAAAACAAAA AAAAAAAAAAAAAACAAAAAAA8A0AczAQAAHwAUBBwAAAAAABUEFAAAALqTsPYAypo7vMvhMgDKmjsB AQAADwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAARQAAAGQAAABFAAAAZAAAAAAAAABccOwBkJcT AE/FDDAAAAAAAAAAAGD9//+m////AQATAHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAABACwAA HwATBDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQAAAC8lxMAdocMMPCpEwD8FuwBAAAAAAAAAAAA AAAAAAAAAAABEwAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAADwCIEzgAAAAPAIoTMAAAAAAA ug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAAANBAgAAABwtQAAcLUAAA8A8A8jCAAAAADz AxQAAAADAAAAAAAAAAIAAAAAAQAAAAAAAAAAnw8EAAAABgAAAAAAqA8kAAAAUmVjb21tZW5kYXRp b24gb2YgSVB2NiBTZWN1cml0eSB3b3JrEACfDwQAAAAFAAAAAACqDwoAAAABAAAAAQAAAAAAAADz AxQAAAAEAAAAAAAAAAIAAAABAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8GAAAAQWdlbmRhEACfDwQA AAABAAAAAACoD2kAAABUaGUgT3JpZ2luIG9mIFNlY3VyaXR5IFByb2JsZW1zDVNlY3VyaXR5IFBy aW5jaXBsZXMgZm9yIElQdjQvSVB2NiBUcmFuc2l0aW9uIFRlY2hub2xvZ3kNUmVjb21tZW5kZWQg V29ya3MAAKoPGgAAAFcAAAAAAAAAAQAAAAEAAAAAABIAAAAAAAAAAADzAxQAAAAFAAAAAAAAAAIA AAACAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8fAAAAVGhlIE9yaWdpbiBvZiBTZWN1cml0eSBQcm9i bGVtcwAAqg8SAAAAHwAAAAAAAAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACoD9UAAABMaW1pdGF0 aW9ucyBpbiB0aGUgZGVzaWduYXRpb24gb2Ygc29sdXRpb25zIGFuZCBwcm90b2NvbHMNQnVncyBp biB0aGUgaW1wbGVtZW50KGNvZGluZykgb2YgcHJvdG9jb2xzDVNlY3VyaXR5IHByb2JsZW1zIHNo b3cgdXAgaW4gZGVwbG95bWVudCBhbmQgdXNlLCB0aGVzZSBjYW5ub3QgYmUgdGhvdWdodCBvdXQg YXQgYWxsIHdoZW4gZGVzaWduaW5nIHRoZSBwcm90b2NvbHMAAKoPGgAAAEYAAAAAAAAAEAAAAAEA AAADAIAAAAAAAAAAAADzAxQAAAAIAAAAAAAAAAIAAAAEAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8O AAAAQ3VycmVudCBTdGF0dXMQAJ8PBAAAAAEAAAAAAKgPawEAAEEgbnVtYmVyIG9mIElQdjQvSVB2 NiB0cmFuc2l0aW9uIHRlY2hub2xvZ2llcywgaW5jbHVkaW5nIHR1bm5lbCwgdHJhbnNsYXRpb24g YW5kIGR1YWwgc3RhY2ssIGFyZSBwcm9wb3NlZC4NSVB2NiBoYXMgbm90IGJlZW4gYnVzaW5lc3Mg dXNlZCBhbmQgZGVwbG95ZWQgd2lsZGx5Lg1DdXN0b21lcnMgbWF5IG5vdCBiZSBxdWl0ZSBjbGVh ciB0aGV5IHdpbGwgY2hvb3NlIHdoaWNoIHRyYW5zaXRpb24gdGVjaG5vbG9neS9pc2UgaW4gY28t ZXhpc3RlbmNlIHN0YWdlLg1TZWN1cml0eSBzaG91bGQgYmUgb25lIG9mIHRoZSBtb3N0IGltcG9y dGFudCBmYWN0b3JzIGFzIHRoZSBldmFsdWF0aW9uIGNyaXRlcmlhIG9mIHRoZSBjdXN0b21lcnMu IAAAoQ8WAAAAbAEAAAAAABAAAFAAbAEAAAAAAgAcAAAAqg8aAAAA7gAAAAAAAAADAAAAAQAAAAMA ewAAAAAAAAAAAPMDFAAAAAkAAAAEAAAAAgAAAAUBAAAAAAAAAACfDwQAAAAAAAAAAACoDzcAAABT ZWN1cml0eSBQcmluY2lwbGVzIGZvciBJUHY0L0lQdjYgVHJhbnNpdGlvbiBUZWNobm9sb2d5AACh DxQAAAA4AAAAAAAAAAAAOAAAAAAAAgAoABAAnw8EAAAAAQAAAAAAqA/hAAAAVGhyZWUga2V5IGFz cGVjdHM6DVNlY3VyaXR5IGZvciBJUCBsYXllcg1TZWN1cml0eSBiZXR3ZWVuIHJlYWxtcw1NVVNU IE5PVCBpbnRyb2R1Y2UgdGhyZWF0cyBmcm9tIG9uZSByZWFsbSB0byBhbm90aGVyLCBlLmcuIGJy aW5nIHRocmVhdHMgZm9ybSBJUHY0IHJlYWxtIHRvIElQdjYgcmVhbG0uDVNlY3VyaXR5IGZvciB0 aGUga2V5IG5vZGUNU0hPVUxEIE5PVCBiZSBlYXNpbHkgYXR0YWNrZWQuAAChD2IAAAATAAAAAAAA AAAALgAAAAEAAAAAAGgAAAACAAAAAAAaAAAAAQAAAAAAHwAAAAIAAAAAABMAAAAAAAAALgAAAAAE AAAABGgAAAAABAAAAAQaAAAAAAgAAAAIHwAAAAAMAAAADAAA8wMUAAAABgAAAAAAAAACAAAAAwEA AAAAAAAAAJ8PBAAAAAAAAAAAAKgPEQAAAFJlY29tbWVuZGVkIFdvcmtzEACfDwQAAAABAAAAAACo DzQBAABFYWNoIHRyYW5zaXRpb24gdGVjaG5vbG9naWVzIGhhdmUgYm90aCBwcm9zIGFuZCBjb25z IGluIHNlY3VyaXR5Lg1BIGRvY3VtZW50OiB0aHJlYXRzIGFuYWx5c2lzIGZvciBkZXBsb3ltZW50 IG9mIGVhY2ggdHJhbnNpdGlvbiB0ZWNobm9sb2dpZXMuDUEgZG9jdW1lbnQ6IHNlY3VyaXR5IHJl cXVpcmVtZW50IGZvciBkZXBsb3ltZW50IG9mIGVhY2ggdHJhbnNpdGlvbiB0ZWNobm9sb2dpZXMu DUEgZG9jdW1lbnQ6IGZ1bmN0aW9uIHJlY29tbWVuZGF0aW9uIGZvciBkZXBsb3ltZW50IG9mIGVh Y2ggdHJhbnNpdGlvbiB0ZWNobm9sb2dpZXMuIC8A8A8cAAAAAADzAxQAAAAKAAAAAAAAAAAAAAAA AQAAAAAAAAAA6gMAAAAADwD4A8AJAAACAO8DGAAAAAEAAAABAgcJCAAAAAAAAAAAAAAAAAAMMGAA 8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAABgAPAHIAAAAP///wAAAAAAlpaW AAAAAAD731MA/5lmAMwzAACZZgAAYADwByAAAAD///8AAAAAAICAgAAAAAAAmcz/AMzM/wAzM8wA r2f/AGAA8AcgAAAA3vbxAAAAAACWlpYAAAAAAP///wCNxv8AAGbMAACoAABgAPAHIAAAAP//2QAA AAAAd3d3AAAAAAD///cAM8zMAP9QUAD/mQAAYADwByAAAAAAgIAA////AABaWAD//5kAAGRiAG1v xwAA//8AAP8AAGAA8AcgAAAAgAAAAP///wBcHwAA39KTAMwzAAC+eWAA//+ZANOiGQBgAPAHIAAA AAAAmQD///8AADNmAMz//wAzZswAALAAAGbM/wD/5wEAYADwByAAAAAAAAAA////ADNmmQDj6/EA ADOZAEaKSwBmzP8A8OUAAGAA8AcgAAAAaGtdAP///wB3d3cA0dHLAJCQggCAnqgA/8xmAOncuQBg APAHIAAAAGZmmQD///8APj5cAP///wBgWXsAZmb/AJnM/wD//5kAYADwByAAAABSPiYA////AC0g FQDfwI0AjHtwAI9fLwDMtAAAjJ6gAAAAow8+AAAAAQD//T8AAAAiIAAAZAAAAAD/AQBkAAAAAAAA AAAAQAIAAAAABwAAAP//7wAAAAAAAQAAAP//LAAAAAADAAAQAKMPfAAAAAUA//0/AAEAIiAAAGQA AAAA/wAAZAAUAAAA2AAAAEACAAAAAAcAAAD//+8AAAAAAAEAAAD//yAAAAAAAQAAgAUAABMg1AEg AQAAAgAcAIAFAAAiINACQAIAAAIAGACABQAAEyDwA2ADAAACABQAgAUAALsAEAWABAAAAAAgAKMP bgAAAAUA//0/AAAAIiAAAGQAAAAA/wAAZAAeAAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAAEAAAD/ /wwAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAA UACjD1IAAAAFAAAAAQkAAAAAAQAAAAAAAAABAAEJAAAAAAEAIAEAAAAAAgABCQAAAAABAEACAAAA AAMAAQkAAAAAAQBgAwAAAAAEAAEJAAAAAAEAgAQAAAAAYACjDwwAAAABAAAAAAAAAAAAAABwAKMP PgAAAAUAAAAAAAAAAAACABwAAQAAAAAAAAACABgAAgAAAAAAAAACABQAAwAAAAAAAAACABIABAAA AAAAAAACABIAgACjDz4AAAAFAAAAAAAAAAAAAgAYAAEAAAAAAAAAAgAUAAIAAAAAAAAAAgASAAMA AAAAAAAAAgAQAAQAAAAAAAAAAgAQAA8ADAQCBQAADwAC8PoEAAAQAAjwCAAAAAYAAAAGBAAADwAD 8JIEAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATw ygAAABIACvAIAAAAAgQAAAAKAACTAAvwNgAAAH8AAQAFAIAAIC/sAYcAAQAAAIEBBAAACIMBAAAA CL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAArQAgAWAVfQMPABHwEAAAAAAAwwsIAAAA AAAAAAEA7AEPAA3wTAAAAAAAnw8EAAAAAAAAAAAAoA8YAAAAVVP7UWRrBFkWf5GPzWtIcgdomJg3 aA9fAACiDwYAAAANAAAAAAAAAKoPCgAAAA0AAAABAAAAAAAPAATw/AAAABIACvAIAAAAAwQAAAAK AACDAAvwMAAAAH8AAQAFAIAAWDbsAYEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAA CAAAEPAIAAAA8AMgAWAVEw8PABHwEAAAAAAAwwsIAAAAAQAAAAIA7AEPAA3whAAAAAAAnw8EAAAA AQAAAAAAoA84AAAAVVP7UWRrBFkWf5GPzWtIcodlLGc3aA9fDQAse4xOp34NACx7CU6nfg0ALHvb Vqd+DQAse5ROp34AAKIPHgAAAA0AAAAAAAQAAAABAAQAAAACAAQAAAADAAQAAAAEAAAAqg8KAAAA HQAAAAEAAAAAAA8ABPDQAAAAEgAK8AgAAAAEBAAAAAoAAIMAC/AwAAAAfwABAAUAgACMPuwBgQEE AAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABeDyABYAaKEA8AEfAQAAAA AADDCwgAAAACAAAABwHsAQ8ADfBYAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8UAAAAAgAA AAAAAAAAAAIAAAAAAAIADgAAAPgPBAAAAAAAAAAAAKoPEgAAAAEAAAABAAAAAAABAAAAAAAAAA8A BPDSAAAAEgAK8AgAAAAFBAAAAAoAAIMAC/AwAAAAfwABAAUAgACQSOwBgQEEAAAIgwEAAAAIvwEB ABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABeD7AH0A6KEA8AEfAQAAAAAADDCwgAAAADAAAA CQLsAQ8ADfBaAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgAAAEAAgAA AAAAAgAOAAAA+g8EAAAAAAAAAAAAqg8SAAAAAQAAAAEAAAAAAAEAAAAAAAAADwAE8NIAAAASAArw CAAAAAYEAAAACgAAgwAL8DAAAAB/AAEABQCAAOhH7AGBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/ AQEACQABAgIAAAgAABDwCAAAAF4PIBBgFYoQDwAR8BAAAAAAAMMLCAAAAAQAAAAIAuwBDwAN8FoA AAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAACAA4AAADY DwQAAAAAAAAAAACqDxIAAAABAAAAAQAAAAAAAQAAAAAAAAAPAATwSAAAABIACvAIAAAAAQQAAAAM AACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQAB ABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAAAA8AihMwAAAA AAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAOYNygFAKF+HIAC6DwwAAADY nqSLvouhiyFqf2cPAPAD/gUAAAEA8QMIAAAAAAAAgAAADTAPAAwEfgUAAA8AAvB2BQAAgAAI8AgA AAAHAAAAByAAAA8AA/AOBQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAA AAAgAAAFAAAADwAE8MgAAAASAArwCAAAAAIgAAAACgAAgwAL8DAAAAB/AAEABQCAAGQUQgKBAQQA AAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAAAAAABQByABDwAR8BAAAAAA AMMLCAAAAAAAAAAKAkICDwAN8FAAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxQAAAACAAAA AAAAAAAAAgAAAAAAAgAMAAAA+Q8EAAAAAAAAAAAAqg8KAAAAAgAAAAEAAAAAAA8ABPDUAAAAEgAK 8AgAAAADIAAAAAoAAIMAC/AwAAAAfwABAAUAgABYKUICgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI /wEBAAkAAQICAAAIAAAQ8AgAAAAAAI8J3xAgAQ8AEfAQAAAAAADDCwgAAAABAAAABwBCAg8ADfBc AAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgAAAIAAgAAAAAAAgAMAAAA +A8EAAAAAAAAAAAAqg8UAAAAAQAAAAEAAAAAAAEAAAABAAAAAAAPAATwZAAAABIACvAIAAAABCAA AAAKAABjAAvwJAAAAH8ABAEEAYcAAQAAAH8BAAABAL8BEQARAP8BCAAJAD8CAQABAAAAEPAIAAAA sAHQAhAOIAoPABHwEAAAAAAAwwsIAAAAAgAAAAUAQgIPAATw/AAAABIACvAIAAAABSAAAAAKAACD AAvwMAAAAH8AAQAFAIAAHAlCAoEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAA EPAIAAAAsAqwATAP0BQPABHwEAAAAAAAwwsIAAAAAwAAAAYCQgIPAA3whAAAAAAAnw8EAAAAAgAA AAAAoA84AAAAVVP7UWRrBFkWf5GPzWtIcodlLGc3aA9fDQAse4xOp34NACx7CU6nfg0ALHvbVqd+ DQAse5ROp34AAKIPHgAAAA0AAAAAAAQAAAABAAQAAAACAAQAAAADAAQAAAAEAAAAqg8KAAAAHQAA AAEAAAAAAA8ABPDYAAAAEgAK8AgAAAAGIAAAAAoAAJMAC/A2AAAAfwABAAUAgACIO0IChwACAAAA gQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABfFQAAUAd/Fg8AEfAQ AAAAAADDCwgAAAAEAAAACQJCAg8ADfBaAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8UAAAA AgAAAAAAAAAAAAIAAAAAAAIADAAAAPoPBAAAAAAAAAAAAKoPFAAAAAEAAAABAAAAAAABAAAAAQAA AAAADwAE8NoAAAASAArwCAAAAAcgAAAACgAAkwAL8DYAAAB/AAEABQCAAHBCQgKHAAIAAACBAQQA AAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAF8VjwnfEH8WDwAR8BAAAAAA AMMLCAAAAAUAAAAIAkICDwAN8FwAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAA AAAACAAAAgACAAAAAAACAAwAAADYDwQAAAAAAAAAAACqDxQAAAABAAAAAQAAAAAAAQAAAAEAAAAA AA8ABPBIAAAAEgAK8AgAAAABIAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwHevWgAlAGOn4sA vwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAA mZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA 6y4IAAAA6Q3KAXCbbyYPAO4DJAIAAAIA7wMYAAAAAAAAAA8QAAAAAAAAAAAAgAAAAAAHAAwwDwAM BJQBAAAPAALwjAEAACAACPAIAAAAAwAAAAMIAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAA AAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPByAAAAEgAK8AgAAAACCAAAIAIAAFMAC/Ae AAAAfwAAAAQAgAAEV+wBvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAAA+BbAB0BTcCA8AEfAQAAAA AADDCwgAAAAAAAAADwDsAQ8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMIAAAg AgAAUwAL8B4AAAB/AAAABACAAHxa7AG/AQEAAQD/AQEAAQABAwMEAAAAABDwCAAAAJAJYAMgE+AN DwAR8BAAAAAAAMMLCAAAAAEAAAAQAOwBDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAI AAAAAQgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQD CQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAA AA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAOYNygEwcmGH DwDuAyQCAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwAMMA8ADASUAQAADwAC8IwBAAAw AAjwCAAAAAMAAAADDAAADwAD8CQBAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIA CvAIAAAAAAwAAAUAAAAPAATwcgAAABIACvAIAAAAAgwAACACAABTAAvwHgAAAH8AAAAEAIAAQKbs Ab8BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAArQAgAWAVfQMPABHwEAAAAAAAwwsIAAAAAAAAAA0A 7AEPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAADDAAAIAIAAFMAC/AeAAAAfwAA AAQAgACs0+wBvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgAAAAJBCABYBUsDw8AEfAQAAAAAADDCwgA AAABAAAADgDsAQ8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAEMAAAADAAAgwAL 8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAH IAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8Q AAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAADmDcoBwMC7ig8A7gMkAgAAAgDvAxgA AAABAAAADQ4AAAAAAAAAAACAAAAAAAcADDAPAAwElAEAAA8AAvCMAQAAQAAI8AgAAAADAAAAAxAA AA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAQAAAFAAAA DwAE8HIAAAASAArwCAAAAAIQAAAgAgAAUwAL8B4AAAB/AAAABACAABCR7AG/AQAAAQD/AQAAAQAB AwIEAAAAABDwCAAAAK0AIAFgFX0DDwAR8BAAAAAAAMMLCAAAAAAAAAANAOwBDwAN8AwAAAAAAJ4P BAAAAAAAAAAPAATwcgAAABIACvAIAAAAAxAAACACAABTAAvwHgAAAH8AAAAEAIAAeNvsAb8BAAAB AP8BAAABAAEDAwQAAAAAEPAIAAAA8AMgAWAVEw8PABHwEAAAAAAAwwsIAAAAAQAAAA4A7AEPAA3w DAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABEAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEF AAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICA gAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABU ADEAMAAAAIsTEAAAAAAA6y4IAAAA5g3KAQAMCIsPAO4DJAIAAAIA7wMYAAAAAQAAAA0OAAAAAAAA AAAAgAAAAAAHAAwwDwAMBJQBAAAPAALwjAEAAGAACPAIAAAAAwAAAAMYAAAPAAPwJAEAAA8ABPAo AAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAGAAABQAAAA8ABPByAAAAEgAK8AgA AAACGAAAIAIAAFMAC/AeAAAAfwAAAAQAgAA8dUICvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACt ACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAADQBCAg8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIA AAASAArwCAAAAAMYAAAgAgAAUwAL8B4AAAB/AAAABACAAFxxQgK/AQAAAQD/AQAAAQABAwMEAAAA ABDwCAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAEICDwAN8AwAAAAAAJ4PBAAAAAEA AAAPAATwSAAAABIACvAIAAAAARgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1o AL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kA AJmZAJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAA AOsuCAAAAOgNygHQarDoDwDuAzACAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAQAABwAMMA8A DASgAQAADwAC8JgBAABwAAjwCAAAAAMAAAADHAAADwAD8DABAAAPAATwKAAAAAEACfAQAAAAAAAA AAAAAAAAAAAAAAAAAAIACvAIAAAAABwAAAUAAAAPAATweAAAABIACvAIAAAAAhwAACACAABjAAvw JAAAAH8AAAAEAIAAbDBCAr8BAAABAP8BAAABAAEDAgQAAIgDAAAAAAAAEPAIAAAArQAgAWAVfQMP ABHwEAAAAAAAwwsIAAAAAAAAAA0AQgIPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPB4AAAAEgAK8AgA AAADHAAAIAIAAGMAC/AkAAAAfwAAAAQAgAAkX0ICvwEAAAEA/wEAAAEAAQMDBAAAiAMAAAAAAAAQ 8AgAAAAJBCABYBUsDw8AEfAQAAAAAADDCwgAAAABAAAADgBCAg8ADfAMAAAAAACeDwQAAAABAAAA DwAE8EgAAAASAArwCAAAAAEcAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZ mQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADr LggAAAANDMoBUKw+mQ8A7gMkAgAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcADDAPAAwE lAEAAA8AAvCMAQAAUAAI8AgAAAADAAAAAxQAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAA AAAAAAAAAAAAAAACAArwCAAAAAAUAAAFAAAADwAE8HIAAAASAArwCAAAAAIUAAAgAgAAUwAL8B4A AAB/AAAABACAAOjd7AG/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAK0AIAFgFX0DDwAR8BAAAAAA AMMLCAAAAAAAAAANAOwBDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAxQAACAC AABTAAvwHgAAAH8AAAAEAIAAuOvsAb8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA8AMgAWAVEw8P ABHwEAAAAAAAwwsIAAAAAQAAAA4A7AEPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgA AAABFAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJ AAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAA DwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAA5g3KAYAYOosP APADaQIAAAEA8QMIAAAABQEAAAcADTAPAAwE6QEAAA8AAvDhAQAAkAAI8AgAAAADAAAAAyQAAA8A A/B5AQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAkAAAFAAAADwAE 8F4AAAASAArwCAAAAAIkAAAgAgAAUwAL8B4AAAB/AAQABAC/AQEAAQD/AQEAAQABAwQgAACIAwAA AAAAABDwCAAAALAB0AIQDiAKDwAR8BAAAAAAAMMLCAAAAAAAAAALAEICDwAE8NsAAAASAArwCAAA AAMkAAAgAgAAYwAL8CQAAAB/AAAABACAABxIQgK/AQAAAQD/AQAAAQABAwUgAACIAwAAAAAAABDw CAAAALAKQAKgDtAUDwAR8BAAAAAAAMMLCAAAAAEAAAAMAEICDwAN8G8AAAAAAJ8PBAAAAAIAAAAA AKgPWwAAAEtleSBub2RlOiB0aGUgdHJhbnNsYXRvciBvciB0aGUgdHVubmVsIHN0YXJ0IGFuZCBl bmQgcG9pbnQgaW4gZWFjaCB0cmFuc2l0aW9uIHRlY2hub2xvZ2llcy4PAATwSAAAABIACvAIAAAA ASQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB3r1oAJQBjp+LAL8BEgASAP8BAAAIAAQDCQAA AD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAAAA8A ihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAA8MygEQI6xNAABy FywAAAABAKAAAAAAABYMAADkGwAAEB4AADwgAADMJgAA3hUAAGgiAACUJAAA+CgAAAAA9Q8cAAAA BQEAAHMgAAMAAAAAaSsAAAEAAAAKAAAAAQDFMQ8A6APFCQAAAQDpAygAAACAFgAA4BAAAOAQAACA FgAABQAAAAoAAAAHAAAAAAAAAAEAAAAAAAABDwDyA2ABAB4AAAAQAAAA1NrGwcS7yc/P1Mq+AAAA AB4AAAAUAAAAzOy98sjLw/G547KltefMqAAAAAADAAAAklcAAAMAAAAXAAAAAwAAAAYAAAADAAAA AAAAAAMAAAAAAAAAAwAAAAAAAAADAAAADycLAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAA AAAAHhAAAAkAAAAGAAAAQXJpYWwABQAAAMvOzOUADQAAAMSsyM/J6LzGxKOw5QAlAAAAUmVjb21t ZW5kYXRpb24gb2YgSVB2NiBTZWN1cml0eSB3b3JrAAcAAABBZ2VuZGEAIAAAAFRoZSBPcmlnaW4g b2YgU2VjdXJpdHkgUHJvYmxlbXMADwAAAEN1cnJlbnQgU3RhdHVzABIAAABSZWNvbW1lbmRlZCBX b3JrcwAQAAAAT3BlbiBkaXNjdXNzaW9uAAwQAAAGAAAAHgAAAAsAAADS0dPDtcTX1szlAAMAAAAC AAAAHgAAABEAAADR3cq+zsS45cnovMbEo7DlAAMAAAABAAAAHgAAAAsAAAC7w7XGxqyx6sziAAMA AAAGAAAA////////oAAAAHgAAAAAAAAAAAAAAPYPIAAAABQAAABfwJHjblcAAAgA9AMDAAAAzOy9 8rXnzKgIAAAAKVklbTV18FMAAAAAAAAAAAAAAAAAAAAA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUA AAAKAAAABwAAAAAAAAABAAAAAAAAAQ8A8gNgAQAALwDIDwwAAAAwANIPBAAAAAAAAAAPANUHmAAA AAAAtw9EAAAAQQByAGkAYQBsAAAAuJYTANHGDDC4lhMAAAAAADAA0g9QqRMAUKkTAKwxmQDYlhMA T8UMMNiWEwAAAAAADwDVBwAABAAQALcPRAAAAItbU08AAGEAbAAAALiWEwDRxgwwuJYTAAAAAAAw ANIPUKkTAFCpEwCsMZkA2JYTAE/FDDDYlhMAAAAAAA8A1QeGAAQAAACkDwgAAACAAEAAAAAAAAAA pQ8MAAAAAAAACC4AAAAHAAAAAACpDwoAAAAHAAAAAgAECAkEQACjD24AAAAFAP/9PwAAACIgAABk AAAAAP8AAGQAAAAAAAAAAABAAgAAAAAHAAAA///vAAAAAAABAAAA//8SAAAAAAEAAAAFAAAgASAB AAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwTAAAAADwAA8LgAAAAA AAbwYAAAAAUoAAALAAAAHwAAAAgAAAABAAAABwAAAAIAAAAEAAAAAwAAAAQAAAAEAAAABAAAAAUA AAAEAAAABgAAAAQAAAAAAAAABAAAAAgAAAAIAAAAAAAAAAQAAAAKAAAABQAAAIMAC/AwAAAAgQEE AAAIgwEAAAAIhkEAAAAAvwEQABAAwAEBAAAIxUEAAAAA/wEIAAgAAQICAAAIQAAe8RAAAAAEAAAI AQAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAIAAAAAAAAAAAAAAAAAAIAAAAAADwDQBzMBAAAf ABQEHAAAAAAAFQQUAAAAupOw9gDKmju8y+EyAMqaOwEBAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9 AzQAAABFAAAAZAAAAEUAAABkAAAAAAAAALgvmQDwlhMAT8UMMAAAAAAAAAAAYP3//6b///8BABMA cAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABk AAAAZAAAAByXEwB2hwwwUKkTAIgxmQAAAAAAAAAAAAAAAAAAAAAAAAETAB8A/wMUAAAAAgAABAwA AAAAAAAAAAAAAAIAAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACL ExAAAAAAAA0ECAAAAHC1AABwtQAADwDwD3UIAAAAAPMDFAAAAAMAAAAAAAAAAgAAAAABAAAAAAAA AACfDwQAAAAGAAAAAACoDyQAAABSZWNvbW1lbmRhdGlvbiBvZiBJUHY2IFNlY3VyaXR5IHdvcmsQ AJ8PBAAAAAUAAAAAAKoPCgAAAAEAAAABAAAAAAAAAPMDFAAAAAQAAAAAAAAAAgAAAAEBAAAAAAAA AACfDwQAAAAAAAAAAACoDwYAAABBZ2VuZGEQAJ8PBAAAAAEAAAAAAKgPUAAAAFRoZSBPcmlnaW4g b2YgU2VjdXJpdHkgUHJvYmxlbXMNQ3VycmVudCBTdGF0dXMNUmVjb21tZW5kZWQgV29ya3MNT3Bl biBkaXNjdXNzaW9uAADzAxQAAAAFAAAAAAAAAAIAAAACAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8f AAAAVGhlIE9yaWdpbiBvZiBTZWN1cml0eSBQcm9ibGVtcxAAnw8EAAAAAQAAAAAAqA/VAAAATGlt aXRhdGlvbnMgaW4gdGhlIGRlc2lnbmF0aW9uIG9mIHNvbHV0aW9ucyBhbmQgcHJvdG9jb2xzDUJ1 Z3MgaW4gdGhlIGltcGxlbWVudChjb2RpbmcpIG9mIHByb3RvY29scw1TZWN1cml0eSBwcm9ibGVt cyBzaG93IHVwIGluIGRlcGxveW1lbnQgYW5kIHVzZSwgdGhlc2UgY2Fubm90IGJlIHRob3VnaHQg b3V0IGF0IGFsbCB3aGVuIGRlc2lnbmluZyB0aGUgcHJvdG9jb2xzAACqDxoAAABGAAAAAAAAABAA AAABAAAAAwCAAAAAAAAAAAAA8wMUAAAACAAAAAAAAAACAAAABAEAAAAAAAAAAJ8PBAAAAAAAAAAA AKgPDgAAAEN1cnJlbnQgU3RhdHVzEACfDwQAAAABAAAAAACoD2sBAABBIG51bWJlciBvZiBJUHY0 L0lQdjYgdHJhbnNpdGlvbiB0ZWNobm9sb2dpZXMsIGluY2x1ZGluZyB0dW5uZWwsIHRyYW5zbGF0 aW9uIGFuZCBkdWFsIHN0YWNrLCBhcmUgcHJvcG9zZWQuDUlQdjYgaGFzIG5vdCBiZWVuIGJ1c2lu ZXNzIHVzZWQgYW5kIGRlcGxveWVkIHdpbGRseS4NQ3VzdG9tZXJzIG1heSBub3QgYmUgcXVpdGUg Y2xlYXIgdGhleSB3aWxsIGNob29zZSB3aGljaCB0cmFuc2l0aW9uIHRlY2hub2xvZ3kvaXNlIGlu IGNvLWV4aXN0ZW5jZSBzdGFnZS4NU2VjdXJpdHkgc2hvdWxkIGJlIG9uZSBvZiB0aGUgbW9zdCBp bXBvcnRhbnQgZmFjdG9ycyBhcyB0aGUgZXZhbHVhdGlvbiBjcml0ZXJpYSBvZiB0aGUgY3VzdG9t ZXJzLiAAAKEPFgAAAGwBAAAAAAAQAABQAGwBAAAAAAIAHAAAAKoPGgAAAO4AAAAAAAAAAwAAAAEA AAADAHsAAAAAAAAAAADzAxQAAAAGAAAAAAAAAAIAAAADAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8R AAAAUmVjb21tZW5kZWQgV29ya3MQAJ8PBAAAAAEAAAAAAKgPMAEAAEVhY2ggdHJhbnNpdGlvbiB0 ZWNobm9sb2dpZXMgaGF2ZSBib3RoIHByb3MgYW5kIGNvbnMgaW4gc2VjdXJpdHkuDUEgZG9jdW1l bnQ6IHRocmVhdHMgYW5hbHlzaXMgZm9yIGRlcGxveW1lbnQgb2YgZWFjaCB0cmFuc2l0aW9uIHRl Y2hub2xvZ2llcy4NQSBkb2N1bWVudDogc2VjdXJpdHkgcmVxdWlyZW1lbnQgZm9yIGRlcGxveW1l bnQgb2YgZWFjaCB0cmFuc2l0aW9uIHRlY2hub2xvZ2llcy4NQSBkb2N1bWVudDogZnVuY3Rpb24g cmVjb21tZW5kYXRpb24gZm9yIGRldmljZXMgb2YgZWFjaCB0cmFuc2l0aW9uIHRlY2hub2xvZ2ll cy4AAPMDFAAAAAsAAAAAAAAAAgAAAAUBAAAAAAAAAACfDwQAAAAAAAAAAACoDw8AAABPcGVuIGRp c2N1c3Npb24AAKoPEgAAAA8AAAAAAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAoA/+AQAAVwBo AGEAdAAgAGkAcwAgAHQAaABlACAAdwBlAGkAZwBoAHQAIABvAGYAIABzAGUAYwB1AHIAaQB0AHkA IAB3AGgAZQBuACAAYwBoAG8AbwBzAGkAbgBnACAAdABoAGUAIAB0AHIAYQBuAHMAaQB0AGkAbwBu ACAAdABlAGMAaABuAG8AbABvAGcAeQA/AA0AVwBoAGUAdABoAGUAcgAgAGEAIAByAGUAcQB1AGkA cgBlAG0AZQBuAHQAIABkAG8AYwB1AG0AZQBuAHQAIABpAHMAIABuAGUAZQBkAGUAZAAgAHQAbwAg AHAAcgBvAHYAaQBkAGUAIABhACAAHCBjAGgAZQBjAGsAbABpAHMAdAAdICAAZgBvAHIAIABjAHUA cwB0AG8AbQBlAHIAcwAgAGYAbwByACAAZQB2AGEAbAB1AGEAdABpAG4AZwAgAGUAYQBjAGgAIABj AGEAbgBkAGkAZABhAHQAZQAgAHMAbwBsAHUAdABpAG8AbgAsACAAdwBoAGkAYwBoACAAbQBpAGcA aAB0ACAAaABlAGwAcAAgAGMAdQBzAHQAbwBtAGUAcgBzACAAYwBoAG8AbwBzAGUAIAB0AGgAZQAg AG0AbwBzAHQAIABzAHUAaQB0AGEAYgBsAGUAIABvAG4AZQAgAGUAYQBzAGkAZQByAC4AAACqDxoA AAD4AAAAAAAAAAcAAAABAAAAAAABAAAAAAAAAAAA6gMAAAAADwDuAyQCAAACAO8DGAAAAAEAAAAN DgAAAAAAAAAAAIAAAAAABwAMMA8ADASUAQAADwAC8IwBAAAwAAjwCAAAAAMAAAADDAAADwAD8CQB AAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAwAAAUAAAAPAATwcgAA ABIACvAIAAAAAgwAACACAABTAAvwHgAAAH8AAAAEAIAApEfUAb8BAAABAP8BAAABAAEDAgQAAAAA EPAIAAAArQAgAWAVfQMPABHwEAAAAAAAwwsIAAAAAAAAAA0A1AEPAA3wDAAAAAAAng8EAAAAAAAA AA8ABPByAAAAEgAK8AgAAAADDAAAIAIAAFMAC/AeAAAAfwAAAAQAgABoRtQBvwEAAAEA/wEAAAEA AQMDBAAAAAAQ8AgAAAAJBCABYBUsDw8AEfAQAAAAAADDCwgAAAABAAAADgDUAQ8ADfAMAAAAAACe DwQAAAABAAAADwAE8EgAAAASAArwCAAAAAEMAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6f iwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC7 4OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAA ixMQAAAAAADrLggAAADmDcoBwMC7ig8A7gMkAgAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAA AAcADDAPAAwElAEAAA8AAvCMAQAAUAAI8AgAAAADAAAAAxQAAA8AA/AkAQAADwAE8CgAAAABAAnw EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAUAAAFAAAADwAE8HIAAAASAArwCAAAAAIUAAAg AgAAUwAL8B4AAAB/AAAABACAAGSa1AG/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAK0AIAFgFX0D DwAR8BAAAAAAAMMLCAAAAAAAAAANANQBDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAI AAAAAxQAACACAABTAAvwHgAAAH8AAAAEAIAAvJ7UAb8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA 8AMgAWAVEw8PABHwEAAAAAAAwwsIAAAAAQAAAA4A1AEPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBI AAAAEgAK8AgAAAABFAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA /wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwA AA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAA 5g3KAYAYOosPAO4DJAIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHAAwwDwAMBJQBAAAP AALwjAEAAKAACPAIAAAAAwAAAAQoAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAA AAAAAAAAAgAK8AgAAAAAKAAABQAAAA8ABPByAAAAEgAK8AgAAAACKAAAIAIAAFMAC/AeAAAAfwAA AAQAgACMHAMEvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgA AAAAAAAADQADBA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMoAAAgAgAAUwAL 8B4AAAB/AAAABACAAHT01AG/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAPADIAFgFRMPDwAR8BAA AAAAAMMLCAAAAAEAAAAOAAMEDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAASgA AAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8D AQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAAAA8AihMw AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAACkOygGQvf43AAByFyAA AAABABAA9jcAAAQAEABCRAAABgAQAG5GAAALABAAmkgAAAAA9Q8cAAAABQEAAHMgAAPSNwAAxkoA AAEAAAALAAAAAQDFMQ8A6ANEDAAAAQDpAygAAACAFgAA4BAAAOAQAACAFgAABQAAAAoAAAAHAAAA AAAAAAEAAAAAAAABDwDyA2ABAAAvAMgPDAAAADAA0g8EAAAAAAAAAA8A1QeYAAAAAAC3D0QAAABB AHIAaQBhAGwAAAC4lhMA0cYMMLiWEwAAAAAAMADSD1CpEwBQqRMArDGZANiWEwBPxQww2JYTAAAA AAAPANUHAAAEABAAtw9EAAAAi1tTTwAAYQBsAAAAuJYTANHGDDC4lhMAAAAAADAA0g9QqRMAUKkT AKwxmQDYlhMAT8UMMNiWEwAAAAAADwDVB4YABAAAAKQPCAAAAIAAQAAAAAAAAAClDwwAAAAAAAAI LgAAAAcAAAAAAKkPCgAAAAcAAAACAAQICQRAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAA/wAAZAAA AAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAAEAAAD//xIAAAAAAQAAAAUAACABIAEAAAAAAAUAAEAC QAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwALBMAAAAAPAADwuAAAAAAABvBgAAAABSgA AAsAAAAfAAAACAAAAAEAAAAHAAAAAgAAAAQAAAADAAAABAAAAAQAAAAEAAAABQAAAAQAAAAGAAAA BAAAAAAAAAAEAAAACAAAAAgAAAAAAAAABAAAAAoAAAAFAAAAgwAL8DAAAACBAQQAAAiDAQAAAAiG QQAAAAC/ARAAEADAAQEAAAjFQQAAAAD/AQgACAABAgIAAAhAAB7xEAAAAAQAAAgBAAAIAgAACPcA ABAfAPAPHAAAAAAA8wMUAAAAAgAAAAAAAAAAAAAAAAAAgAAAAAAPANAHMwEAAB8AFAQcAAAAAAAV BBQAAAC6k7D2AMqaO7zL4TIAypo7AQEAAA8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAAEUAAABk AAAARQAAAGQAAAAAAAAAuC+ZAPCWEwBPxQwwAAAAAAAAAABg/f//pv///wEAEwBwAPsDCAAAAAAA AABwCAAAcAD7AwgAAAABAAAAQAsAAB8AEwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAAHJcT AHaHDDBQqRMAiDGZAAAAAAAAAAAAAAAAAAAAAAAAARMAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAA AgAAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAADQQI AAAAcLUAAHC1AAAPAPAPdQgAAAAA8wMUAAAAAwAAAAAAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYA AAAAAKgPJAAAAFJlY29tbWVuZGF0aW9uIG9mIElQdjYgU2VjdXJpdHkgd29yaxAAnw8EAAAABQAA AAAAqg8KAAAAAQAAAAEAAAAAAAAA8wMUAAAABAAAAAAAAAACAAAAAQEAAAAAAAAAAJ8PBAAAAAAA AAAAAKgPBgAAAEFnZW5kYRAAnw8EAAAAAQAAAAAAqA9QAAAAVGhlIE9yaWdpbiBvZiBTZWN1cml0 eSBQcm9ibGVtcw1DdXJyZW50IFN0YXR1cw1SZWNvbW1lbmRlZCBXb3Jrcw1PcGVuIGRpc2N1c3Np b24AAPMDFAAAAAUAAAAAAAAAAgAAAAIBAAAAAAAAAACfDwQAAAAAAAAAAACoDx8AAABUaGUgT3Jp Z2luIG9mIFNlY3VyaXR5IFByb2JsZW1zEACfDwQAAAABAAAAAACoD9UAAABMaW1pdGF0aW9ucyBp biB0aGUgZGVzaWduYXRpb24gb2Ygc29sdXRpb25zIGFuZCBwcm90b2NvbHMNQnVncyBpbiB0aGUg aW1wbGVtZW50KGNvZGluZykgb2YgcHJvdG9jb2xzDVNlY3VyaXR5IHByb2JsZW1zIHNob3cgdXAg aW4gZGVwbG95bWVudCBhbmQgdXNlLCB0aGVzZSBjYW5ub3QgYmUgdGhvdWdodCBvdXQgYXQgYWxs IHdoZW4gZGVzaWduaW5nIHRoZSBwcm90b2NvbHMAAKoPGgAAAEYAAAAAAAAAEAAAAAEAAAADAIAA AAAAAAAAAADzAxQAAAAIAAAAAAAAAAIAAAAEAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8OAAAAQ3Vy cmVudCBTdGF0dXMQAJ8PBAAAAAEAAAAAAKgPawEAAEEgbnVtYmVyIG9mIElQdjQvSVB2NiB0cmFu c2l0aW9uIHRlY2hub2xvZ2llcywgaW5jbHVkaW5nIHR1bm5lbCwgdHJhbnNsYXRpb24gYW5kIGR1 YWwgc3RhY2ssIGFyZSBwcm9wb3NlZC4NSVB2NiBoYXMgbm90IGJlZW4gYnVzaW5lc3MgdXNlZCBh bmQgZGVwbG95ZWQgd2lsZGx5Lg1DdXN0b21lcnMgbWF5IG5vdCBiZSBxdWl0ZSBjbGVhciB0aGV5 IHdpbGwgY2hvb3NlIHdoaWNoIHRyYW5zaXRpb24gdGVjaG5vbG9neS9pc2UgaW4gY28tZXhpc3Rl bmNlIHN0YWdlLg1TZWN1cml0eSBzaG91bGQgYmUgb25lIG9mIHRoZSBtb3N0IGltcG9ydGFudCBm YWN0b3JzIGFzIHRoZSBldmFsdWF0aW9uIGNyaXRlcmlhIG9mIHRoZSBjdXN0b21lcnMuIAAAoQ8W AAAAbAEAAAAAABAAAFAAbAEAAAAAAgAcAAAAqg8aAAAA7gAAAAAAAAADAAAAAQAAAAMAewAAAAAA AAAAAPMDFAAAAAYAAAAAAAAAAgAAAAMBAAAAAAAAAACfDwQAAAAAAAAAAACoDxEAAABSZWNvbW1l bmRlZCBXb3JrcxAAnw8EAAAAAQAAAAAAqA8wAQAARWFjaCB0cmFuc2l0aW9uIHRlY2hub2xvZ2ll cyBoYXZlIGJvdGggcHJvcyBhbmQgY29ucyBpbiBzZWN1cml0eS4NQSBkb2N1bWVudDogdGhyZWF0 cyBhbmFseXNpcyBmb3IgZGVwbG95bWVudCBvZiBlYWNoIHRyYW5zaXRpb24gdGVjaG5vbG9naWVz Lg1BIGRvY3VtZW50OiBzZWN1cml0eSByZXF1aXJlbWVudCBmb3IgZGVwbG95bWVudCBvZiBlYWNo IHRyYW5zaXRpb24gdGVjaG5vbG9naWVzLg1BIGRvY3VtZW50OiBmdW5jdGlvbiByZWNvbW1lbmRh dGlvbiBmb3IgZGV2aWNlcyBvZiBlYWNoIHRyYW5zaXRpb24gdGVjaG5vbG9naWVzLgAA8wMUAAAA CwAAAAAAAAACAAAABQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPDwAAAE9wZW4gZGlzY3Vzc2lvbgAA qg8SAAAADwAAAAAAAAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACgD/4BAABXAGgAYQB0ACAAaQBz ACAAdABoAGUAIAB3AGUAaQBnAGgAdAAgAG8AZgAgAHMAZQBjAHUAcgBpAHQAeQAgAHcAaABlAG4A IABjAGgAbwBvAHMAaQBuAGcAIAB0AGgAZQAgAHQAcgBhAG4AcwBpAHQAaQBvAG4AIAB0AGUAYwBo AG4AbwBsAG8AZwB5AD8ADQBXAGgAZQB0AGgAZQByACAAYQAgAHIAZQBxAHUAaQByAGUAbQBlAG4A dAAgAGQAbwBjAHUAbQBlAG4AdAAgAGkAcwAgAG4AZQBlAGQAZQBkACAAdABvACAAcAByAG8AdgBp AGQAZQAgAGEAIAAcIGMAaABlAGMAawBsAGkAcwB0AB0gIABmAG8AcgAgAGMAdQBzAHQAbwBtAGUA cgBzACAAZgBvAHIAIABlAHYAYQBsAHUAYQB0AGkAbgBnACAAZQBhAGMAaAAgAGMAYQBuAGQAaQBk AGEAdABlACAAcwBvAGwAdQB0AGkAbwBuACwAIAB3AGgAaQBjAGgAIABtAGkAZwBoAHQAIABoAGUA bABwACAAYwB1AHMAdABvAG0AZQByAHMAIABjAGgAbwBvAHMAZQAgAHQAaABlACAAbQBvAHMAdAAg AHMAdQBpAHQAYQBiAGwAZQAgAG8AbgBlACAAZQBhAHMAaQBlAHIALgAAAKoPGgAAAPgAAAAAAAAA BwAAAAEAAAAAAAEAAAAAAAAAAADqAwAAAAAAAHIXCAAAAAEAEAASSwAAAAD1DxwAAAAFAQAAcyAA A+5KAABeVwAAAQAAAAsAAAAPAMUxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAA AA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAADEAAAD+////GAAAABkAAAAaAAAA GwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAA/v////////// ///////////////////////////////9////MAAAAP7///8yAAAAMwAAADQAAAA1AAAANgAAABcA AAD+////OQAAADoAAAA7AAAAPAAAAD0AAAAWAAAA//////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAQjYFkm0/PEYbqAKoAuSnoAAAAAAAAAAAA AAAAoBod5yoOygE4AAAAAA4AAAAAAABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAP///////////////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADcAAAA4AAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4A ZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAQAAAP////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgLAAAAAAAAUABvAHcA ZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACgAAgECAAAABAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA klcAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABp AG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAC0AAABsAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAvAMgPDAAAADAA0g8EAAAAAAAAAA8A1QeYAAAAAAC3D0QAAABBAHIAaQBhAGwAAAC4 lhMA0cYMMLiWEwAAAAAAMADSD1CpEwBQqRMArDGZANiWEwBPxQww2JYTAAAAAAAPANUHAAAEABAA tw9EAAAAi1tTTwAAYQBsAAAAuJYTANHGDDC4lhMAAAAAADAA0g9QqRMAUKkTAKwxmQDYlhMAT8UM MNiWEwAAAAAADwDVB4YABAAAAKQPCAAAAIAAQAAAAAAAAAClDwwAAAAAAAAILgAAAAcAAAAAAKkP CgAAAAcAAAACAAQICQRAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAA/wAAZAAAAAAAAAAAAEACAAAA AAcAAAD//+8AAAAAAAEAAAD//xIAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGAD YAMAAAAAAAUAAIAEgAQAAAAADwALBLgAAAAPAADwsAAAAAAABvBYAAAABCQAAAoAAAAcAAAABwAA AAEAAAAHAAAAAgAAAAQAAAADAAAABAAAAAQAAAAEAAAABQAAAAQAAAAGAAAABAAAAAAAAAAEAAAA CAAAAAgAAAAAAAAABAAAAIMAC/AwAAAAgQEEAAAIgwEAAAAIhkEAAAAAvwEQABAAwAEBAAAIxUEA AAAA/wEIAAgAAQICAAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAIA AAAAAAAAAAAAAAAAAIAAAAAADwDQBzMBAAAfABQEHAAAAAAAFQQUAAAAupOw9gDKmju8y+EyAMqa OwEBAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABFAAAAZAAAAEUAAABkAAAAAAAAALgvmQDw lhMAT8UMMAAAAAAAAAAAVvv//6b///8BABMAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEAL AAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAAByXEwB2hwwwUKkTAIgxmQAAAAAAAAAA AAAAAAAAAAAAAAETAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAPAIgTOAAAAA8AihMwAAAA AAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAA0ECAAAAHC1AABwtQAADwDwD/4FAAAA APMDFAAAAAMAAAAAAAAAAgAAAAABAAAAAAAAAACfDwQAAAAGAAAAAACoDyQAAABSZWNvbW1lbmRh dGlvbiBvZiBJUHY2IFNlY3VyaXR5IHdvcmsQAJ8PBAAAAAUAAAAAAKoPCgAAAAEAAAABAAAAAAAA APMDFAAAAAQAAAAAAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDwYAAABBZ2VuZGEQAJ8P BAAAAAEAAAAAAKgPQAAAAFRoZSBPcmlnaW4gb2YgU2VjdXJpdHkgUHJvYmxlbXMNQ3VycmVudCBT dGF0dXMNUmVjb21tZW5kZWQgV29ya3MAAKoPGgAAACAAAAAAAAAADgAAAAEAAAAAABMAAAAAAAAA AADzAxQAAAAFAAAAAAAAAAIAAAACAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8fAAAAVGhlIE9yaWdp biBvZiBTZWN1cml0eSBQcm9ibGVtcxAAnw8EAAAAAQAAAAAAqA/VAAAATGltaXRhdGlvbnMgaW4g dGhlIGRlc2lnbmF0aW9uIG9mIHNvbHV0aW9ucyBhbmQgcHJvdG9jb2xzDUJ1Z3MgaW4gdGhlIGlt cGxlbWVudChjb2RpbmcpIG9mIHByb3RvY29scw1TZWN1cml0eSBwcm9ibGVtcyBzaG93IHVwIGlu IGRlcGxveW1lbnQgYW5kIHVzZSwgdGhlc2UgY2Fubm90IGJlIHRob3VnaHQgb3V0IGF0IGFsbCB3 aGVuIGRlc2lnbmluZyB0aGUgcHJvdG9jb2xzAACqDxoAAABGAAAAAAAAABAAAAABAAAAAwCAAAAA AAAAAAAA8wMUAAAACAAAAAAAAAACAAAABAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPDgAAAEN1cnJl bnQgU3RhdHVzEACfDwQAAAABAAAAAACoD2sBAABBIG51bWJlciBvZiBJUHY0L0lQdjYgdHJhbnNp dGlvbiB0ZWNobm9sb2dpZXMsIGluY2x1ZGluZyB0dW5uZWwsIHRyYW5zbGF0aW9uIGFuZCBkdWFs IHN0YWNrLCBhcmUgcHJvcG9zZWQuDUlQdjYgaGFzIG5vdCBiZWVuIGJ1c2luZXNzIHVzZWQgYW5k IGRlcGxveWVkIHdpbGRseS4NQ3VzdG9tZXJzIG1heSBub3QgYmUgcXVpdGUgY2xlYXIgdGhleSB3 aWxsIGNob29zZSB3aGljaCB0cmFuc2l0aW9uIHRlY2hub2xvZ3kvaXNlIGluIGNvLWV4aXN0ZW5j ZSBzdGFnZS4NU2VjdXJpdHkgc2hvdWxkIGJlIG9uZSBvZiB0aGUgbW9zdCBpbXBvcnRhbnQgZmFj dG9ycyBhcyB0aGUgZXZhbHVhdGlvbiBjcml0ZXJpYSBvZiB0aGUgY3VzdG9tZXJzLiAAAKEPFgAA AGwBAAAAAAAQAABQAGwBAAAAAAIAHAAAAKoPGgAAAO4AAAAAAAAAAwAAAAEAAAADAHsAAAAAAAAA AADzAxQAAAAGAAAAAAAAAAIAAAADAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8RAAAAUmVjb21tZW5k ZWQgV29ya3MQAJ8PBAAAAAEAAAAAAKgPNAEAAEVhY2ggdHJhbnNpdGlvbiB0ZWNobm9sb2dpZXMg aGF2ZSBib3RoIHByb3MgYW5kIGNvbnMgaW4gc2VjdXJpdHkuDUEgZG9jdW1lbnQ6IHRocmVhdHMg YW5hbHlzaXMgZm9yIGRlcGxveW1lbnQgb2YgZWFjaCB0cmFuc2l0aW9uIHRlY2hub2xvZ2llcy4N QSBkb2N1bWVudDogc2VjdXJpdHkgcmVxdWlyZW1lbnQgZm9yIGRlcGxveW1lbnQgb2YgZWFjaCB0 cmFuc2l0aW9uIHRlY2hub2xvZ2llcy4NQSBkb2N1bWVudDogZnVuY3Rpb24gcmVjb21tZW5kYXRp b24gZm9yIGRlcGxveW1lbnQgb2YgZWFjaCB0cmFuc2l0aW9uIHRlY2hub2xvZ2llcy4gAADqAwAA AAAPAO4DJAIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHAAwwDwAMBJQBAAAPAALwjAEA ADAACPAIAAAAAwAAAAMMAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAA AgAK8AgAAAAADAAABQAAAA8ABPByAAAAEgAK8AgAAAACDAAAIAIAAFMAC/AeAAAAfwAAAAQAgACk R9QBvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAA DQDUAQ8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMMAAAgAgAAUwAL8B4AAAB/ AAAABACAAGhG1AG/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAAkEIAFgFSwPDwAR8BAAAAAAAMML CAAAAAEAAAAOANQBDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAQwAAAAMAACD AAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA 8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6 DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAOYNygHAwLuKAAByFxAAAAABABAA wSsAAAQAEACONQAAAAD1DxwAAAADAQAAcyAAA50rAAC6NwAAAQAAAAoAAAAPAMUxDwDoA0QMAAAB AAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAA DwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAd AAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsA AAAsAAAA/v///y4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAAP7////+//////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAA6AoAAAsAAAAB AAAAYAAAAAIAAABoAAAABAAAAJgAAAAIAAAArAAAAAkAAADAAAAAEgAAAMwAAAAKAAAA8AAAAAwA AAD8AAAADQAAAAgBAAAPAAAAFAEAABEAAAAcAQAAAgAAAKgDAAAeAAAAKAAAAFJlY29tbWVuZGF0 aW9uIG9mIElQdjYgU2VjdXJpdHkgd29yawAAAAAeAAAADAAAAMzsvfK158yoAAAAAB4AAAAMAAAA zOy98rXnzKgAAAAAHgAAAAQAAAAxNAAAHgAAABwAAABNaWNyb3NvZnQgT2ZmaWNlIFBvd2VyUG9p bnQAQAAAAPBkQhwQAAAAQAAAAOC96vHnDcoBQAAAALDuFecqDsoBAwAAAMEAAABHAAAAxAkAAP// //8DAAAACACJEGcMAAABAAkAAAPZBAAABQCwAwAAAACwAwAAJgYPAFYHV01GQwEAAAAAAAEA9lQA AAAAAQAAADQHAAAAAAAANAcAAAEAAABsAAAA//////////+gAAAAeAAAAAAAAAAAAAAAoA8AALgL AAAgRU1GAAABADQHAAAmAAAAAgAAAAAAAAAAAAAAAAAAAAAFAAAgAwAAQAEAAMgAAAAAAAAAAAAA AAAAAAAA4gQAQA0DAEYAAAAoAAAAHAAAAEdESUMCAAAA/////wAAAACgAAAAeAAAAAAAAAAhAAAA CAAAAGIAAAAMAAAAAQAAACQAAAAkAAAAAACAPQAAAAAAAAAAAACAPQAAAAAAAAAAAgAAACUAAAAM AAAAAAAAgCUAAAAMAAAACAAAgFYAAAAwAAAA//////////+gAAAAeAAAAAUAAAD4//j/+P94B/gJ eAf4Cfj/+P/4/yUAAAAMAAAABwAAgCUAAAAMAAAAAAAAgCQAAAAkAAAAAACAQQAAAAAAAAAAAACA QQAAAAAAAAAAAgAAACIAAAAMAAAA/////0YAAAAUAAAACAAAAEdESUMDAAAARgAAACgAAAAcAAAA R0RJQwIAAAAHAAAAbAAAAC4AAAB3AAAAAAAAAEYAAAAUAAAACAAAAEdESUMDAAAARgAAACgAAAAc AAAAR0RJQwIAAAA2AAAAbAAAAGoAAAB3AAAAAAAAAEYAAAAUAAAACAAAAEdESUMDAAAARgAAACgA AAAcAAAAR0RJQwIAAAALAAAAJAAAAJUAAABAAAAAAAAAAEYAAAAUAAAACAAAAEdESUMDAAAAUgAA AHABAAABAAAA9v///wAAAAAAAAAAAAAAAJABAAAAAAAAAEAAAEEAcgBpAGEAbAAAAAAAAABxAAAA AQAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFiamQAAABMAkJuZAOiomQCs rpkAAAAAAOiomQDVDwAAVM4TAPmL5jAAAAAAFQAAAAEAAAAwzhMAJM8TAJCbmQD0zhMAaK2ZAOio mQCsrpkArK6ZAODREwADAAAAAwAAAAMAAAABAAAAlM4TANWJ5jABAAAAAAAAABUAAAABAAAAAAAA AAAAAAABAAAAJM8TAOTPEwABAAAAFwAAAAAAAAA11wEwKNQTAAAAAAAQlJkAAAAAABYAAAABAAAA 8M4TAOTPEwAAAAAAkJuZAKyumQAAAAAAHM8TAPKN5jBAzxMAAAAAABYAAAABAAAAJM8TAPDOEwDk zxMAAAAAADiemQAsn5kAZHYACAAAAAAlAAAADAAAAAEAAAAWAAAADAAAABgAAAASAAAADAAAAAEA AAAYAAAADAAAAAAAAAJUAAAA2AAAABkAAAAmAAAAiQAAADIAAAABAAAAAADIQQAAyEEZAAAAMAAA ABcAAABMAAAAAAAAAAAAAAAAAAAA//////////98AAAAUgBlAGMAbwBtAG0AZQBuAGQAYQB0AGkA bwBuACAAbwBmACAASQBQAHYANgAgAAAABwAAAAYAAAAFAAAABQAAAAgAAAAJAAAABQAAAAUAAAAG AAAABgAAAAIAAAACAAAABgAAAAUAAAADAAAABgAAAAIAAAADAAAAAwAAAAYAAAAFAAAABgAAAAIA AAAWAAAADAAAAAAAAAAlAAAADAAAAA0AAIAoAAAADAAAAAEAAABSAAAAcAEAAAEAAAD2////AAAA AAAAAAAAAAAAkAEAAAAAAAAAQAAAQQByAGkAYQBsAAAAAAAAAEAAAAABAAAAAAAAAAAAAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWJqZAAAAAAAAAAAAkAEAAAAAAIYQ0hMAi1tTTwAAYQF4 AXgBCgAAAAAAAAAAAAAABDCZAAUAAADAzRMAKNQTAAEAAABAFQEK9v///wAAAAAAAAAAAAAAAJAB AAAAAACGAAAAAItbU08AAJkAAAAAhgoNAjAJBJkAANbUAeiomQANAAAAAAATAODREwBoxU8wAAAA AMDOEwD69dIwpJOZADXXATAo1BMAAAAAABCUmQAAAAAA6KiZAFyumQDUrpkAmNfUAQAA1AFAopkA DgAAAAIAAADczhMAf/TSMAIAAAAMopkA6KiZAAAAAAAAAAAA+M4TANzz0jAAAAAAOJ6ZAIifmQBk dgAIAAAAACUAAAAMAAAAAQAAABYAAAAMAAAAGAAAABIAAAAMAAAAAQAAABgAAAAMAAAAAAAAAlQA AACcAAAAMwAAADIAAABtAAAAPgAAAAEAAAAAAMhBAADIQTMAAAA8AAAADQAAAEwAAAAAAAAAAAAA AAAAAAD//////////2gAAABTAGUAYwB1AHIAaQB0AHkAIAB3AG8AcgBrAAAABwAAAAYAAAAEAAAA BgAAAAMAAAACAAAAAwAAAAUAAAADAAAABwAAAAYAAAADAAAABAAAABYAAAAMAAAAAAAAACUAAAAM AAAADQAAgCgAAAAMAAAAAQAAAA4AAAAUAAAAAAAAABAAAAAUAAAABAAAAAMBCAAFAAAACwIAAAAA BQAAAAwCeACgAAMAAAAeAAcAAAD8AgAA////AAAABAAAAC0BAAAIAAAA+gIFAAAAAAD///8ABAAA AC0BAQAOAAAAJAMFAP///////3gAoAB4AKAA////////CAAAAPoCAAAAAAAAAAAAAAQAAAAtAQIA BAAAAC0BAAAEAAAAJwH//xwAAAD7Avb/AAAAAAAAkAEAAAAAAEAAAEFyaWFsAAAAcQABAAAAAAAB AAAAAAAAAAAAAAAAAPKfBAAAAC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAioAAAAyCjAA GQAXAAAAUmVjb21tZW5kYXRpb24gb2YgSVB2NiAABwAGAAUABQAIAAkABQAFAAYABgACAAIABgAF AAMABgACAAMAAwAGAAUABgACAAQAAAAuAQAAHAAAAPsCEAAHAAAAAAC8AgAAAIYBAgIiU3lzdGVt AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAADwAQMAHAAAAPsC9v8AAAAAAACQ AQAAAAAAQAAAQXJpYWwAAABAAAEAAAAAAAEAAAAAAAAAAAAAAAAA8p8EAAAALQEDAAQAAAAuARgA BAAAAAIBAQAFAAAACQIAAAACGwAAADIKPAAzAA0AAABTZWN1cml0eSB3b3JrAwcABgAEAAYAAwAC AAMABQADAAcABgADAAQABAAAAC4BAAAEAAAALQEEAAQAAADwAQMAAwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAA AALVzdWcLhsQk5cIACss+a4wAAAAPAIAABAAAAABAAAAiAAAAAMAAACQAAAADwAAAKgAAAAEAAAA xAAAAAYAAADMAAAABwAAANQAAAAIAAAA3AAAAAkAAADkAAAACgAAAOwAAAAXAAAA9AAAAAsAAAD8 AAAAEAAAAAQBAAATAAAADAEAABYAAAAUAQAADQAAABwBAAAMAAAA3QEAAAIAAACoAwAA --Apple-Mail-40--195521586-- From joelja@bogus.com Mon Jul 27 05:10:47 2009 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 4DEED28C180 for ; Mon, 27 Jul 2009 05:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 ls2cBA95m+BN for ; Mon, 27 Jul 2009 05:10:46 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id F3AE728C150 for ; Mon, 27 Jul 2009 05:10:45 -0700 (PDT) Received: from [130.129.22.14] (dhcp-160e.meeting.ietf.org [130.129.22.14]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n6RC95rL084300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jul 2009 12:10:04 GMT (envelope-from joelja@bogus.com) Message-ID: <4A6D98AC.4060100@bogus.com> Date: Mon, 27 Jul 2009 14:08:12 +0200 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.22 (X11/20090710) MIME-Version: 1.0 To: Fred Baker References: <633E561F-48D1-42DE-A310-9E77DB0A87F1@cisco.com> In-Reply-To: <633E561F-48D1-42DE-A310-9E77DB0A87F1@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Mon, 27 Jul 2009 12:10:15 +0000 (UTC) X-Mailman-Approved-At: Mon, 27 Jul 2009 05:24:29 -0700 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man-ads@tools.ietf.org, secdir@ietf.org, Kurt Erik Lindqvist , Joe Abley , Softwire Chairs , v6ops-ads@tools.ietf.org, softwire-ads@tools.ietf.org, Tina TSOU , behave-ads@tools.ietf.org, Behave Chairs Subject: Re: [secdir] Discussion from the Security Directorate 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, 27 Jul 2009 12:10:47 -0000 I'd probably tune the slides a bit still: Security problems show up in deployment and use, these cannot be thought out at all when designing the protocols Is an assertion you'll get pushback on. we have signficant operational experience with variations on many of the proposed or deployed transition mechanisms. necessarily that experience informs both our current thinking and the desirability of any particular approach. bump in the wire type transition technologies certainly are an area potential concern for opsec Fred Baker wrote: > Thanks, Tina. I will add this to the IPv6 Operations agenda, probably > during our second session Tuesday. > > You will note that I am copying the chairs and ADs from several working > groups. The reason is that the primary thrust of the comments you are > making apply to work being done in those working groups. Slide 5 > specifically requests a threat analysis, security assessment, and > "function recommendation" on each transition technology; these are in > fact being done in behave and softwires. I mention 6man because > marketing blather from the IPv6 form makes security claims for IPv6, > which it would be good if that working group clarified. > > I do have to ask specifically what the Security Directorate hopes to > find in the three documents that have been requested for each of these > various technologies. What, specifically, is a "function > recommendation"? A threat analysis is a statement that there exist a set > of possible threats. Is a security assessment a statement about how > those threats are responded to? What, if the WGs don't produce it, is > going to leave the Security Directorate feeling ill-used? > > On Jul 27, 2009, at 12:56 PM, Tina TSOU wrote: > >> >> B. R. >> ">http://tinatsou.weebly.com/contact.html > >> Begin forwarded message: >> >>> From: "Romascanu, Dan (Dan)" >>> Date: July 27, 2009 7:52:20 AM GMT+02:00 >>> To: Ron Bonica >>> Cc: Tina TSOU >>> Subject: FW: [OPS-DIR] Reminder: OPS-DIR working lunch >>> >>> Ron, >>> >>> This looks more like an opsec (who are not meeting this time) or v6ops >>> subject. >>> >>> Dan >>> >>> >>> -----Original Message----- >>> From: Tina TSOU [mailto:tena@huawei.com] >>> Sent: Monday, July 27, 2009 12:02 AM >>> To: Romascanu, Dan (Dan) >>> Subject: Re: [OPS-DIR] Reminder: OPS-DIR working lunch >>> >>> Hi Dan, >>> Could this be discussed at OPS-DIR working lunch? >> >> >> From william.polk@nist.gov Mon Jul 27 05:56:46 2009 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 101593A6A82 for ; Mon, 27 Jul 2009 05:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.758 X-Spam-Level: X-Spam-Status: No, score=-6.758 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, 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 HeYHGl6E2z91 for ; Mon, 27 Jul 2009 05:56:45 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 27EBE3A6C70 for ; Mon, 27 Jul 2009 05:56:45 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n6RCudU2030357 for ; Mon, 27 Jul 2009 08:56:39 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Mon, 27 Jul 2009 08:56:39 -0400 From: "Polk, William T." To: "secdir@ietf.org" Date: Mon, 27 Jul 2009 08:55:52 -0400 Thread-Topic: Food Update Thread-Index: AcoOuCBY/dO8YRIUSOiZQy6nyAAxlAAAXJLp Message-ID: References: <7E1D2868-579C-4BF5-8867-8FEAA6699BF4@amsl.com> In-Reply-To: <7E1D2868-579C-4BF5-8867-8FEAA6699BF4@amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov X-Mailman-Approved-At: Mon, 27 Jul 2009 05:57:59 -0700 Subject: [secdir] FW: Food Update 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, 27 Jul 2009 12:56:46 -0000 Good news regarding the secdir lunch! ________________________________________ From: iesg-bounces@ietf.org [iesg-bounces@ietf.org] On Behalf Of Alexa Morr= is [amorris@amsl.com] Sent: Monday, July 27, 2009 8:45 AM To: The IESG Subject: Food Update The conference center has relented, and our attendees are now permitted to bring in food from outside. Food is still not permitted in the Congresshall A,B or C rooms. Whew. -Alexa ----------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com From shanna@juniper.net Tue Jul 28 02:14:13 2009 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 197943A6ADE; Tue, 28 Jul 2009 02:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGDoLRgBW+xc; Tue, 28 Jul 2009 02:14:12 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id E89F43A6D3C; Tue, 28 Jul 2009 02:13:57 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSm7BVtGbOf2ZWAqwStQRVeE9Dw/8Kwqg@postini.com; Tue, 28 Jul 2009 02:14:02 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 28 Jul 2009 02:10:00 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 28 Jul 2009 05:09:59 -0400 From: Stephen Hanna To: "iesg@ietf.org" , "secdir@ietf.org" , "ietf@ietf.org" , "draft-peterson-rai-rfc3427bis@tools.ietf.org" Date: Tue, 28 Jul 2009 05:09:31 -0400 Thread-Topic: secdir review of draft-peterson-rai-rfc3427bis-02.txt Thread-Index: AcoPYx3URs99g7Z4T5WHm8QuiidkTg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] secdir review of draft-peterson-rai-rfc3427bis-02.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, 28 Jul 2009 09:14:13 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. 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 replaces RFC 3427, refining the SIP change process. Although I have some familiarity with SIP, my knowledge of this area is minimal. I have not participated in any of the RAI WGs or in the SIP change process. My comments should therefore mainly be taken as those of an IETF "common man" and a security expert. I have very few security concerns related to this document. As with RFC 3427, this document continues to require all new SIP headers and event packages (the only extensions that can be registered without going through an IETF WG) to be reviewed by a Designated Expert using guidelines that include strict security requirements. My only security concern with this process is that a Designated Expert might not have much or any security expertise. A truly dedicated reviewer without such expertise would seek specialized review for security issues but many reviewers are overworked or not able to obtain security help. This problem could be solved by requiring all SIP extensions to become RFCs, therefore ensuring that they get broad review, including secdir reviews. RFC 3427 required this. This draft proposes to remove the requirement for RFC publication for SIP headers, allowing IANA registration of SIP headers that receive Designated Expert review but are not published as RFCs. I suggest that this change not be made since it will reduce the security review of these extensions. Another reason to not allow IANA registration of SIP headers without RFC publication is that there may not be a permanent and clear definition of these headers. If a header is only documented on a vendor web site, that documentation can disappear at any time. Other changes that were made to the SIP header registration process include a large reduction in the number of guidelines for expert reviewers. The requirements dropped include these: applicability to SIP, lack of overlap with current or planned SIP extensions, clear documents, and an applicability statement when the extension is not suitable for use on the Internet. Removing those guidelines seems unwise to me. I have divided the rest of my comments into substantive and non-substantive comments. First, the substantive ones. * Does the term "consensus" in the first sentence of the third paragraph of section 3 refer to WG consensus or IETF consensus? I believe that it refers to WG consensus but this should be clarified. * The last sentence of the fifth paragraph in section 3 says that the DISPATCH working group may "approve proposals for extensions if the requirements are judged to be appropriate to SIP, but are not sufficiently general for standards track activity." I think that these proposals would then proceed as individual submissions. If that's right, I suggest that this be mentioned in this sentence. * The first paragraph of section 4.1 says that "Normal event packages can be created and registered by the publication of any Working Group RFC (Informational, Standards Track, Experimental), provided that the RFC is a chartered working group item." However, the next paragraph describes how individual submissions for event packages may be published. This seems to be a contradiction. Maybe the sentence that I just quoted is not intended to exhaustively describe all the ways that event packages can be created. If that's the case, the sentence should be clarified. * Paragraph four of section 4.1 says that the procedure for registering event packages developed outside the scope of an IETF working group is "RFC Required". However, the process described in the following paragraphs would better be described as "RFC Required with Designated Expert Review". * As the first paragraph in the Security Considerations section says, feature interactions can have significant security implications. However, the text should go one step beyond to require that all RFCs that modify or extend SIP must consider the security implications of feature interactions. * The fifth paragraph of section 7 says that "For event template packages, registrations must follow the RFC5226 processes for Standards Action." Actually, the earlier part of this document included an additional requirement that such specifications must be developed by an IETF Working Group. Probably that should be documented here. * The fifth paragraph of section 7 also states that IETF Review is the process used for ordinary event packages. That is not consistent with section 4.1, which states that the process for these is RFC Required (with Designated Expert review). I think that section 4.1 is correct and the text in section 7 should be updated. Here are my non-substantive comments. * In the first paragraph of section 2, "SIP has to preserve" should be "SIP has been to preserve". * In the first paragraph of section 2.1, the word "exists" should be removed from the end of the first sentence. * In the second paragraph of section 2.1, the phrase "updates or obsoletes" is not clear. I suggest using the phrase "documents that update or obsolete". Further, I suggest adding the phrase "or their successors" at the end of that sentence. * In the third paragraph of section 2.1, "will the use" should be "will use". In the following sentence, delete the phrase "and the rest of this document". That is a copy and paste error left over from RFC 3427, I think. In the last sentence of this paragraph, I suggest changing "any protocol in the IETF" to "SIP (and any protocol in the IETF)". The emphasis should be on SIP in this document. * In the fourth paragraph of section 2.1, change the first sentence to say "IETF working group" instead of just "working group". I think that's the intent but someone could read it to include working groups of other organizations also. * In the second paragraph of section 4, there's an extra comma after "While". Also, I think the word "general" is missing after the phrase "deal with a point solution and are not". * In the sixth paragraph of section 4, the phrase "Informational IETF specifications" would be clearer if it was replaced by "Informational RFCs". * The first paragraph of section 4.1 includes a reference to "[6]" but references in this spec are of the form "[RFCXXXX]". I believe this reference is supposed to be [RFC3265]. * In the numbered list at the end of section 4.1, several references use the wrong format. The references to [6] should be [RFC3265] and the reference to [3] should be [RFC3261], I think. * The text "(See Section 4)" appears in the list at the end of section 4.1 but the meaning of this text is not clear. Please clarify. * More numeric references appear in section 6. These can easily be transformed to the more explicit style used in this document since the RFC numbers are adjacent to the references. From paul.hoffman@vpnc.org Tue Jul 28 03:24:58 2009 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 4B21A3A6D86 for ; Tue, 28 Jul 2009 03:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diKzlyh-VBEg for ; Tue, 28 Jul 2009 03:24:57 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id DA1A33A6AA2 for ; Tue, 28 Jul 2009 03:24:56 -0700 (PDT) Received: from [10.20.30.158] (dhcp-11ce.meeting.ietf.org [130.129.17.206]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6SAOrKK037350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Jul 2009 03:24:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 28 Jul 2009 12:24:52 +0200 To: secdir@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [secdir] Paper on RSA 1024 and ECC 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, 28 Jul 2009 10:24:58 -0000 >From today's lunch: --Paul Hoffman, Director --VPN Consortium From yaronf@checkpoint.com Tue Jul 28 04:59:03 2009 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 E86343A67AA for ; Tue, 28 Jul 2009 04:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 WMip2kROZtCz for ; Tue, 28 Jul 2009 04:59:02 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 9EBA23A681C for ; Tue, 28 Jul 2009 04:58:33 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7621929C002; Tue, 28 Jul 2009 14:58:51 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 2898B29C005; Tue, 28 Jul 2009 14:58:51 +0300 (IDT) X-CheckPoint: {4A6EE696-2-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n6SBw03i028169; Tue, 28 Jul 2009 14:58:33 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 28 Jul 2009 14:58:29 +0300 From: Yaron Sheffer To: Paul Hoffman , "secdir@ietf.org" Date: Tue, 28 Jul 2009 14:58:24 +0300 Thread-Topic: [secdir] Paper on RSA 1024 and ECC Thread-Index: AcoPbau2jgp56SdURcC5hhjddg0CBAADPB6g Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557C90D@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0033_01CA0F8B.799B6BA0" MIME-Version: 1.0 Subject: Re: [secdir] Paper on RSA 1024 and ECC 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, 28 Jul 2009 11:59:04 -0000 ------=_NextPart_000_0033_01CA0F8B.799B6BA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit And the AES-256 related-key attack: http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html Thanks, Yaron > -----Original Message----- > From: secdir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] On Behalf > Of Paul Hoffman > Sent: Tuesday, July 28, 2009 12:25 > To: secdir@ietf.org > Subject: [secdir] Paper on RSA 1024 and ECC > > From today's lunch: > > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0033_01CA0F8B.799B6BA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDcyODExNTgyNFowIwYJKoZIhvcNAQkEMRYEFKRwylssAuNn UHNOQDtcyUumyRCZMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA jmLzr9r1WkLiCZXscm/qDkp6f3MrSwwhJ3eBK46oPmszPc1Mk89EvsO0rDoEz5WS2AE+0imO8tUY nfO7kXEuqC5KhhzAu8Lc9u+v3WGIvjvmPsrwbXAJOwX6mfQG7rpvhj435iDZKk51N98GOPiKPe0q /lL+h6ziOYhDE93+SyB4NH95fHBlb0m/DZQMENL45tVFG8BrQKAKyEz7FK1U78k2WTDpTaGLpuPZ x2tbtL9lQDGAJ+dIa5KN9R7B7xU8xrQpUM3MI7iKEniqrYG6hFss1odgREyE4oxdfB9wNQV8UoNK ObapRhhqJiNHfvhNlapObc+BFiOelwz0T7wbXgAAAAAAAA== ------=_NextPart_000_0033_01CA0F8B.799B6BA0-- From fred@cisco.com Tue Jul 28 13:49:29 2009 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 3A9473A68AE for ; Tue, 28 Jul 2009 13:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.862 X-Spam-Level: X-Spam-Status: No, score=-109.862 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 wWYSpcm45I+8 for ; Tue, 28 Jul 2009 13:49:28 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8F1973A67EB for ; Tue, 28 Jul 2009 13:49:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgAAFYBb0qQ/uCKe2dsb2JhbACaBgEBFiQGolOIJ5AgBYQQgU0 X-IronPort-AV: E=Sophos;i="4.43,284,1246838400"; d="scan'208";a="46010102" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 Jul 2009 20:49:27 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6SKnRhX013304; Tue, 28 Jul 2009 22:49:27 +0200 Received: from [10.43.1.21] (ams3-vpn-dhcp1554.cisco.com [10.61.70.18]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6SKnDtq015185; Tue, 28 Jul 2009 20:49:15 GMT Message-Id: <5AECC74E-90A0-45DA-9D23-7DE64F3488CB@cisco.com> From: Fred Baker To: Joel Jaeggli In-Reply-To: <4A6D98AC.4060100@bogus.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 28 Jul 2009 22:49:11 +0200 References: <633E561F-48D1-42DE-A310-9E77DB0A87F1@cisco.com> <4A6D98AC.4060100@bogus.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3772; t=1248814167; x=1249678167; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Discussion=20from=20the=20Security=20Di rectorate |Sender:=20; bh=4dHjt/lsFUKKLeg2AJP2Ev2BB/ekSpDj2Fg0nVli/e0=; b=gZpwLAM/8mvfdQmVZV4F812E43VPyJ9waHd5A412Ek3QX2fxKtQMiIWN9/ iu43NRu/pk3jIEaXSjmVDCSA1U/mft5ImALxOH8F8y821E2cQF87xlEZItPS ZZ3F1qLidE; Authentication-Results: ams-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man-ads@tools.ietf.org, secdir@ietf.org, Kurt Erik Lindqvist , Joe Abley , Softwire Chairs , v6ops-ads@tools.ietf.org, softwire-ads@tools.ietf.org, Tina TSOU , behave-ads@tools.ietf.org, Behave Chairs Subject: Re: [secdir] Discussion from the Security Directorate 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, 28 Jul 2009 20:49:29 -0000 I'm not arguing against the request. I'm asking what it is requesting, as I have no idea... I think I know what a threat analysis is. What is a "security assessment" apart from a "threat assessment"? I told v6ops (which does not develop transition technologies, by charter, and therefore is the absolute wrong place to send this) that I thought it might mean an assessment of how we might mitigate the threats. Absent any answers from the Security Directorate responsive to the question, I have no idea whether I was correct. And what on God's Green Earth is a "function recommendation"? I have no idea what you want. Nobody from the Security Directorate was there today to deliver the message. If I were developing a threat assessment of that protocol... let's see: delivered to the wrong WG by someone who didn't know what the message was supposed to be using slides he didn't understand and the security directorate didn't take the time to explain... On Jul 27, 2009, at 2:08 PM, Joel Jaeggli wrote: > I'd probably tune the slides a bit still: > > Security problems show up in deployment and use, these cannot be > thought out at all when designing the protocols > > Is an assertion you'll get pushback on. we have signficant operational > experience with variations on many of the proposed or deployed > transition mechanisms. necessarily that experience informs both our > current thinking and the desirability of any particular approach. > > bump in the wire type transition technologies certainly are an area > potential concern for opsec > > Fred Baker wrote: >> Thanks, Tina. I will add this to the IPv6 Operations agenda, probably >> during our second session Tuesday. >> >> You will note that I am copying the chairs and ADs from several >> working >> groups. The reason is that the primary thrust of the comments you are >> making apply to work being done in those working groups. Slide 5 >> specifically requests a threat analysis, security assessment, and >> "function recommendation" on each transition technology; these are in >> fact being done in behave and softwires. I mention 6man because >> marketing blather from the IPv6 form makes security claims for IPv6, >> which it would be good if that working group clarified. >> >> I do have to ask specifically what the Security Directorate hopes to >> find in the three documents that have been requested for each of >> these >> various technologies. What, specifically, is a "function >> recommendation"? A threat analysis is a statement that there exist >> a set >> of possible threats. Is a security assessment a statement about how >> those threats are responded to? What, if the WGs don't produce it, is >> going to leave the Security Directorate feeling ill-used? >> >> On Jul 27, 2009, at 12:56 PM, Tina TSOU wrote: >> >>> >>> B. R. >>> ">http://tinatsou.weebly.com/contact.html >> >>> Begin forwarded message: >>> >>>> From: "Romascanu, Dan (Dan)" >>>> Date: July 27, 2009 7:52:20 AM GMT+02:00 >>>> To: Ron Bonica >>>> Cc: Tina TSOU >>>> Subject: FW: [OPS-DIR] Reminder: OPS-DIR working lunch >>>> >>>> Ron, >>>> >>>> This looks more like an opsec (who are not meeting this time) or >>>> v6ops >>>> subject. >>>> >>>> Dan >>>> >>>> >>>> -----Original Message----- >>>> From: Tina TSOU [mailto:tena@huawei.com] >>>> Sent: Monday, July 27, 2009 12:02 AM >>>> To: Romascanu, Dan (Dan) >>>> Subject: Re: [OPS-DIR] Reminder: OPS-DIR working lunch >>>> >>>> Hi Dan, >>>> Could this be discussed at OPS-DIR working lunch? >>> >>> >>> From joelja@bogus.com Wed Jul 29 01:56:07 2009 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 A29453A68CE for ; Wed, 29 Jul 2009 01:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 9pGFV68u-tyJ for ; Wed, 29 Jul 2009 01:56:06 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 3E84E3A6F3D for ; Wed, 29 Jul 2009 01:55:55 -0700 (PDT) Received: from [130.129.21.251] (dhcp-15fb.meeting.ietf.org [130.129.21.251]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n6T8tECa039929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Jul 2009 08:55:18 GMT (envelope-from joelja@bogus.com) Message-ID: <4A700E71.8080804@bogus.com> Date: Wed, 29 Jul 2009 10:55:13 +0200 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.22 (X11/20090710) MIME-Version: 1.0 To: Fred Baker References: <633E561F-48D1-42DE-A310-9E77DB0A87F1@cisco.com> <4A6D98AC.4060100@bogus.com> <5AECC74E-90A0-45DA-9D23-7DE64F3488CB@cisco.com> In-Reply-To: <5AECC74E-90A0-45DA-9D23-7DE64F3488CB@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Wed, 29 Jul 2009 08:55:24 +0000 (UTC) Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man-ads@tools.ietf.org, secdir@ietf.org, Kurt Erik Lindqvist , Joe Abley , Softwire Chairs , v6ops-ads@tools.ietf.org, softwire-ads@tools.ietf.org, Tina TSOU , behave-ads@tools.ietf.org, Behave Chairs Subject: Re: [secdir] Discussion from the Security Directorate 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, 29 Jul 2009 08:56:07 -0000 Fred Baker wrote: > I'm not arguing against the request. I'm asking what it is requesting, > as I have no idea... > > I think I know what a threat analysis is. > > What is a "security assessment" apart from a "threat assessment"? I told > v6ops (which does not develop transition technologies, by charter, and > therefore is the absolute wrong place to send this) that I thought it > might mean an assessment of how we might mitigate the threats. Absent > any answers from the Security Directorate responsive to the question, I > have no idea whether I was correct. I don't get the warm fuzzy impression that what the security directorate was attempting to communicate was conveyed. If the cpe security discussion in v6 ops underscores anything it's the compromise that we arrived at in ipv4 with 30 years worth of intellectual ferment where desirable or un, is quite hard to arrive at by deliberate intention. > And what on God's Green Earth is a "function recommendation"? I have no > idea what you want. > > Nobody from the Security Directorate was there today to deliver the > message. If I were developing a threat assessment of that protocol... > let's see: delivered to the wrong WG by someone who didn't know what the > message was supposed to be using slides he didn't understand and the > security directorate didn't take the time to explain... > > On Jul 27, 2009, at 2:08 PM, Joel Jaeggli wrote: > >> I'd probably tune the slides a bit still: >> >> Security problems show up in deployment and use, these cannot be >> thought out at all when designing the protocols >> >> Is an assertion you'll get pushback on. we have signficant operational >> experience with variations on many of the proposed or deployed >> transition mechanisms. necessarily that experience informs both our >> current thinking and the desirability of any particular approach. >> >> bump in the wire type transition technologies certainly are an area >> potential concern for opsec >> >> Fred Baker wrote: >>> Thanks, Tina. I will add this to the IPv6 Operations agenda, probably >>> during our second session Tuesday. >>> >>> You will note that I am copying the chairs and ADs from several working >>> groups. The reason is that the primary thrust of the comments you are >>> making apply to work being done in those working groups. Slide 5 >>> specifically requests a threat analysis, security assessment, and >>> "function recommendation" on each transition technology; these are in >>> fact being done in behave and softwires. I mention 6man because >>> marketing blather from the IPv6 form makes security claims for IPv6, >>> which it would be good if that working group clarified. >>> >>> I do have to ask specifically what the Security Directorate hopes to >>> find in the three documents that have been requested for each of these >>> various technologies. What, specifically, is a "function >>> recommendation"? A threat analysis is a statement that there exist a set >>> of possible threats. Is a security assessment a statement about how >>> those threats are responded to? What, if the WGs don't produce it, is >>> going to leave the Security Directorate feeling ill-used? >>> >>> On Jul 27, 2009, at 12:56 PM, Tina TSOU wrote: >>> >>>> >>>> B. R. >>>> ">http://tinatsou.weebly.com/contact.html >>> >>>> Begin forwarded message: >>>> >>>>> From: "Romascanu, Dan (Dan)" >>>>> Date: July 27, 2009 7:52:20 AM GMT+02:00 >>>>> To: Ron Bonica >>>>> Cc: Tina TSOU >>>>> Subject: FW: [OPS-DIR] Reminder: OPS-DIR working lunch >>>>> >>>>> Ron, >>>>> >>>>> This looks more like an opsec (who are not meeting this time) or v6ops >>>>> subject. >>>>> >>>>> Dan >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Tina TSOU [mailto:tena@huawei.com] >>>>> Sent: Monday, July 27, 2009 12:02 AM >>>>> To: Romascanu, Dan (Dan) >>>>> Subject: Re: [OPS-DIR] Reminder: OPS-DIR working lunch >>>>> >>>>> Hi Dan, >>>>> Could this be discussed at OPS-DIR working lunch? >>>> >>>> >>>> > From ietfdbh@comcast.net Wed Jul 29 02:30:48 2009 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 949943A6F03 for ; Wed, 29 Jul 2009 02:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 m3IYiofWA-o9 for ; Wed, 29 Jul 2009 02:30:47 -0700 (PDT) Received: from QMTA13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by core3.amsl.com (Postfix) with ESMTP id 7875F3A6E8C for ; Wed, 29 Jul 2009 02:30:47 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA13.emeryville.ca.mail.comcast.net with comcast id MlWH1c00116AWCUADlWqdv; Wed, 29 Jul 2009 09:30:50 +0000 Received: from Harrington73653 ([130.129.18.98]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id MlWC1c00226xVzW8SlWFXp; Wed, 29 Jul 2009 09:30:47 +0000 From: "David Harrington" To: References: <633E561F-48D1-42DE-A310-9E77DB0A87F1@cisco.com><4A6D98AC.4060100@bogus.com> <5AECC74E-90A0-45DA-9D23-7DE64F3488CB@cisco.com> Date: Wed, 29 Jul 2009 11:30:07 +0200 Message-ID: <04f701ca102f$3e6d2c90$7958404e@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoPxOmPdY3vZikXSGCbROfMvDRktAAZz99w In-Reply-To: <5AECC74E-90A0-45DA-9D23-7DE64F3488CB@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: '6man Chairs' <6man-chairs@tools.ietf.org>, 'Joel Jaeggli' , 6man-ads@tools.ietf.org, 'Fred Baker' , 'Behave Chairs' , 'Kurt Erik Lindqvist' , 'Joe Abley' , 'Softwire Chairs' , v6ops-ads@tools.ietf.org, softwire-ads@tools.ietf.org, behave-ads@tools.ietf.org, 'Tina TSOU' Subject: Re: [secdir] Discussion from the Security Directorate 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, 29 Jul 2009 09:30:48 -0000 Hi, I have a question. I am a member of the Security Directorate, and I do not remember any discussion leading to this powerpoint presentation or request. I may have missed a SECDIR session. I didn't find discussion of this powerpoint presentation in the secdir archives prior to this week. Is this a "Discussion from the Security Directorate"? If so, when was this discussed? Has the SECDIR reviewed this powerpoint slide deck and approved it being sent to working groups? David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: secdir-bounces@ietf.org > [mailto:secdir-bounces@ietf.org] On Behalf Of Fred Baker > Sent: Tuesday, July 28, 2009 10:49 PM > To: Joel Jaeggli > Cc: 6man Chairs; 6man-ads@tools.ietf.org; secdir@ietf.org; > Kurt Erik Lindqvist; Joe Abley; Softwire Chairs; > v6ops-ads@tools.ietf.org; softwire-ads@tools.ietf.org; Tina > TSOU; behave-ads@tools.ietf.org; Behave Chairs > Subject: Re: [secdir] Discussion from the Security Directorate > > I'm not arguing against the request. I'm asking what it is > requesting, > as I have no idea... > > I think I know what a threat analysis is. > > What is a "security assessment" apart from a "threat assessment"? I > told v6ops (which does not develop transition technologies, by > charter, and therefore is the absolute wrong place to send > this) that > I thought it might mean an assessment of how we might mitigate the > threats. Absent any answers from the Security Directorate responsive > to the question, I have no idea whether I was correct. > > And what on God's Green Earth is a "function recommendation"? I have > no idea what you want. > > Nobody from the Security Directorate was there today to deliver the > message. If I were developing a threat assessment of that > protocol... > let's see: delivered to the wrong WG by someone who didn't know what > the message was supposed to be using slides he didn't understand and > the security directorate didn't take the time to explain... > > On Jul 27, 2009, at 2:08 PM, Joel Jaeggli wrote: > > > I'd probably tune the slides a bit still: > > > > Security problems show up in deployment and use, these cannot be > > thought out at all when designing the protocols > > > > Is an assertion you'll get pushback on. we have signficant > operational > > experience with variations on many of the proposed or deployed > > transition mechanisms. necessarily that experience informs both our > > current thinking and the desirability of any particular approach. > > > > bump in the wire type transition technologies certainly are an area > > potential concern for opsec > > > > Fred Baker wrote: > >> Thanks, Tina. I will add this to the IPv6 Operations > agenda, probably > >> during our second session Tuesday. > >> > >> You will note that I am copying the chairs and ADs from several > >> working > >> groups. The reason is that the primary thrust of the > comments you are > >> making apply to work being done in those working groups. Slide 5 > >> specifically requests a threat analysis, security assessment, and > >> "function recommendation" on each transition technology; > these are in > >> fact being done in behave and softwires. I mention 6man because > >> marketing blather from the IPv6 form makes security claims > for IPv6, > >> which it would be good if that working group clarified. > >> > >> I do have to ask specifically what the Security > Directorate hopes to > >> find in the three documents that have been requested for each of > >> these > >> various technologies. What, specifically, is a "function > >> recommendation"? A threat analysis is a statement that > there exist > >> a set > >> of possible threats. Is a security assessment a statement about how > >> those threats are responded to? What, if the WGs don't > produce it, is > >> going to leave the Security Directorate feeling ill-used? > >> > >> On Jul 27, 2009, at 12:56 PM, Tina TSOU wrote: > >> > >>> > >>> B. R. > >>> ">http://tinatsou.weebly.com/contact.html > >> > >>> Begin forwarded message: > >>> > >>>> From: "Romascanu, Dan (Dan)" > >>>> Date: July 27, 2009 7:52:20 AM GMT+02:00 > >>>> To: Ron Bonica > >>>> Cc: Tina TSOU > >>>> Subject: FW: [OPS-DIR] Reminder: OPS-DIR working lunch > >>>> > >>>> Ron, > >>>> > >>>> This looks more like an opsec (who are not meeting this > time) or > >>>> v6ops > >>>> subject. > >>>> > >>>> Dan > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Tina TSOU [mailto:tena@huawei.com] > >>>> Sent: Monday, July 27, 2009 12:02 AM > >>>> To: Romascanu, Dan (Dan) > >>>> Subject: Re: [OPS-DIR] Reminder: OPS-DIR working lunch > >>>> > >>>> Hi Dan, > >>>> Could this be discussed at OPS-DIR working lunch? > >>> > >>> > >>> > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From william.polk@nist.gov Wed Jul 29 04:14:49 2009 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 ADABF3A6FD3; Wed, 29 Jul 2009 04:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.734 X-Spam-Level: X-Spam-Status: No, score=-6.734 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, 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 Vs+8B-W8b55d; Wed, 29 Jul 2009 04:14:48 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id C0DBB3A6F3F; Wed, 29 Jul 2009 04:14:48 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n6TBEijZ032146; Wed, 29 Jul 2009 07:14:44 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Wed, 29 Jul 2009 07:14:43 -0400 From: "Polk, William T." To: "secdir@ietf.org" , "saag@ietf.org" Date: Wed, 29 Jul 2009 07:14:43 -0400 Thread-Topic: Nomcom 2009-2010: IETF-75 Office hours Thread-Index: AcoPEQbFn5p69000RvKoubu2bcmSPQBKsoCS Message-ID: References: <20090727231807.374A33A6922@core3.amsl.com> In-Reply-To: <20090727231807.374A33A6922@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Subject: [secdir] FW: Nomcom 2009-2010: IETF-75 Office hours 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, 29 Jul 2009 11:14:49 -0000 Folks, I suspect that many of you are not on ietf@ietf.org or 75attendees@ietf.org= , so I thought I would pass this on. Please support the nomcom in their extremely important job by talking with the nomcom members! For those in Stockholm, they are having office=20 hours this week, as noted below. For those not at IETF 75, please take advantage of the nomcom09@ietf.org address. Tim Polk P.S. Note that I am IESG liaison to the nomcom this year. If you would pre= fer that I not see your feedback, I encourage you to send the email directly to Mary Barnes ________________________________________ From: ietf-bounces@ietf.org [ietf-bounces@ietf.org] On Behalf Of Mary Barne= s [mary.barnes@nortel.com] Sent: Monday, July 27, 2009 7:18 PM To: IETF Announcement list Cc: ietf@ietf.org; 75attendees@ietf.org Subject: Nomcom 2009-2010: IETF-75 Office hours Hi all, As you know, one of the first tasks of the Nomcom is consideration of the qualifications for the various positions. While the Nomcom is in the initial stages of organization, we would appreciate community feedback on the qualifications, as well as general feedback or concerns that you feel Nomcom should consider. The official nominations period starts on August 10th, at which time the online nomination tool will be available. However, nominations are welcome via email at this point as well. Please find one of the Nomcom members (wearing an orange dot) at the meeting and share your thoughts or drop by the Nomcom office. If you prefer to schedule an appointment, please let me know or send a request to nomcom09@ietf.org. We will be available in the Nomcom room (204) as follows (W-Fri): Wed: 8am-4:10pm Thurs: 8-9am, 11:30am-1pm Fri: 8-9am If you would to schedule a specific timeslot or another time not listed above, please let us know and please include 3 timeslot/session options in your request. We will make every effort to accommodate your requests and will reply with an exact timeslot. Of course, anyone is welcome to send input and feedback to the Nomcom (nomcom09@ietf.org) or directly to myself or any nomcom voting member at any time during the selection process. Regards, Mary H. Barnes mary.barnes@nortel.com nomcom-chair@ietf.org mary.h.barnes@gmail.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From fred@cisco.com Wed Jul 29 08:04:55 2009 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 B5DFB3A6A72 for ; Wed, 29 Jul 2009 08:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.962 X-Spam-Level: X-Spam-Status: No, score=-109.962 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 s0p7G39kBFG2 for ; Wed, 29 Jul 2009 08:04:54 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id EADDD3A6814 for ; Wed, 29 Jul 2009 08:04:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQAADcCcEqQ/uCLe2dsb2JhbACBUpg6FiQGoSCIJ5A1BYQRgU4 X-IronPort-AV: E=Sophos;i="4.43,289,1246838400"; d="scan'208";a="46079289" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2009 15:04:54 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6TF4saw016424; Wed, 29 Jul 2009 17:04:54 +0200 Received: from dhcp-56c8.meeting.ietf.org (dhcp-10-61-104-243.cisco.com [10.61.104.243]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6TF4rhj029091; Wed, 29 Jul 2009 15:04:53 GMT Message-Id: <4C4D74B8-10FA-458E-93E4-37EE48F9D386@cisco.com> From: Fred Baker To: David Harrington , Tina TSOU In-Reply-To: <04f701ca102f$3e6d2c90$7958404e@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 29 Jul 2009 17:04:53 +0200 References: <633E561F-48D1-42DE-A310-9E77DB0A87F1@cisco.com><4A6D98AC.4060100@bogus.com> <5AECC74E-90A0-45DA-9D23-7DE64F3488CB@cisco.com> <04f701ca102f$3e6d2c90$7958404e@china.huawei.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5502; t=1248879894; x=1249743894; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[secdir]=20Discussion=20from=20the=20Se curity=20Directorate |Sender:=20; bh=/Mls4I8JYHirPmfRr2C9MbqI6h+u1xWWC+cW3wayYXw=; b=HF6RAG4hww7eNNW0GosDaiQ6qo1dcHI84W+OFSSSY8FCpJjUISoTLJb2h8 3y6CXUzSPWusjwqwY+PnYaogkATf8NasKjR1YbENP/vORIziiuVYMbbZpksp v9KRtnrP2c; Authentication-Results: ams-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Joel Jaeggli , 6man-ads@tools.ietf.org, secdir@ietf.org, Kurt Erik Lindqvist , Joe Abley , Softwire Chairs , v6ops-ads@tools.ietf.org, softwire-ads@tools.ietf.org, behave-ads@tools.ietf.org, Behave Chairs Subject: Re: [secdir] Discussion from the Security Directorate 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, 29 Jul 2009 15:04:55 -0000 It was presented to the ops directorate as "from the security directorate" on Monday, and shipped off to my working group. OK, Tina, over to you... On Jul 29, 2009, at 11:30 AM, David Harrington wrote: > Hi, > > I have a question. > I am a member of the Security Directorate, and I do not remember any > discussion leading to this powerpoint presentation or request. I may > have missed a SECDIR session. I didn't find discussion of this > powerpoint presentation in the secdir archives prior to this week. > > Is this a "Discussion from the Security Directorate"? If so, when was > this discussed? Has the SECDIR reviewed this powerpoint slide deck and > approved it being sent to working groups? > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > >> -----Original Message----- >> From: secdir-bounces@ietf.org >> [mailto:secdir-bounces@ietf.org] On Behalf Of Fred Baker >> Sent: Tuesday, July 28, 2009 10:49 PM >> To: Joel Jaeggli >> Cc: 6man Chairs; 6man-ads@tools.ietf.org; secdir@ietf.org; >> Kurt Erik Lindqvist; Joe Abley; Softwire Chairs; >> v6ops-ads@tools.ietf.org; softwire-ads@tools.ietf.org; Tina >> TSOU; behave-ads@tools.ietf.org; Behave Chairs >> Subject: Re: [secdir] Discussion from the Security Directorate >> >> I'm not arguing against the request. I'm asking what it is >> requesting, >> as I have no idea... >> >> I think I know what a threat analysis is. >> >> What is a "security assessment" apart from a "threat assessment"? I > >> told v6ops (which does not develop transition technologies, by >> charter, and therefore is the absolute wrong place to send >> this) that >> I thought it might mean an assessment of how we might mitigate the >> threats. Absent any answers from the Security Directorate responsive > >> to the question, I have no idea whether I was correct. >> >> And what on God's Green Earth is a "function recommendation"? I have > >> no idea what you want. >> >> Nobody from the Security Directorate was there today to deliver the > >> message. If I were developing a threat assessment of that >> protocol... >> let's see: delivered to the wrong WG by someone who didn't know what > >> the message was supposed to be using slides he didn't understand and > >> the security directorate didn't take the time to explain... >> >> On Jul 27, 2009, at 2:08 PM, Joel Jaeggli wrote: >> >>> I'd probably tune the slides a bit still: >>> >>> Security problems show up in deployment and use, these cannot > be >>> thought out at all when designing the protocols >>> >>> Is an assertion you'll get pushback on. we have signficant >> operational >>> experience with variations on many of the proposed or deployed >>> transition mechanisms. necessarily that experience informs both > our >>> current thinking and the desirability of any particular approach. >>> >>> bump in the wire type transition technologies certainly are an > area >>> potential concern for opsec >>> >>> Fred Baker wrote: >>>> Thanks, Tina. I will add this to the IPv6 Operations >> agenda, probably >>>> during our second session Tuesday. >>>> >>>> You will note that I am copying the chairs and ADs from several >>>> working >>>> groups. The reason is that the primary thrust of the >> comments you are >>>> making apply to work being done in those working groups. Slide 5 >>>> specifically requests a threat analysis, security assessment, and >>>> "function recommendation" on each transition technology; >> these are in >>>> fact being done in behave and softwires. I mention 6man because >>>> marketing blather from the IPv6 form makes security claims >> for IPv6, >>>> which it would be good if that working group clarified. >>>> >>>> I do have to ask specifically what the Security >> Directorate hopes to >>>> find in the three documents that have been requested for each of > >>>> these >>>> various technologies. What, specifically, is a "function >>>> recommendation"? A threat analysis is a statement that >> there exist >>>> a set >>>> of possible threats. Is a security assessment a statement about > how >>>> those threats are responded to? What, if the WGs don't >> produce it, is >>>> going to leave the Security Directorate feeling ill-used? >>>> >>>> On Jul 27, 2009, at 12:56 PM, Tina TSOU wrote: >>>> >>>>> >>>>> B. R. >>>>> ">http://tinatsou.weebly.com/contact.html >>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: "Romascanu, Dan (Dan)" >>>>>> Date: July 27, 2009 7:52:20 AM GMT+02:00 >>>>>> To: Ron Bonica >>>>>> Cc: Tina TSOU >>>>>> Subject: FW: [OPS-DIR] Reminder: OPS-DIR working lunch >>>>>> >>>>>> Ron, >>>>>> >>>>>> This looks more like an opsec (who are not meeting this >> time) or >>>>>> v6ops >>>>>> subject. >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Tina TSOU [mailto:tena@huawei.com] >>>>>> Sent: Monday, July 27, 2009 12:02 AM >>>>>> To: Romascanu, Dan (Dan) >>>>>> Subject: Re: [OPS-DIR] Reminder: OPS-DIR working lunch >>>>>> >>>>>> Hi Dan, >>>>>> Could this be discussed at OPS-DIR working lunch? >>>>> >>>>> >>>>> >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> > From rbarnes@bbn.com Wed Jul 29 08:23:22 2009 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 B67FE3A6D46 for ; Wed, 29 Jul 2009 08:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 f8EC4UulMAVK for ; Wed, 29 Jul 2009 08:23:21 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 6F1563A6AA1 for ; Wed, 29 Jul 2009 08:23:21 -0700 (PDT) Received: from [128.89.254.56] (helo=dhcp-14e6.meeting.ietf.org) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MWA3r-0005vE-Eq; Wed, 29 Jul 2009 10:23:20 -0400 Message-ID: <4A706966.2090908@bbn.com> Date: Wed, 29 Jul 2009 17:23:18 +0200 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Fred Baker References: <633E561F-48D1-42DE-A310-9E77DB0A87F1@cisco.com><4A6D98AC.4060100@bogus.com> <5AECC74E-90A0-45DA-9D23-7DE64F3488CB@cisco.com> <04f701ca102f$3e6d2c90$7958404e@china.huawei.com> <4C4D74B8-10FA-458E-93E4-37EE48F9D386@cisco.com> In-Reply-To: <4C4D74B8-10FA-458E-93E4-37EE48F9D386@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Joe Abley , 6man-ads@tools.ietf.org, secdir@ietf.org, behave-ads@tools.ietf.org, Behave Chairs , Kurt Erik Lindqvist , Joel Jaeggli , Softwire Chairs , v6ops-ads@tools.ietf.org, softwire-ads@tools.ietf.org, Tina TSOU Subject: Re: [secdir] Discussion from the Security Directorate 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, 29 Jul 2009 15:23:22 -0000 I'll second Dave, I don't remember seeing this in a SECDIR context before Fred sent it around. Fred Baker wrote: > It was presented to the ops directorate as "from the security > directorate" on Monday, and shipped off to my working group. > > OK, Tina, over to you... > > On Jul 29, 2009, at 11:30 AM, David Harrington wrote: > >> Hi, >> >> I have a question. >> I am a member of the Security Directorate, and I do not remember any >> discussion leading to this powerpoint presentation or request. I may >> have missed a SECDIR session. I didn't find discussion of this >> powerpoint presentation in the secdir archives prior to this week. >> >> Is this a "Discussion from the Security Directorate"? If so, when was >> this discussed? Has the SECDIR reviewed this powerpoint slide deck and >> approved it being sent to working groups? >> >> David Harrington >> dbharrington@comcast.net >> ietfdbh@comcast.net >> dharrington@huawei.com >> >> >>> -----Original Message----- >>> From: secdir-bounces@ietf.org >>> [mailto:secdir-bounces@ietf.org] On Behalf Of Fred Baker >>> Sent: Tuesday, July 28, 2009 10:49 PM >>> To: Joel Jaeggli >>> Cc: 6man Chairs; 6man-ads@tools.ietf.org; secdir@ietf.org; >>> Kurt Erik Lindqvist; Joe Abley; Softwire Chairs; >>> v6ops-ads@tools.ietf.org; softwire-ads@tools.ietf.org; Tina >>> TSOU; behave-ads@tools.ietf.org; Behave Chairs >>> Subject: Re: [secdir] Discussion from the Security Directorate >>> >>> I'm not arguing against the request. I'm asking what it is >>> requesting, >>> as I have no idea... >>> >>> I think I know what a threat analysis is. >>> >>> What is a "security assessment" apart from a "threat assessment"? I >> >>> told v6ops (which does not develop transition technologies, by >>> charter, and therefore is the absolute wrong place to send >>> this) that >>> I thought it might mean an assessment of how we might mitigate the >>> threats. Absent any answers from the Security Directorate responsive >> >>> to the question, I have no idea whether I was correct. >>> >>> And what on God's Green Earth is a "function recommendation"? I have >> >>> no idea what you want. >>> >>> Nobody from the Security Directorate was there today to deliver the >> >>> message. If I were developing a threat assessment of that >>> protocol... >>> let's see: delivered to the wrong WG by someone who didn't know what >> >>> the message was supposed to be using slides he didn't understand and >> >>> the security directorate didn't take the time to explain... >>> >>> On Jul 27, 2009, at 2:08 PM, Joel Jaeggli wrote: >>> >>>> I'd probably tune the slides a bit still: >>>> >>>> Security problems show up in deployment and use, these cannot >> be >>>> thought out at all when designing the protocols >>>> >>>> Is an assertion you'll get pushback on. we have signficant >>> operational >>>> experience with variations on many of the proposed or deployed >>>> transition mechanisms. necessarily that experience informs both >> our >>>> current thinking and the desirability of any particular approach. >>>> >>>> bump in the wire type transition technologies certainly are an >> area >>>> potential concern for opsec >>>> >>>> Fred Baker wrote: >>>>> Thanks, Tina. I will add this to the IPv6 Operations >>> agenda, probably >>>>> during our second session Tuesday. >>>>> >>>>> You will note that I am copying the chairs and ADs from several >>>>> working >>>>> groups. The reason is that the primary thrust of the >>> comments you are >>>>> making apply to work being done in those working groups. Slide 5 >>>>> specifically requests a threat analysis, security assessment, and >>>>> "function recommendation" on each transition technology; >>> these are in >>>>> fact being done in behave and softwires. I mention 6man because >>>>> marketing blather from the IPv6 form makes security claims >>> for IPv6, >>>>> which it would be good if that working group clarified. >>>>> >>>>> I do have to ask specifically what the Security >>> Directorate hopes to >>>>> find in the three documents that have been requested for each of >> >>>>> these >>>>> various technologies. What, specifically, is a "function >>>>> recommendation"? A threat analysis is a statement that >>> there exist >>>>> a set >>>>> of possible threats. Is a security assessment a statement about >> how >>>>> those threats are responded to? What, if the WGs don't >>> produce it, is >>>>> going to leave the Security Directorate feeling ill-used? >>>>> >>>>> On Jul 27, 2009, at 12:56 PM, Tina TSOU wrote: >>>>> >>>>>> >>>>>> B. R. >>>>>> ">http://tinatsou.weebly.com/contact.html >>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>>> From: "Romascanu, Dan (Dan)" >>>>>>> Date: July 27, 2009 7:52:20 AM GMT+02:00 >>>>>>> To: Ron Bonica >>>>>>> Cc: Tina TSOU >>>>>>> Subject: FW: [OPS-DIR] Reminder: OPS-DIR working lunch >>>>>>> >>>>>>> Ron, >>>>>>> >>>>>>> This looks more like an opsec (who are not meeting this >>> time) or >>>>>>> v6ops >>>>>>> subject. >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Tina TSOU [mailto:tena@huawei.com] >>>>>>> Sent: Monday, July 27, 2009 12:02 AM >>>>>>> To: Romascanu, Dan (Dan) >>>>>>> Subject: Re: [OPS-DIR] Reminder: OPS-DIR working lunch >>>>>>> >>>>>>> Hi Dan, >>>>>>> Could this be discussed at OPS-DIR working lunch? >>>>>> >>>>>> >>>>>> >>> >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> >> > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From tena@huawei.com Wed Jul 29 08:24:37 2009 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 B230B3A6823 for ; Wed, 29 Jul 2009 08:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.411 X-Spam-Level: X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.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 vOPWH5tAkeZO for ; Wed, 29 Jul 2009 08:24:36 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 761A33A697F for ; Wed, 29 Jul 2009 08:24:13 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNJ00CXIUS4W9@szxga02-in.huawei.com> for secdir@ietf.org; Wed, 29 Jul 2009 23:24:04 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNJ009IWUS4OM@szxga02-in.huawei.com> for secdir@ietf.org; Wed, 29 Jul 2009 23:24:04 +0800 (CST) Received: from dhcp-1313.meeting.ietf.org (dhcp-1313.meeting.ietf.org [130.129.19.19]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNJ00HB6URVBZ@szxml02-in.huawei.com>; Wed, 29 Jul 2009 23:24:04 +0800 (CST) Date: Wed, 29 Jul 2009 17:23:53 +0200 From: Tina In-reply-to: <4C4D74B8-10FA-458E-93E4-37EE48F9D386@cisco.com> To: Fred Baker Message-id: <50F560B9-787C-4B90-903B-28F27E67CF85@huawei.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT References: <633E561F-48D1-42DE-A310-9E77DB0A87F1@cisco.com> <4A6D98AC.4060100@bogus.com> <5AECC74E-90A0-45DA-9D23-7DE64F3488CB@cisco.com> <04f701ca102f$3e6d2c90$7958404e@china.huawei.com> <4C4D74B8-10FA-458E-93E4-37EE48F9D386@cisco.com> X-Mailman-Approved-At: Wed, 29 Jul 2009 08:26:22 -0700 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Joel Jaeggli , 6man-ads@tools.ietf.org, secdir@ietf.org, behave-ads@tools.ietf.org, Kurt Erik Lindqvist , Joe Abley , Softwire Chairs , v6ops-ads@tools.ietf.org, softwire-ads@tools.ietf.org, Behave Chairs Subject: Re: [secdir] Discussion from the Security Directorate 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, 29 Jul 2009 15:24:37 -0000 Hi Fred and David, The slides were sent to OPS ADs, and we discussed it a bit in OPS-DIR work lunch on Monday. According to the suggestion from Dan, I forwarded the slides to the WG chairs of v6ops and opsec. Then Fred forwarded to SEC-DIR. I mentioned Fred's email during SEC-DIR work lunch on Tuesday. There was discussion. I went to Tuesday v6ops session before my slides were taken. Then I left for some personal emergency reasons. Therefore I was not able to present the slides. But Fred did it. The slides will be presented in OPS Area Opening meeting in the Large Stage between 15:10 to 16:10. B. R. Tina http://tinatsou.weebly.com/contact.html On Jul 29, 2009, at 5:04 PM, Fred Baker wrote: > It was presented to the ops directorate as "from the security > directorate" on Monday, and shipped off to my working group. > > OK, Tina, over to you... > > On Jul 29, 2009, at 11:30 AM, David Harrington wrote: > >> Hi, >> >> I have a question. >> I am a member of the Security Directorate, and I do not remember any >> discussion leading to this powerpoint presentation or request. I may >> have missed a SECDIR session. I didn't find discussion of this >> powerpoint presentation in the secdir archives prior to this week. >> >> Is this a "Discussion from the Security Directorate"? If so, when was >> this discussed? Has the SECDIR reviewed this powerpoint slide deck >> and >> approved it being sent to working groups? >> >> David Harrington >> dbharrington@comcast.net >> ietfdbh@comcast.net >> dharrington@huawei.com >> >> >>> -----Original Message----- >>> From: secdir-bounces@ietf.org >>> [mailto:secdir-bounces@ietf.org] On Behalf Of Fred Baker >>> Sent: Tuesday, July 28, 2009 10:49 PM >>> To: Joel Jaeggli >>> Cc: 6man Chairs; 6man-ads@tools.ietf.org; secdir@ietf.org; >>> Kurt Erik Lindqvist; Joe Abley; Softwire Chairs; >>> v6ops-ads@tools.ietf.org; softwire-ads@tools.ietf.org; Tina >>> TSOU; behave-ads@tools.ietf.org; Behave Chairs >>> Subject: Re: [secdir] Discussion from the Security Directorate >>> >>> I'm not arguing against the request. I'm asking what it is >>> requesting, >>> as I have no idea... >>> >>> I think I know what a threat analysis is. >>> >>> What is a "security assessment" apart from a "threat assessment"? I >> >>> told v6ops (which does not develop transition technologies, by >>> charter, and therefore is the absolute wrong place to send >>> this) that >>> I thought it might mean an assessment of how we might mitigate the >>> threats. Absent any answers from the Security Directorate responsive >> >>> to the question, I have no idea whether I was correct. >>> >>> And what on God's Green Earth is a "function recommendation"? I have >> >>> no idea what you want. >>> >>> Nobody from the Security Directorate was there today to deliver the >> >>> message. If I were developing a threat assessment of that >>> protocol... >>> let's see: delivered to the wrong WG by someone who didn't know what >> >>> the message was supposed to be using slides he didn't understand and >> >>> the security directorate didn't take the time to explain... >>> >>> On Jul 27, 2009, at 2:08 PM, Joel Jaeggli wrote: >>> >>>> I'd probably tune the slides a bit still: >>>> >>>> Security problems show up in deployment and use, these cannot >> be >>>> thought out at all when designing the protocols >>>> >>>> Is an assertion you'll get pushback on. we have signficant >>> operational >>>> experience with variations on many of the proposed or deployed >>>> transition mechanisms. necessarily that experience informs both >> our >>>> current thinking and the desirability of any particular approach. >>>> >>>> bump in the wire type transition technologies certainly are an >> area >>>> potential concern for opsec >>>> >>>> Fred Baker wrote: >>>>> Thanks, Tina. I will add this to the IPv6 Operations >>> agenda, probably >>>>> during our second session Tuesday. >>>>> >>>>> You will note that I am copying the chairs and ADs from several >>>>> working >>>>> groups. The reason is that the primary thrust of the >>> comments you are >>>>> making apply to work being done in those working groups. Slide 5 >>>>> specifically requests a threat analysis, security assessment, and >>>>> "function recommendation" on each transition technology; >>> these are in >>>>> fact being done in behave and softwires. I mention 6man because >>>>> marketing blather from the IPv6 form makes security claims >>> for IPv6, >>>>> which it would be good if that working group clarified. >>>>> >>>>> I do have to ask specifically what the Security >>> Directorate hopes to >>>>> find in the three documents that have been requested for each of >> >>>>> these >>>>> various technologies. What, specifically, is a "function >>>>> recommendation"? A threat analysis is a statement that >>> there exist >>>>> a set >>>>> of possible threats. Is a security assessment a statement about >> how >>>>> those threats are responded to? What, if the WGs don't >>> produce it, is >>>>> going to leave the Security Directorate feeling ill-used? >>>>> >>>>> On Jul 27, 2009, at 12:56 PM, Tina TSOU wrote: >>>>> >>>>>> >>>>>> B. R. >>>>>> ">http://tinatsou.weebly.com/contact.html >>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>>> From: "Romascanu, Dan (Dan)" >>>>>>> Date: July 27, 2009 7:52:20 AM GMT+02:00 >>>>>>> To: Ron Bonica >>>>>>> Cc: Tina TSOU >>>>>>> Subject: FW: [OPS-DIR] Reminder: OPS-DIR working lunch >>>>>>> >>>>>>> Ron, >>>>>>> >>>>>>> This looks more like an opsec (who are not meeting this >>> time) or >>>>>>> v6ops >>>>>>> subject. >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Tina TSOU [mailto:tena@huawei.com] >>>>>>> Sent: Monday, July 27, 2009 12:02 AM >>>>>>> To: Romascanu, Dan (Dan) >>>>>>> Subject: Re: [OPS-DIR] Reminder: OPS-DIR working lunch >>>>>>> >>>>>>> Hi Dan, >>>>>>> Could this be discussed at OPS-DIR working lunch? >>>>>> >>>>>> >>>>>> >>> >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> >> > From jhutz@cmu.edu Wed Jul 29 08:56:43 2009 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 9D41E3A6909 for ; Wed, 29 Jul 2009 08:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 SrcMv5O7Mt7V for ; Wed, 29 Jul 2009 08:56:43 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 4ABF63A6B6C for ; Wed, 29 Jul 2009 08:56:39 -0700 (PDT) Received: from ATLANTIS.PC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n6TFticp007881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 11:55:44 -0400 (EDT) Date: Wed, 29 Jul 2009 11:55:44 -0400 From: Jeffrey Hutzelman To: Tina , Fred Baker Message-ID: <7A7BC0A59F89445F9C385328@atlantis.pc.cs.cmu.edu> In-Reply-To: <10275_1248881187_n6TFQQhM022941_50F560B9-787C-4B90-903B-28F27E67CF85@huawei.com> References: <633E561F-48D1-42DE-A310-9E77DB0A87F1@cisco.com> <4A6D98AC.4060100@bogus.com> <5AECC74E-90A0-45DA-9D23-7DE64F3488CB@cisco.com> <04f701ca102f$3e6d2c90$7958404e@china.huawei.com> <4C4D74B8-10FA-458E-93E4-37EE48F9D386@cisco.com> <10275_1248881187_n6TFQQhM022941_50F560B9-787C-4B90-903B-28F27E67CF85@huawei.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Joe Abley , 6man-ads@tools.ietf.org, secdir@ietf.org, Kurt Erik Lindqvist , Joel Jaeggli , Softwire Chairs , v6ops-ads@tools.ietf.org, softwire-ads@tools.ietf.org, behave-ads@tools.ietf.org, Behave Chairs Subject: Re: [secdir] Discussion from the Security Directorate 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, 29 Jul 2009 15:56:43 -0000 --On Wednesday, July 29, 2009 05:23:53 PM +0200 Tina wrote: > Hi Fred and David, > The slides were sent to OPS ADs, and we discussed it a bit in OPS-DIR > work lunch on Monday. According to the suggestion from Dan, I forwarded > the slides to the WG chairs of v6ops and opsec. Who sent them to the OPS AD's? This is the first I've heard of this, and certainly others on the security directorate seem to be in the same boat. Some context would be nice... -- Jeff From turners@ieca.com Thu Jul 30 02:03:01 2009 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 7836328C17C for ; Thu, 30 Jul 2009 02:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 i3FgqCGhWcNu for ; Thu, 30 Jul 2009 02:03:00 -0700 (PDT) Received: from smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by core3.amsl.com (Postfix) with SMTP id 8994028C19E for ; Thu, 30 Jul 2009 02:03:00 -0700 (PDT) Received: (qmail 4669 invoked from network); 30 Jul 2009 09:03:02 -0000 Received: from unknown (HELO dhcp-1598.meeting.ietf.org) (turners@130.129.21.152 with plain) by smtp109.biz.mail.re2.yahoo.com with SMTP; 30 Jul 2009 09:03:00 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: 9PSemO4VM1l_tpdnk_eU0VGp1_GNellOy3ZECvbPy3IbJU4N09TzdZOh2L4CscY7G4b.y4ewh5Lqa7XI10EIXDAveowmvcAzmsIyfXfc3QTpWSVR_1kUibbAYMjgNODbLcIeJ39NVzMcaqqVoYa_yRjuk_t2jr8oaDGBFjh9RAPRVZO20PQJfk1SB49ZXpEj5QbEPxprjg_ERTC1zVcuROGcn74DQ.eGuP4F6ckZO5BI1YdP7579Bp8Mt5FqrDToqgjJOo5bx1juM7L21GsQ2vR9ZqtgQdRNHtt66Dlv5FtbLZtxHI_Re9UAZKU4FAJqlRgcldc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7161C0.4040007@ieca.com> Date: Thu, 30 Jul 2009 11:02:56 +0200 From: Sean Turner User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: secdir , draft-nottingham-http-link-header@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lisa Dusseault Subject: [secdir] secdir review of draft-nottingham-http-link-header 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, 30 Jul 2009 09:03:01 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Document: draft-nottingham-http-link-header-06.txt Reviewer: Sean Turner Review Date: 2009-07-30 IETF LC End Date: 2009-08-11 IESG Telechat date: N/A Summary: This document specifies relation types for Web links, and defines a registry for them. It also defines how to send such links in HTTP headers with the Link header-field. Comments: The security considerations are pretty clear: the content of the fields aren't secured in any way. I think some text should be added that says something like "[Mechanism XYZ] can be combined with [protocol ABC] to provide the following security service: 1, 2, 3." spt From tena@huawei.com Thu Jul 30 03:29:59 2009 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 37BDB3A6860 for ; Thu, 30 Jul 2009 03:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.346 X-Spam-Level: X-Spam-Status: No, score=-0.346 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.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 YK2vg14z+rxD for ; Thu, 30 Jul 2009 03:29:58 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 6F0503A67D7 for ; Thu, 30 Jul 2009 03:29:58 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNL00H7EBCRBM@szxga01-in.huawei.com> for secdir@ietf.org; Thu, 30 Jul 2009 18:19:40 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNL00IYKBCR5Z@szxga01-in.huawei.com> for secdir@ietf.org; Thu, 30 Jul 2009 18:19:39 +0800 (CST) Received: from dhcp-1313.meeting.ietf.org (dhcp-1313.meeting.ietf.org [130.129.19.19]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNL005ASBCKSQ@szxml02-in.huawei.com>; Thu, 30 Jul 2009 18:19:39 +0800 (CST) Date: Thu, 30 Jul 2009 12:19:30 +0200 From: Tina TSOU In-reply-to: <7A7BC0A59F89445F9C385328@atlantis.pc.cs.cmu.edu> To: Jeffrey Hutzelman Message-id: <78B348B3-0F13-4751-BDF9-2A9B8CAC8587@huawei.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT References: <633E561F-48D1-42DE-A310-9E77DB0A87F1@cisco.com> <4A6D98AC.4060100@bogus.com> <5AECC74E-90A0-45DA-9D23-7DE64F3488CB@cisco.com> <04f701ca102f$3e6d2c90$7958404e@china.huawei.com> <4C4D74B8-10FA-458E-93E4-37EE48F9D386@cisco.com> <10275_1248881187_n6TFQQhM022941_50F560B9-787C-4B90-903B-28F27E67CF85@huawei.com> <7A7BC0A59F89445F9C385328@atlantis.pc.cs.cmu.edu> Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Joe Abley , 6man-ads@tools.ietf.org, secdir@ietf.org, Behave Chairs , Kurt Erik Lindqvist , Joel Jaeggli , Fred Baker , v6ops-ads@tools.ietf.org, softwire-ads@tools.ietf.org, behave-ads@tools.ietf.org, Softwire Chairs Subject: Re: [secdir] Discussion from the Security Directorate 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, 30 Jul 2009 10:29:59 -0000 On Jul 29, 2009, at 5:55 PM, Jeffrey Hutzelman wrote: > --On Wednesday, July 29, 2009 05:23:53 PM +0200 Tina > wrote: > >> Hi Fred and David, >> The slides were sent to OPS ADs, and we discussed it a bit in OPS-DIR >> work lunch on Monday. According to the suggestion from Dan, I >> forwarded >> the slides to the WG chairs of v6ops and opsec. > > Who sent them to the OPS AD's? This is the first I've heard of > this, and certainly others on the security directorate seem to be in > the same boat. Some context would be nice... > > -- Jeff > I sent the slides to OPS AD's. In the first email Fred send to you about this subject, you could see the email history. Tina From cwallace@cygnacom.com Thu Jul 30 04:12:24 2009 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 BDB6F3A7184 for ; Thu, 30 Jul 2009 04:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 QkRfZ1eY8NzM for ; Thu, 30 Jul 2009 04:12:24 -0700 (PDT) Received: from p03c11o142.symantecmail.net (p03c11o142.symantecmail.net [208.65.144.85]) by core3.amsl.com (Postfix) with ESMTP id E4E653A68D7 for ; Thu, 30 Jul 2009 04:12:23 -0700 (PDT) Received: from unknown [65.242.48.5] (EHLO p03c11o142.symantecmail.net) by p03c11o142.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id a10817a4.2063313840.286275.00-503.p03c11o142.symantecmail.net (envelope-from ); Thu, 30 Jul 2009 05:12:26 -0600 (MDT) Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o142.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 610817a4.1895476144.286271.00-018.p03c11o142.symantecmail.net (envelope-from ); Thu, 30 Jul 2009 05:12:22 -0600 (MDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1106.9B5B8DAA" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 30 Jul 2009 07:12:19 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-solinas-rfc4753bis-00 thread-index: AcoRBppjIuFz780LRqWPn9kJVZMBjg== From: "Carl Wallace" To: "secdir" , , X-Spam: [F=0.2000000000; S=0.200(2009071501)] X-MAIL-FROM: X-SOURCE-IP: [65.242.48.5] Subject: [secdir] secdir review of draft-solinas-rfc4753bis-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: Thu, 30 Jul 2009 11:12:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1106.9B5B8DAA 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 This draft incorporates the erratum for RFC 4753. I have no security concerns with this draft. =20 ------_=_NextPart_001_01CA1106.9B5B8DAA 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.

 

This draft incorporates the erratum for RFC = 4753.  I have no security concerns with this draft.

 

------_=_NextPart_001_01CA1106.9B5B8DAA-- From fred@cisco.com Thu Jul 30 04:50:01 2009 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 8B30D3A6AF8 for ; Thu, 30 Jul 2009 04:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.147 X-Spam-Level: X-Spam-Status: No, score=-110.147 tagged_above=-999 required=5 tests=[AWL=0.452, 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 YiZaSGVY5888 for ; Thu, 30 Jul 2009 04:50:00 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8063828C219 for ; Thu, 30 Jul 2009 04:49:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQAAAMmcUqQ/uCLe2dsb2JhbACBUpg7FiQGnnKIJ5AlBYQR X-IronPort-AV: E=Sophos;i="4.43,295,1246838400"; d="scan'208";a="46136719" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2009 11:49:43 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6UBnh72001975; Thu, 30 Jul 2009 13:49:43 +0200 Received: from dhcp-56c8.meeting.ietf.org (dhcp-10-61-102-132.cisco.com [10.61.102.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6UBngEL007642; Thu, 30 Jul 2009 11:49:42 GMT Message-Id: <443755B4-A19A-4DF8-9BC3-07B7D1B8477D@cisco.com> From: Fred Baker To: David Harrington In-Reply-To: <003601ca10f1$937bfe60$62128182@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 13:49:42 +0200 References: <633E561F-48D1-42DE-A310-9E77DB0A87F1@cisco.com> <4A6D98AC.4060100@bogus.com> <5AECC74E-90A0-45DA-9D23-7DE64F3488CB@cisco.com> <04f701ca102f$3e6d2c90$7958404e@china.huawei.com> <4C4D74B8-10FA-458E-93E4-37EE48F9D386@cisco.com> <50F560B9-787C-4B90-903B-28F27E67CF85@huawei.com> <132FFEDA-A10E-4CF2-9090-B2BBD274F6BA@huawei.com> <003601ca10f1$937bfe60$62128182@china.huawei.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=526; t=1248954583; x=1249818583; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[secdir]=20Discussion=20from=20the=20Se curity=20Directorate |Sender:=20; bh=JGLPaNrlXZKe181ChEh0pPKc1pDhw8j3cFjheqzBF0I=; b=QZf2+blyxI/T1IF3H70OwiFegJ0evypROJgMkqA7y3od9A439X8qJw2GgR Jh547cFG7xx3jgNtldpT2lS1fulwD5fMr/dCwmisr8SKwXkebhGe5nw5egtT YTiQ+Uynfr; Authentication-Results: ams-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: '6man Chairs' <6man-chairs@tools.ietf.org>, 'Joel Jaeggli' , 6man-ads@tools.ietf.org, secdir@ietf.org, 'Kurt Erik Lindqvist' , 'Joe Abley' , 'Tina' , 'Softwire Chairs' , v6ops-ads@tools.ietf.org, softwire-ads@tools.ietf.org, behave-ads@tools.ietf.org, 'Behave Chairs' Subject: Re: [secdir] Discussion from the Security Directorate 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, 30 Jul 2009 11:50:01 -0000 On Jul 30, 2009, at 10:41 AM, David Harrington wrote: > I think the real clarification that needs to be made is that this is > NOT a communication from the Security Directorate. It is a discussion > from Tina. I apologize for my confusion. I expedited it on my agenda due to my understanding that it was a formal request. Especially given that it will be discussed this afternoon in a meeting that the folks that Tina would like to do the work will not be in, I suspect this needs some further thought. From fred@cisco.com Thu Jul 30 04:56:52 2009 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 9C5CD3A68A9 for ; Thu, 30 Jul 2009 04:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.861 X-Spam-Level: X-Spam-Status: No, score=-99.861 tagged_above=-999 required=5 tests=[AWL=-9.862, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, URIBL_BLACK=20, 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 1Osh9GsD4H1G for ; Thu, 30 Jul 2009 04:56:51 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B985828C242 for ; Thu, 30 Jul 2009 04:56:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQAAC8ncUqQ/uCLe2dsb2JhbACBUpg7FiQGnnSIJ5AlBYQRgU4 X-IronPort-AV: E=Sophos;i="4.43,295,1246838400"; d="scan'208";a="46137233" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2009 11:56:51 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6UBupvY003539; Thu, 30 Jul 2009 13:56:51 +0200 Received: from dhcp-56c8.meeting.ietf.org (dhcp-10-61-102-132.cisco.com [10.61.102.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6UBuoYk009250; Thu, 30 Jul 2009 11:56:50 GMT Message-Id: <85C22B4D-F60E-47C4-95A1-2AFCB3917114@cisco.com> From: Fred Baker To: Tina In-Reply-To: <132FFEDA-A10E-4CF2-9090-B2BBD274F6BA@huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 13:56:50 +0200 References: <633E561F-48D1-42DE-A310-9E77DB0A87F1@cisco.com> <4A6D98AC.4060100@bogus.com> <5AECC74E-90A0-45DA-9D23-7DE64F3488CB@cisco.com> <04f701ca102f$3e6d2c90$7958404e@china.huawei.com> <4C4D74B8-10FA-458E-93E4-37EE48F9D386@cisco.com> <50F560B9-787C-4B90-903B-28F27E67CF85@huawei.com> <132FFEDA-A10E-4CF2-9090-B2BBD274F6BA@huawei.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7740; t=1248955011; x=1249819011; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[secdir]=20Discussion=20from=20the=20Se curity=20Directorate |Sender:=20; bh=x2aLFxvyzpqZtB5mmGVVGiS86ZxQI3tmPugp8mLGzdg=; b=Nra2Xx08GfJewn+ajvyXauGKd8QZDrcsOAqVZ9FPnfD8FbbKWEIbiWEb8W nYPZGilSbL6Y2+vPm/UhjG8MxZHqvvUACm4EtpL9mztl/sBepRFh9K0Hcdp2 E2VTHjmTHW; Authentication-Results: ams-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Joel Jaeggli , 6man-ads@tools.ietf.org, secdir@ietf.org, behave-ads@tools.ietf.org, Behave Chairs , Kurt Erik Lindqvist , Joe Abley , Softwire Chairs , v6ops-ads@tools.ietf.org, softwire-ads@tools.ietf.org Subject: Re: [secdir] Discussion from the Security Directorate 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, 30 Jul 2009 11:56:52 -0000 who is "we"? I would suggest that you make your request to the chairs of the various working groups doing the work. These include 6man (designated custodian of all things IPv6 and therefore of RFCs 3053, 3056, 4213, and 5214), behave (translation), and softwire (tunnels). On Jul 29, 2009, at 8:45 PM, Tina wrote: > Hi again:) > Some clarifications for the slides. > > a. security assessment, to evaluate the security of a transition > technology. What aspects do we need to judge and consider? > b. function recommendation, to reduce the security threat of some > kind of transition technology. When deploy this technology, what > functionalities should the device need to have? > > > B. R. > Tina > http://tinatsou.weebly.com/contact.html > > > > On Jul 29, 2009, at 5:23 PM, Tina wrote: > >> Hi Fred and David, >> The slides were sent to OPS ADs, and we discussed it a bit in OPS- >> DIR work lunch on Monday. According to the suggestion from Dan, I >> forwarded the slides to the WG chairs of v6ops and opsec. >> >> Then Fred forwarded to SEC-DIR. >> >> I mentioned Fred's email during SEC-DIR work lunch on Tuesday. >> There was discussion. >> >> I went to Tuesday v6ops session before my slides were taken. Then I >> left for some personal emergency reasons. Therefore I was not able >> to present the slides. But Fred did it. >> >> The slides will be presented in OPS Area Opening meeting in the >> Large Stage between 15:10 to 16:10. >> >> >> B. R. >> Tina >> http://tinatsou.weebly.com/contact.html >> >> >> On Jul 29, 2009, at 5:04 PM, Fred Baker wrote: >> >>> It was presented to the ops directorate as "from the security >>> directorate" on Monday, and shipped off to my working group. >>> >>> OK, Tina, over to you... >>> >>> On Jul 29, 2009, at 11:30 AM, David Harrington wrote: >>> >>>> Hi, >>>> >>>> I have a question. >>>> I am a member of the Security Directorate, and I do not remember >>>> any >>>> discussion leading to this powerpoint presentation or request. I >>>> may >>>> have missed a SECDIR session. I didn't find discussion of this >>>> powerpoint presentation in the secdir archives prior to this week. >>>> >>>> Is this a "Discussion from the Security Directorate"? If so, when >>>> was >>>> this discussed? Has the SECDIR reviewed this powerpoint slide >>>> deck and >>>> approved it being sent to working groups? >>>> >>>> David Harrington >>>> dbharrington@comcast.net >>>> ietfdbh@comcast.net >>>> dharrington@huawei.com >>>> >>>> >>>>> -----Original Message----- >>>>> From: secdir-bounces@ietf.org >>>>> [mailto:secdir-bounces@ietf.org] On Behalf Of Fred Baker >>>>> Sent: Tuesday, July 28, 2009 10:49 PM >>>>> To: Joel Jaeggli >>>>> Cc: 6man Chairs; 6man-ads@tools.ietf.org; secdir@ietf.org; >>>>> Kurt Erik Lindqvist; Joe Abley; Softwire Chairs; >>>>> v6ops-ads@tools.ietf.org; softwire-ads@tools.ietf.org; Tina >>>>> TSOU; behave-ads@tools.ietf.org; Behave Chairs >>>>> Subject: Re: [secdir] Discussion from the Security Directorate >>>>> >>>>> I'm not arguing against the request. I'm asking what it is >>>>> requesting, >>>>> as I have no idea... >>>>> >>>>> I think I know what a threat analysis is. >>>>> >>>>> What is a "security assessment" apart from a "threat >>>>> assessment"? I >>>> >>>>> told v6ops (which does not develop transition technologies, by >>>>> charter, and therefore is the absolute wrong place to send >>>>> this) that >>>>> I thought it might mean an assessment of how we might mitigate the >>>>> threats. Absent any answers from the Security Directorate >>>>> responsive >>>> >>>>> to the question, I have no idea whether I was correct. >>>>> >>>>> And what on God's Green Earth is a "function recommendation"? I >>>>> have >>>> >>>>> no idea what you want. >>>>> >>>>> Nobody from the Security Directorate was there today to deliver >>>>> the >>>> >>>>> message. If I were developing a threat assessment of that >>>>> protocol... >>>>> let's see: delivered to the wrong WG by someone who didn't know >>>>> what >>>> >>>>> the message was supposed to be using slides he didn't understand >>>>> and >>>> >>>>> the security directorate didn't take the time to explain... >>>>> >>>>> On Jul 27, 2009, at 2:08 PM, Joel Jaeggli wrote: >>>>> >>>>>> I'd probably tune the slides a bit still: >>>>>> >>>>>> Security problems show up in deployment and use, these cannot >>>> be >>>>>> thought out at all when designing the protocols >>>>>> >>>>>> Is an assertion you'll get pushback on. we have signficant >>>>> operational >>>>>> experience with variations on many of the proposed or deployed >>>>>> transition mechanisms. necessarily that experience informs both >>>> our >>>>>> current thinking and the desirability of any particular approach. >>>>>> >>>>>> bump in the wire type transition technologies certainly are an >>>> area >>>>>> potential concern for opsec >>>>>> >>>>>> Fred Baker wrote: >>>>>>> Thanks, Tina. I will add this to the IPv6 Operations >>>>> agenda, probably >>>>>>> during our second session Tuesday. >>>>>>> >>>>>>> You will note that I am copying the chairs and ADs from several >>>>>>> working >>>>>>> groups. The reason is that the primary thrust of the >>>>> comments you are >>>>>>> making apply to work being done in those working groups. Slide 5 >>>>>>> specifically requests a threat analysis, security assessment, >>>>>>> and >>>>>>> "function recommendation" on each transition technology; >>>>> these are in >>>>>>> fact being done in behave and softwires. I mention 6man because >>>>>>> marketing blather from the IPv6 form makes security claims >>>>> for IPv6, >>>>>>> which it would be good if that working group clarified. >>>>>>> >>>>>>> I do have to ask specifically what the Security >>>>> Directorate hopes to >>>>>>> find in the three documents that have been requested for each of >>>> >>>>>>> these >>>>>>> various technologies. What, specifically, is a "function >>>>>>> recommendation"? A threat analysis is a statement that >>>>> there exist >>>>>>> a set >>>>>>> of possible threats. Is a security assessment a statement about >>>> how >>>>>>> those threats are responded to? What, if the WGs don't >>>>> produce it, is >>>>>>> going to leave the Security Directorate feeling ill-used? >>>>>>> >>>>>>> On Jul 27, 2009, at 12:56 PM, Tina TSOU wrote: >>>>>>> >>>>>>>> >>>>>>>> B. R. >>>>>>>> ">http://tinatsou.weebly.com/contact.html >>>>>>> >>>>>>>> Begin forwarded message: >>>>>>>> >>>>>>>>> From: "Romascanu, Dan (Dan)" >>>>>>>>> Date: July 27, 2009 7:52:20 AM GMT+02:00 >>>>>>>>> To: Ron Bonica >>>>>>>>> Cc: Tina TSOU >>>>>>>>> Subject: FW: [OPS-DIR] Reminder: OPS-DIR working lunch >>>>>>>>> >>>>>>>>> Ron, >>>>>>>>> >>>>>>>>> This looks more like an opsec (who are not meeting this >>>>> time) or >>>>>>>>> v6ops >>>>>>>>> subject. >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Tina TSOU [mailto:tena@huawei.com] >>>>>>>>> Sent: Monday, July 27, 2009 12:02 AM >>>>>>>>> To: Romascanu, Dan (Dan) >>>>>>>>> Subject: Re: [OPS-DIR] Reminder: OPS-DIR working lunch >>>>>>>>> >>>>>>>>> Hi Dan, >>>>>>>>> Could this be discussed at OPS-DIR working lunch? >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> _______________________________________________ >>>>> secdir mailing list >>>>> secdir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/secdir >>>>> >>>> >>> >> > From fred@cisco.com Thu Jul 30 05:03:01 2009 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 7EC793A6BB1 for ; Thu, 30 Jul 2009 05:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.562 X-Spam-Level: X-Spam-Status: No, score=-99.562 tagged_above=-999 required=5 tests=[AWL=-9.563, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, URIBL_BLACK=20, 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 mfuKwPc+8OKt for ; Thu, 30 Jul 2009 05:03:00 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5642828C162 for ; Thu, 30 Jul 2009 05:02:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQAAFsocUqQ/uCKe2dsb2JhbACBUpg7FiQGnnyIJ5ApBYQRgU4 X-IronPort-AV: E=Sophos;i="4.43,295,1246838400"; d="scan'208";a="46137694" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2009 12:02:59 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6UC2xlI026699; Thu, 30 Jul 2009 14:02:59 +0200 Received: from dhcp-56c8.meeting.ietf.org (dhcp-10-61-102-132.cisco.com [10.61.102.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6UC2wZE010623; Thu, 30 Jul 2009 12:02:58 GMT Message-Id: <07CE53A0-BEA8-41C0-BE06-7E0B0B9FD7AE@cisco.com> From: Fred Baker To: Tina TSOU In-Reply-To: <85C22B4D-F60E-47C4-95A1-2AFCB3917114@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 14:02:58 +0200 References: <633E561F-48D1-42DE-A310-9E77DB0A87F1@cisco.com> <4A6D98AC.4060100@bogus.com> <5AECC74E-90A0-45DA-9D23-7DE64F3488CB@cisco.com> <04f701ca102f$3e6d2c90$7958404e@china.huawei.com> <4C4D74B8-10FA-458E-93E4-37EE48F9D386@cisco.com> <50F560B9-787C-4B90-903B-28F27E67CF85@huawei.com> <132FFEDA-A10E-4CF2-9090-B2BBD274F6BA@huawei.com> <85C22B4D-F60E-47C4-95A1-2AFCB3917114@cisco.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10578; t=1248955379; x=1249819379; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[secdir]=20Discussion=20from=20the=20Se curity=20Directorate |Sender:=20; bh=jH1wnJ1cTWgPfD5Pd4I9HsGhPt/hOYwOhXWXgZnLoFc=; b=snHBRHf1U9IgATYka/utmH3rFbGM8kXSHKaJM7btCxab/+dnfr+rV6jIYv MzpFFXX/309lgHjh9v8hta0o1RxODlPbmwT8V4+5Off4enLqG/Po7DbFSGfM HNd9teeYIq; Authentication-Results: ams-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Joel Jaeggli , 6man-ads@tools.ietf.org, secdir@ietf.org, behave-ads@tools.ietf.org, Kurt Erik Lindqvist , Joe Abley , Tina , Softwire Chairs , v6ops-ads@tools.ietf.org, softwire-ads@tools.ietf.org, Behave Chairs Subject: Re: [secdir] Discussion from the Security Directorate 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, 30 Jul 2009 12:03:01 -0000 additional drafts: http://tools.ietf.org/html/draft-despres-6rd "IPv6 Rapid Deployment on IPv4 infrastructures (6rd)", Remi Despres, 7-Apr-09, http://tools.ietf.org/html/draft-despres-sam "Scalable Multihoming across IPv6 Local-Address Routing Zones Global-Prefix/Local-Address Stateless Address Mapping (SAM)", Remi Despres, 13-Jul-09, http://tools.ietf.org/html/draft-despres-6rd "IPv6 Rapid Deployment on IPv4 infrastructures (6rd)", Remi Despres, 7-Apr-09, http://tools.ietf.org/html/draft-despres-sam "Scalable Multihoming across IPv6 Local-Address Routing Zones Global-Prefix/Local-Address Stateless Address Mapping (SAM)", Remi Despres, 13-Jul-09, http://tools.ietf.org/html/draft-denis-behave-v4v6exthdr "IPv6 destination header option for IPv4 translator mapping notification", Remi Denis-Courmont, 9-Mar-09, http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework "Framework for IPv4/IPv6 Translation", Fred Baker, Xing Li, Congxiao Bao, Kevin Yin, 6-Jul-09, http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate "IP/ICMP Translation Algorithm", Xing Li, Congxiao Bao, Fred Baker, 26-Jun-09, http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch van Beijnum, 11-Jul-09, http://tools.ietf.org/html/draft-ietf-behave-dns64 "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Philip Matthews, Iljitsch van Beijnum, 4-Jul-09, http://tools.ietf.org/html/draft-xli-behave-ivi "The CERNET IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition", Xing Li, Congxiao Bao, Maoke Chen, Hong Zhang, Jianping Wu, 13-Jun-09, http://tools.ietf.org/html/draft-wu-softwire-4over6 "4over6 Transit Solution using IP Encapsulation and MP-BGP Extensions", Jianping Wu, Yong Cui, Xing Li, Mingwei Xu, Chris Metz, 14-Apr-09, On Jul 30, 2009, at 1:56 PM, Fred Baker wrote: > who is "we"? > > I would suggest that you make your request to the chairs of the > various working groups doing the work. These include 6man > (designated custodian of all things IPv6 and therefore of RFCs 3053, > 3056, 4213, and 5214), behave (translation), and softwire (tunnels). > > On Jul 29, 2009, at 8:45 PM, Tina wrote: > >> Hi again:) >> Some clarifications for the slides. >> >> a. security assessment, to evaluate the security of a transition >> technology. What aspects do we need to judge and consider? >> b. function recommendation, to reduce the security threat of some >> kind of transition technology. When deploy this technology, what >> functionalities should the device need to have? >> >> >> B. R. >> Tina >> http://tinatsou.weebly.com/contact.html >> >> >> >> On Jul 29, 2009, at 5:23 PM, Tina wrote: >> >>> Hi Fred and David, >>> The slides were sent to OPS ADs, and we discussed it a bit in OPS- >>> DIR work lunch on Monday. According to the suggestion from Dan, I >>> forwarded the slides to the WG chairs of v6ops and opsec. >>> >>> Then Fred forwarded to SEC-DIR. >>> >>> I mentioned Fred's email during SEC-DIR work lunch on Tuesday. >>> There was discussion. >>> >>> I went to Tuesday v6ops session before my slides were taken. Then >>> I left for some personal emergency reasons. Therefore I was not >>> able to present the slides. But Fred did it. >>> >>> The slides will be presented in OPS Area Opening meeting in the >>> Large Stage between 15:10 to 16:10. >>> >>> >>> B. R. >>> Tina >>> http://tinatsou.weebly.com/contact.html >>> >>> >>> On Jul 29, 2009, at 5:04 PM, Fred Baker wrote: >>> >>>> It was presented to the ops directorate as "from the security >>>> directorate" on Monday, and shipped off to my working group. >>>> >>>> OK, Tina, over to you... >>>> >>>> On Jul 29, 2009, at 11:30 AM, David Harrington wrote: >>>> >>>>> Hi, >>>>> >>>>> I have a question. >>>>> I am a member of the Security Directorate, and I do not remember >>>>> any >>>>> discussion leading to this powerpoint presentation or request. I >>>>> may >>>>> have missed a SECDIR session. I didn't find discussion of this >>>>> powerpoint presentation in the secdir archives prior to this week. >>>>> >>>>> Is this a "Discussion from the Security Directorate"? If so, >>>>> when was >>>>> this discussed? Has the SECDIR reviewed this powerpoint slide >>>>> deck and >>>>> approved it being sent to working groups? >>>>> >>>>> David Harrington >>>>> dbharrington@comcast.net >>>>> ietfdbh@comcast.net >>>>> dharrington@huawei.com >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: secdir-bounces@ietf.org >>>>>> [mailto:secdir-bounces@ietf.org] On Behalf Of Fred Baker >>>>>> Sent: Tuesday, July 28, 2009 10:49 PM >>>>>> To: Joel Jaeggli >>>>>> Cc: 6man Chairs; 6man-ads@tools.ietf.org; secdir@ietf.org; >>>>>> Kurt Erik Lindqvist; Joe Abley; Softwire Chairs; >>>>>> v6ops-ads@tools.ietf.org; softwire-ads@tools.ietf.org; Tina >>>>>> TSOU; behave-ads@tools.ietf.org; Behave Chairs >>>>>> Subject: Re: [secdir] Discussion from the Security Directorate >>>>>> >>>>>> I'm not arguing against the request. I'm asking what it is >>>>>> requesting, >>>>>> as I have no idea... >>>>>> >>>>>> I think I know what a threat analysis is. >>>>>> >>>>>> What is a "security assessment" apart from a "threat >>>>>> assessment"? I >>>>> >>>>>> told v6ops (which does not develop transition technologies, by >>>>>> charter, and therefore is the absolute wrong place to send >>>>>> this) that >>>>>> I thought it might mean an assessment of how we might mitigate >>>>>> the >>>>>> threats. Absent any answers from the Security Directorate >>>>>> responsive >>>>> >>>>>> to the question, I have no idea whether I was correct. >>>>>> >>>>>> And what on God's Green Earth is a "function recommendation"? I >>>>>> have >>>>> >>>>>> no idea what you want. >>>>>> >>>>>> Nobody from the Security Directorate was there today to deliver >>>>>> the >>>>> >>>>>> message. If I were developing a threat assessment of that >>>>>> protocol... >>>>>> let's see: delivered to the wrong WG by someone who didn't know >>>>>> what >>>>> >>>>>> the message was supposed to be using slides he didn't >>>>>> understand and >>>>> >>>>>> the security directorate didn't take the time to explain... >>>>>> >>>>>> On Jul 27, 2009, at 2:08 PM, Joel Jaeggli wrote: >>>>>> >>>>>>> I'd probably tune the slides a bit still: >>>>>>> >>>>>>> Security problems show up in deployment and use, these cannot >>>>> be >>>>>>> thought out at all when designing the protocols >>>>>>> >>>>>>> Is an assertion you'll get pushback on. we have signficant >>>>>> operational >>>>>>> experience with variations on many of the proposed or deployed >>>>>>> transition mechanisms. necessarily that experience informs both >>>>> our >>>>>>> current thinking and the desirability of any particular >>>>>>> approach. >>>>>>> >>>>>>> bump in the wire type transition technologies certainly are an >>>>> area >>>>>>> potential concern for opsec >>>>>>> >>>>>>> Fred Baker wrote: >>>>>>>> Thanks, Tina. I will add this to the IPv6 Operations >>>>>> agenda, probably >>>>>>>> during our second session Tuesday. >>>>>>>> >>>>>>>> You will note that I am copying the chairs and ADs from several >>>>>>>> working >>>>>>>> groups. The reason is that the primary thrust of the >>>>>> comments you are >>>>>>>> making apply to work being done in those working groups. >>>>>>>> Slide 5 >>>>>>>> specifically requests a threat analysis, security assessment, >>>>>>>> and >>>>>>>> "function recommendation" on each transition technology; >>>>>> these are in >>>>>>>> fact being done in behave and softwires. I mention 6man because >>>>>>>> marketing blather from the IPv6 form makes security claims >>>>>> for IPv6, >>>>>>>> which it would be good if that working group clarified. >>>>>>>> >>>>>>>> I do have to ask specifically what the Security >>>>>> Directorate hopes to >>>>>>>> find in the three documents that have been requested for each >>>>>>>> of >>>>> >>>>>>>> these >>>>>>>> various technologies. What, specifically, is a "function >>>>>>>> recommendation"? A threat analysis is a statement that >>>>>> there exist >>>>>>>> a set >>>>>>>> of possible threats. Is a security assessment a statement about >>>>> how >>>>>>>> those threats are responded to? What, if the WGs don't >>>>>> produce it, is >>>>>>>> going to leave the Security Directorate feeling ill-used? >>>>>>>> >>>>>>>> On Jul 27, 2009, at 12:56 PM, Tina TSOU wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> B. R. >>>>>>>>> ">http://tinatsou.weebly.com/contact.html >>>>>>>> >>>>>>>>> Begin forwarded message: >>>>>>>>> >>>>>>>>>> From: "Romascanu, Dan (Dan)" >>>>>>>>>> Date: July 27, 2009 7:52:20 AM GMT+02:00 >>>>>>>>>> To: Ron Bonica >>>>>>>>>> Cc: Tina TSOU >>>>>>>>>> Subject: FW: [OPS-DIR] Reminder: OPS-DIR working lunch >>>>>>>>>> >>>>>>>>>> Ron, >>>>>>>>>> >>>>>>>>>> This looks more like an opsec (who are not meeting this >>>>>> time) or >>>>>>>>>> v6ops >>>>>>>>>> subject. >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Tina TSOU [mailto:tena@huawei.com] >>>>>>>>>> Sent: Monday, July 27, 2009 12:02 AM >>>>>>>>>> To: Romascanu, Dan (Dan) >>>>>>>>>> Subject: Re: [OPS-DIR] Reminder: OPS-DIR working lunch >>>>>>>>>> >>>>>>>>>> Hi Dan, >>>>>>>>>> Could this be discussed at OPS-DIR working lunch? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> secdir mailing list >>>>>> secdir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/secdir >>>>>> >>>>> >>>> >>> >> >