From aboba@internaut.com Tue Jan 7 15:14:12 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id PAA25184 for ; Tue, 7 Jan 2003 15:14:11 -0500 (EST) Received: from internaut.com ([64.38.134.99]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA07296 for ; Tue, 7 Jan 2003 15:14:10 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h07J4v528413 for ; Tue, 7 Jan 2003 11:04:57 -0800 Date: Tue, 7 Jan 2003 11:04:57 -0800 (PST) From: Bernard Aboba To: saag@mit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [saag] Review of Man-in-the-Middle Problem Statement draft Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: As many of you might be aware, during IETF 55, EAP WG had a discussion of an individual submission, draft-puthenkulam-eap-binding-01.txt, which described man-in-the-middle attacks possible against authentication methods working in sequence or within tunnels, where cryptographic binding is not provided. The problems described are applicable to a number of protocols and drafts in progress, including PIC, IKEv2, XAUTH, PEAP, EAP TTLS and PANA over TLS. At IETF 55, the sense of the EAP WG was that this was a problem that needed to be addressed in some way. The first step in that direction is to get a problem statement characterizing the problem and the requirements for a solution. As a first step, we've been asking for review of draft-puthenkulam-eap-binding-01.txt both by the EAP WG and the security community. Once this feedback has been resolved, then the EAP WG will consider taking the draft on as a WG work item. Comments received so far are available for examination at: http://mail.frascone.com/pipermail/eap/2002-December/000413.html http://mail.frascone.com/pipermail/eap/2003-January/000485.html We would like to solicit further feedback from the SAAG. Please address your comments to the authors, and CC: the EAP WG mailing list (eap@frascone.com). From jhargest@cnri.reston.va.us Tue Jan 14 19:43:13 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id TAA04906 for ; Tue, 14 Jan 2003 19:43:07 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA26006 for ; Tue, 14 Jan 2003 19:43:06 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17416; Tue, 14 Jan 2003 19:39:42 -0500 (EST) Message-Id: <200301150039.TAA17416@ietf.org> From: Roman Danyliw To: inch@NIC.SURFNET.NL, saag@mit.edu, IETF-Announce: ; Date: Tue, 14 Jan 2003 19:39:42 -0500 Subject: [saag] INCH WG Interim Meeting, Feb. 9, 2002 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Incident Handling WG (INCH) Interim Meeting =========================================== The INCH WG will be holding an interim meeting on February 9, 2002. This meeting is the weekend prior to the FIRST Technical Colloquium, being held in the same city. Time: SUNDAY, February 9, 2002 at 0900-??? Location: Basic Hotel Kungsgatan 27 Uppsala, Sweden Chair: Roman Danyliw Security Area Advisor: Jeffrey Schiller ---[ AGENDA ]-------------------------------------------------------- A formal agenda will be sent out in January, but the intent is to discuss: - The new I-D that is to be created from the two current data model requirements drafts, - The data model (draft-ietf-inch-iodef-00.txt) I-D, and - Early implementation experience. ----[ LOCATION ]------------------------------------------------------ Basic Hotel Kungsgatan 27 Uppsala, Sweden Phone: +46-18-480-5000 WWW: http://www.basichotel.com Single Room 990 SEK / approx. 110 USD / night Double Room 1200 SEK / approx. 133 USD / night The meeting will be held in a conference room at the Basic Hotel. Additional logistical information about Uppsala, Sweden can be found here: http://www.first.org/tc/feb2003/#hotel http://www.first.org/tc/feb2003/#transport There will be no wired or wireless connectivity provided. ----[ MAILING LIST ]---------------------------------------------------- Post: inch@nic.surfnet.nl Archive: http://listserv.surfnet.nl/archives/inch.html Subscribe: send mail to listserv@nic.surfnet.nl with "subscribe inch " in the body From rgm-sec@htt-consult.com Wed Jan 29 12:11:17 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id MAA19957 for ; Wed, 29 Jan 2003 12:11:09 -0500 (EST) Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id MAA29306 for ; Wed, 29 Jan 2003 12:10:51 -0500 (EST) Received: from port3490.htt-consult.com ([65.84.78.209]) by htt-consult.com ; Wed, 29 Jan 2003 12:10:47 -0500 Message-Id: <5.1.0.14.2.20030129120932.02bc4c98@localhost> X-Sender: rgm-sec@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 29 Jan 2003 12:10:40 -0500 To: saag@mit.edu From: Robert Moskowitz Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_502161880==_.ALT" X-Rcpt-To: Subject: [saag] FWD: NIST Key Mgmt. Drafts X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 29 Jan 2003 17:11:17 -0000 --=====================_502161880==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed NIST is requesting comments on three draft key management documents, which are available at http://csrc.nist.gov/CryptoToolkit/tkkeymgmt.html. 1. "Recommendation for Key Management, Part 1: General Guideline" provides general key management guidance for system developers and system administrators. This is a revision of a draft provided in June, 2002. Please submit comments to GuidelineComments@nist.gov by April 3, 2003. 2. "Recommendation for Key Management, Part 2: Best Practices for Key Management Organization" provides guidance for system and application owners for use in identifying appropriate organizational key management infrastructures, establishing organizational key management policies, and specifying organizational key management practices and plans. This is an initial draft of this part of the Recommendation. Please submit comments to GuidelineComments@nist.gov by May 2, 2003. 3. "Recommendation on Key Establishment Schemes" provides specifications of key establishment schemes based on standards developed by the American National Standards Institute (ANSI) X9: ANSI X9.42, Agreement of Symmetric Keys Using Discrete Logarithm Cryptography, and ANSI X9.63, Key Agreement and Key Transport Using Elliptic Curve Cryptography. Inclusion of RSA techniques as specified in ANSI X9.44, Key Establishment Using Integer Factorization Cryptography, is planned for the future. This draft is a revision of a draft provided in October, 2001. Please submit comments to kmscomments@nist.gov by April 3, 2003. Robert Moskowitz TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com --=====================_502161880==_.ALT Content-Type: text/html; charset="us-ascii" NIST is requesting comments on three draft key management documents, which are available at http://csrc.nist.gov/CryptoToolkit/tkkeymgmt.html.
1.      “Recommendation for Key Management, Part 1: General Guideline” provides general key management guidance for system developers and system administrators. This is a revision of a draft provided in June, 2002. Please submit comments to GuidelineComments@nist.gov by April 3, 2003.
2.      “Recommendation for Key Management, Part 2: Best Practices for Key Management Organization” provides guidance for system and application owners for use in identifying appropriate organizational key management infrastructures, establishing organizational key management policies, and specifying organizational key management practices and plans. This is an initial draft of this part of the Recommendation. Please submit comments to GuidelineComments@nist.gov by May 2, 2003.

3.      “Recommendation on Key Establishment Schemes” provides specifications of key establishment schemes based on standards developed by the American National Standards Institute (ANSI) X9: ANSI X9.42, Agreement of Symmetric Keys Using Discrete Logarithm Cryptography, and ANSI X9.63, Key Agreement and Key Transport Using Elliptic Curve Cryptography. Inclusion of RSA techniques as specified in ANSI X9.44, Key Establishment Using Integer Factorization Cryptography, is planned for the future. This draft is a revision of a draft provided in October, 2001. Please submit comments to kmscomments@nist.gov by April 3, 2003.


Robert Moskowitz
TruSecure Corporation
Security Interest EMail: rgm-sec@htt-consult.com --=====================_502161880==_.ALT-- From moriarty@ll.mit.edu Wed Feb 12 14:49:40 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id OAA09144 for ; Wed, 12 Feb 2003 14:49:40 -0500 (EST) Received: from ll.mit.edu (LLMAIL.LL.MIT.EDU [129.55.12.40]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA06377 for ; Wed, 12 Feb 2003 14:49:40 -0500 (EST) Received: (from smtp@localhost) by ll.mit.edu (8.11.3/8.8.8) id h1CJncb04214 for ; Wed, 12 Feb 2003 14:49:38 -0500 (EST) Received: from kmoriarty.llan.ll.mit.edu( ), claiming to be "ll.mit.edu" via SMTP by llpost, id smtpdAAAaga4xe; Wed Feb 12 14:49:19 2003 Message-ID: <3E4AA5C9.4020800@ll.mit.edu> Date: Wed, 12 Feb 2003 14:51:37 -0500 From: Kathleen Moriarty User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Communication between network providers to trace attacks X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 12 Feb 2003 19:49:41 -0000 Hello, I posted a new version of an Internet draft to the IETF on Real-time Inter-network Defense against Denial of Service attacks. The draft proposes a mechanism to communicate trace requests across multiple networks. Please send me an email message if you would like to be on the mailing list, any feedback would be appreciated. The abstract and link for the draft are included below. Thank you, Kathleen Title : Distributed Denial of Service Incident Handling: Real-Time Inter-Network Defense Author(s) : K. Moriarty Filename : draft-moriarty-ddos-rid-03.txt Pages : 32 Date : 2003-2-11 One of the latest trends attacking Internet security is the increasing prevalence of Denial of Service (DoS) attacks. DoS attacks target system and/or network resources and seek to prevent valid access by consuming resources. Network Providers (NP) need to be equipped and ready to assist in tracing security incidents with tools and procedures in place before the occurrence of an attack. This paper proposes a proactive inter-network communication method to integrate existing tracing mechanisms across NP boundaries to identify the source(s) of an attack. The various methods implemented to trace attacks must be coordinated both on the NPs network as well as provide a communication mechanism across network borders. It is imperative that NPs have quick communication methods defined to enable neighboring NPs to assist in tracking a security incident across the Internet. This proposal makes use of current tracing practices for traffic and performance management, which could be extended for DoS incident handling. Policy guidelines for handling these incidents are recommended and can be used by NPs and extended to their clients in conjunction with the technical recommendations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-moriarty-ddos-rid-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-moriarty-ddos-rid-03.txt". Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-moriarty-ddos-rid-03.txt". ____________________________ Kathleen M. Moriarty moriarty@ll.mit.edu From rgm-sec@htt-consult.com Thu Feb 20 17:04:21 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id RAA25408 for ; Thu, 20 Feb 2003 17:04:17 -0500 (EST) Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id RAA24901 for ; Thu, 20 Feb 2003 17:04:14 -0500 (EST) Received: from port3490.htt-consult.com ([65.84.78.209]) by htt-consult.com ; Thu, 20 Feb 2003 17:04:14 -0500 Message-Id: <5.1.0.14.2.20030220140308.02b28900@localhost> X-Sender: rgm-sec@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 20 Feb 2003 14:04:01 -0800 To: saag@mit.edu From: Robert Moskowitz Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Rcpt-To: Subject: [saag] Of potential interest -- Citibank tries to gag crypto bug disclosure X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 20 Feb 2003 22:04:21 -0000 >To: ukcrypto@chiark.greenend.org.uk >Subject: Citibank tries to gag crypto bug disclosure >Date: Thu, 20 Feb 2003 09:57:34 +0000 >From: Ross Anderson > > >Citibank is trying to get an order in the High Court today gagging >public disclosure of crypto vulnerabilities: > > http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_gag.pdf > >I have written to the judge opposing the order: > > http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_response.pdf > >The background is that my student Mike Bond has discovered some really >horrendous vulnerabilities in the cryptographic equipment commonly >used to protect the PINs used to identify customers to cash machines: > > http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-560.pdf > >These vulnerabilities mean that bank insiders can almost trivially >find out the PINs of any or all customers. The discoveries happened >while Mike and I were working as expert witnesses on a `phantom >withdrawal' case. > >The vulnerabilities are also scientifically interesting: > > http://cryptome.org/pacc.htm > >For the last couple of years or so there has been a rising tide of >phantoms. I get emails with increasing frequency from people all over >the world whose banks have debited them for ATM withdrawals that they >deny making. Banks in many countries simply claim that their systems >are secure and so the customers must be responsible. It now looks like >some of these vulnerabilities have also been discovered by the bad >guys. Our courts and regulators should make the banks fix their >systems, rather than just lying about security and dumping the costs >on the customers. > >Curiously enough, Citi was also the bank in the case that set US law >on phantom withdrawals from ATMs (Judd v Citibank). They lost. I hope >that's an omen, if not a precedent ... > >Ross Anderson Robert Moskowitz TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com From aboba@internaut.com Thu Feb 20 20:35:19 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id UAA27679 for ; Thu, 20 Feb 2003 20:35:18 -0500 (EST) Received: from internaut.com ([64.38.134.99]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id UAA11360 for ; Thu, 20 Feb 2003 20:35:18 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1L0M5J19857 for ; Thu, 20 Feb 2003 16:22:05 -0800 Date: Thu, 20 Feb 2003 16:22:05 -0800 (PST) From: Bernard Aboba To: saag@mit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [saag] Review of 3GPP authentication methods? X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 21 Feb 2003 01:35:20 -0000 3GPP has a list of work items they have asked that the IETF take on, for publication as RFCs: http://www.3gpp.org/TB/Other/IETF.htm Included on the list is EAP SIM and EAP AKA: http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-09.txt http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-08.txt I'm curious if anyone in the SAAG has reviewed these and has an opinion on the level of security provided, for use in wireless authentication. From rgm-sec@htt-consult.com Fri Feb 21 13:38:30 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id NAA06705 for ; Fri, 21 Feb 2003 13:38:30 -0500 (EST) Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id NAA29077 for ; Fri, 21 Feb 2003 13:38:27 -0500 (EST) Received: from port3490.htt-consult.com ([65.84.78.209]) by htt-consult.com ; Fri, 21 Feb 2003 13:38:27 -0500 Message-Id: <5.1.0.14.2.20030221133500.02b3e160@localhost> X-Sender: rgm-sec@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 21 Feb 2003 13:38:24 -0500 To: saag@mit.edu From: Robert Moskowitz In-Reply-To: <5.1.0.14.2.20030220140308.02b28900@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Rcpt-To: Subject: [saag] Update to RFC 2828? X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 21 Feb 2003 18:38:31 -0000 I seem to recall an Internet Draft that updated Rob's opus, but can't find it. Does anyone have the draft name? Did it expire? Or did the RFC get issued? Robert Moskowitz TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com From Jeff.Hodges@KingsMountain.com Fri Feb 28 14:18:16 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id OAA23295 for ; Fri, 28 Feb 2003 14:18:16 -0500 (EST) From: Jeff.Hodges@KingsMountain.com Received: from networking.Stanford.EDU (networking.Stanford.EDU [171.64.20.23]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA02616 for ; Fri, 28 Feb 2003 14:18:15 -0500 (EST) Received: from networking.Stanford.EDU (hodges@localhost) by networking.Stanford.EDU (8.11.6/8.11.6) with ESMTP id h1SJIEm25674 for ; Fri, 28 Feb 2003 11:18:14 -0800 (PST) Message-Id: <200302281918.h1SJIEm25674@networking.Stanford.EDU> X-Authentication-Warning: networking.Stanford.EDU: hodges owned process doing -bs X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: SAAG list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Feb 2003 11:18:14 -0800 Subject: [saag] XACML Spec and open source implementation X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 28 Feb 2003 19:18:17 -0000 The eXtensible Access Control Markup Language (XACML) specification set 1.0, developed at OASIS, was recently announced and is likely to be of interest to some SAAG readers. It specifies XML schema for a policy language, and a simple request-response protocol for making policy queries. The committee's home page is at: http://www.oasis-open.org/committees/xacml/ An associated open soure XACML implementation project was recently spun up at SourceForge, with an initial implementation contributed by Sun. The material below is taken from the opening page of the sourceforge.net XACML project website. JeffH ---------- Forwarded Material ---------- Announcement: XACML Open Source Implementation Project ------------------------------------------------------ XACML ::= "eXtensible Access Control Markup Language" The XACML open source impl project is housed here.. http://sunxacml.sourceforge.net/ XACML itself is a work product of the OASIS XACML Technical Committee, whose home is here.. http://www.oasis-open.org/committees/xacml/ And the XACML 1.0 spec set itself is available here.. http://www.oasis-open.org/committees/xacml/#documents >From the SourceForge XACML project webpage... Welcome to Sun's XACML Implementation! This is an open source implementation of the OASIS XACML standard, written in the JavaTM programming language. For more information about XACML look at our FAQ, the Programmer's Guide or the XACML TC web page. Sun's XACML Implementation requires the Java 2 Platform, Standard Edition version 1.4 or later. This project provides complete support for all the mandatory features of XACML as well as a number of optional features. Specifically, there is full support for parsing both policy and request/response documents, determining applicability of policies, and evaluating requests against policies. All of the standard attribute types, functions, and combining algorithms are supported, and there are APIs for adding new functionality as needed. There are also APIs for writing new retrieval mechanisms used for finding things like policies and attributes. This project was developed in Sun Microsystems Laboratories, part of Sun Microsystems, Inc., and is part of an ongoing project on Internet Authorization in the Internet Security Research Group. Going forward, we have a host of features we'd like to add to this project, including better configurability, support for some of the up and coming standards to connect XACML and things like SAML or LDAP, and strong tools support. If you'd like to get involved please mail the project administrator: sethp@users.sourceforge.net Introduction to XACML XACML (eXtensible Access Control Markup Language) is an XML-based language for access control that has been standardized in OASIS. XACML describes both an access control policy language and a request/response language. The policy language is used to express access control policies (who can do what when). The request/response language expresses queries about whether a particular access should be allowed (requests) and describes answers to those queries (responses). In a typical XACML usage scenario, a subject (e.g. human user, workstation) wants to take some action on a particular resource. The subject submits its query to the entity protecting the resource (e.g. filesystem, web server). This entity is called a Policy Enforcement Point (PEP). The PEP forms a request (using the XACML request language) based on the attributes of the subject, action, resource, and other relevant information. The PEP then sends this request to a Policy Decision Point (PDP), which examines the request, retrieves policies (written in the XACML policy language) that are applicable to this request, and determines whether access should be granted according to the XACML rules for evaluating policies. That answer (expressed in the XACML response language) is returned to the PEP, which can then allow or deny access to the requester. XACML has many benefits over other access control policy languages: * One standard access control policy language can replace dozens of application-specific languages * Administrators save time and money because they don't need to rewrite their policies in many different languages * Developers save time and money because they don't have to invent new policy languages and write code to support them. They can reuse existing code * Good tools for writing and managing XACML policies will be developed, since they can be used with many applications * XACML is flexible enough to accommodate most access control policy needs and extensible so that new requirements can be supported. * One XACML policy can cover many resources. This helps avoid inconsistent policies on different resources. * XACML allows one policy to refer to another. This is important for large organizations. For instance, a site-specific policy may refer to a company-wide policy and a country-specific policy. Acknowledgments This project comes from the Internet Security Research Group (ISRG) in Sun Microsystems Laboratories. The ISRG is Anne Anderson, Yassir Elley, Steve Hanna, Radia Perlman and Seth Proctor. We would also like to thank the following for their help, advice, contributions, and general sanity: Members of the OASIS XACML TC, Marco Barreno, Miriam Kadansky and Steve Heller. Get Involved! There is lots of cool stuff to work on in this project. If you'd like to get involved send mail to the project lead: sethp@users.sourceforge.net --- end From rgm-sec@htt-consult.com Mon Mar 3 09:07:45 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id JAA01815 for ; Mon, 3 Mar 2003 09:07:44 -0500 (EST) Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id JAA27719 for ; Mon, 3 Mar 2003 09:07:37 -0500 (EST) Received: from port3490.htt-consult.com ([65.84.78.209]) by htt-consult.com ; Mon, 03 Mar 2003 09:07:43 -0500 Message-Id: <5.1.0.14.2.20030303090358.02b4da38@localhost> X-Sender: rgm-sec@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 03 Mar 2003 09:05:18 -0500 To: saag@mit.edu From: Robert Moskowitz Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Rcpt-To: Subject: [saag] Roger Needham rip X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 03 Mar 2003 14:07:45 -0000 From: Jon Crowcroft our ex chair of dept and head of microsoft research europe passed away on friday he may not be familiar to all of you unless perhaps you know origins of kerberos info at http://www.cl.cam.ac.uk/~ksj/RogerNeedham.html Further info: http://www.research.microsoft.com/~aherbert/volume.pdf Robert Moskowitz TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com From redkresearch@yahoo.com.sg Thu Mar 6 21:36:28 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8/8.12.8) with ESMTP id h272aSIs025086 for ; Thu, 6 Mar 2003 21:36:28 -0500 (EST) Received: from web14802.mail.yahoo.com (web14802.mail.yahoo.com [216.136.224.218]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id VAA16044 for ; Thu, 6 Mar 2003 21:36:16 -0500 (EST) Message-ID: <20030307023401.89935.qmail@web14802.mail.yahoo.com> Received: from [137.132.3.10] by web14802.mail.yahoo.com via HTTP; Fri, 07 Mar 2003 10:34:01 CST Date: Fri, 7 Mar 2003 10:34:01 +0800 (CST) From: =?iso-8859-1?q?Redk=20Redk?= To: saag@mit.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-265208690-1047004441=:88468" Content-Transfer-Encoding: 8bit Subject: [saag] question about SPKI X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Mar 2003 02:36:29 -0000 --0-265208690-1047004441=:88468 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, I want to ask some questions about SPKI rfc2693. I don't understand the meaning for the following formulas in section 6.4 1. [(name K1 N) -> K2] 2. [(name K1 N) -> (name K2 N1 N2 ... Nk)] Thank you very much! Best Regards RedK Yahoo! Biztools - Promote your business from just $5 a month! --0-265208690-1047004441=:88468 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi,

I want to ask some questions about SPKI rfc2693.

I don't understand the meaning for the following
formulas in section 6.4

1. [(name K1 N) -> K2]
2. [(name K1 N) -> (name K2 N1 N2 ... Nk)]

Thank you very much!

Best Regards
RedK

Yahoo! Biztools
- Promote your business from just $5 a month! --0-265208690-1047004441=:88468-- From warlord@MIT.EDU Fri Mar 7 12:01:06 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8/8.12.8) with ESMTP id h27H15Is011181 for ; Fri, 7 Mar 2003 12:01:05 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82])MAA01497; Fri, 7 Mar 2003 12:01:00 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86])MAA08659; Fri, 7 Mar 2003 12:01:00 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) h27H0x9i002812; Fri, 7 Mar 2003 12:00:59 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA05304; Fri, 7 Mar 2003 12:00:59 -0500 (EST) To: Redk Redk From: Derek Atkins Subject: Re: [saag] question about SPKI References: <20030307023401.89935.qmail@web14802.mail.yahoo.com> Date: 07 Mar 2003 12:00:59 -0500 In-Reply-To: <20030307023401.89935.qmail@web14802.mail.yahoo.com> Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: saag@MIT.EDU X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Mar 2003 17:01:06 -0000 Hi, You may want to ask this on the SPKI list, spki@c2.net -derek Redk Redk writes: > Hi, > > I want to ask some questions about SPKI rfc2693. > > I don't understand the meaning for the following > formulas in section 6.4 > > 1. [(name K1 N) -> K2] > 2. [(name K1 N) -> (name K2 N1 N2 ... Nk)] > > Thank you very much! -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From carl.m.ellison@intel.com Fri Mar 7 14:30:21 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8/8.12.8) with ESMTP id h27JULIs012627 for ; Fri, 7 Mar 2003 14:30:21 -0500 (EST) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA16865 for ; Fri, 7 Mar 2003 14:30:20 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) 20:43:23 dmccart Exp $) with ESMTP id h27JNrM13664 for ; Fri, 7 Mar 2003 19:23:53 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124])19:44:39 dmccart Exp $) with SMTP id h27JOh201978 for ; Fri, 7 Mar 2003 19:24:44 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) M2003030711303127385 ; Fri, 07 Mar 2003 11:30:31 -0800 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 11:30:15 -0800 Message-ID: From: "Ellison, Carl M" To: Russ Housley , "Ellison, Carl M" , saag@mit.edu Subject: RE: [saag] question about SPKI Date: Fri, 7 Mar 2003 11:30:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Mar 2003 19:30:22 -0000 The notation is meant to convey that a SDSI name certificate is a group membership certificate - that is, that the subject of the certificate is included as a member in the named group. There are two subjects of interest here (in the order of the two examples you listed): 1. an individual key or 2. any SDSI name (i.e.., any named group) In case #2, the members of that subgroup become members of the group named in this certificate. That binding is deferred. That is, if we have the certificates: (cert (issuer (name K0 GroupA)) (subject (name K1 GroupB)) ) and (cert (issuer (name K1 GroupB)) (subject K3) ) then K3 is a member of two groups: (name K0 GroupA) and (name K1 GroupB) - Carl Additional documentation is available at http://theory.lcs.mit.edu/~cis/sdsi.html and http://theworld.com/~cme/html/spki.html +--------------------------------------------------------+ |Carl Ellison Intel R & D E: cme@jf.intel.com | |2111 NE 25th Ave T: +1-503-264-2900 | |Hillsboro OR 97124 F: +1-503-264-6225 | |PGP Key ID: 0xFE5AF240 | | 1FDB 2770 08D7 8540 E157 AAB4 CC6A 0466 FE5A F240 | +--------------------------------------------------------+ -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Friday, March 07, 2003 7:16 AM To: carl.m.ellison@intel.com Subject: Fwd: [saag] question about SPKI Delivered-To: housley@mail.binhost.com Delivered-To: alias-582@vigilsec.com Date: Fri, 7 Mar 2003 10:34:01 +0800 (CST) From: Redk Redk To: saag@mit.edu Subject: [saag] question about SPKI X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Sender: saag-bounces@mit.edu Hi, I want to ask some questions about SPKI rfc2693. I don't understand the meaning for the following formulas in section 6.4 1. [(name K1 N) -> K2] 2. [(name K1 N) -> (name K2 N1 N2 ... Nk)] Thank you very much! Best Regards RedK Yahoo! Biztools - Promote your business from just $5 a month! _______________________________________________ saag mailing list saag@mit.edu https://jis.mit.edu/mailman/listinfo/saag From carl.m.ellison@intel.com Fri Mar 7 14:16:30 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8/8.12.8) with ESMTP id h27JGUIs012495 for ; Fri, 7 Mar 2003 14:16:30 -0500 (EST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA06259 for ; Fri, 7 Mar 2003 14:16:29 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) 20:43:23 dmccart Exp $) with ESMTP id h27JDBq25048 for ; Fri, 7 Mar 2003 19:13:11 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124])19:44:39 dmccart Exp $) with SMTP id h27JAu216077 for ; Fri, 7 Mar 2003 19:10:56 GMT Received: from FMSMSX016.fm.intel.com ([132.233.42.195]) M2003030711164418711 ; Fri, 07 Mar 2003 11:16:44 -0800 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 11:16:28 -0800 Message-ID: From: "Ellison, Carl M" To: Russ Housley , "Ellison, Carl M" , saag@mit.edu Subject: RE: [saag] question about SPKI Date: Fri, 7 Mar 2003 11:16:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Mailman-Approved-At: Sun, 09 Mar 2003 12:11:15 -0500 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Mar 2003 19:16:31 -0000 The notation is meant to convey that a SDSI name certificate is a group membership certificate - that is, that the subject of the certificate is included as a member in the named group. There are two subjects of interest here (in the order of the two examples you listed): 1. an individual key or 2. any SDSI name (i.e.., any named group) In case #2, the members of that subgroup become members of the group named in this certificate. That binding is deferred. That is, if we have the certificates: (cert (issuer (name K0 GroupA)) (subject (name K1 GroupB)) ) and (cert (issuer (name K1 GroupB)) (subject K3) ) then K3 is a member of two groups: (name K0 GroupA) and (name K1 GroupB) - Carl Additional documentation is available at http://theory.lcs.mit.edu/~cis/sdsi.html and http://theworld.com/~cme/html/spki.html +--------------------------------------------------------+ |Carl Ellison Intel R & D E: cme@jf.intel.com | |2111 NE 25th Ave T: +1-503-264-2900 | |Hillsboro OR 97124 F: +1-503-264-6225 | |PGP Key ID: 0xFE5AF240 | | 1FDB 2770 08D7 8540 E157 AAB4 CC6A 0466 FE5A F240 | +--------------------------------------------------------+ -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Friday, March 07, 2003 7:16 AM To: carl.m.ellison@intel.com Subject: Fwd: [saag] question about SPKI Delivered-To: housley@mail.binhost.com Delivered-To: alias-582@vigilsec.com Date: Fri, 7 Mar 2003 10:34:01 +0800 (CST) From: Redk Redk To: saag@mit.edu Subject: [saag] question about SPKI X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Sender: saag-bounces@mit.edu Hi, I want to ask some questions about SPKI rfc2693. I don't understand the meaning for the following formulas in section 6.4 1. [(name K1 N) -> K2] 2. [(name K1 N) -> (name K2 N1 N2 ... Nk)] Thank you very much! Best Regards RedK Yahoo! Biztools - Promote your business from just $5 a month! _______________________________________________ saag mailing list saag@mit.edu https://jis.mit.edu/mailman/listinfo/saag From Gregory@netscreen.com Thu Mar 20 19:11:11 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8/8.12.8) with ESMTP id h2L0BBIs015439 for ; Thu, 20 Mar 2003 19:11:11 -0500 (EST) Received: from mail1.netscreen.com (mail1.netscreen.com [63.126.135.16]) h2L0BAXi009836 for ; Thu, 20 Mar 2003 19:11:10 -0500 (EST) Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) h2L06x604706 for ; Thu, 20 Mar 2003 16:06:59 -0800 (PST) Received: by NS-CA.netscreen.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Mar 2003 16:08:14 -0800 Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66B21@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'saag@mit.edu'" Date: Thu, 20 Mar 2003 16:06:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [saag] www.drizzle.com/~aboba/IETF56 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 21 Mar 2003 00:11:11 -0000 From housley@vigilsec.com Thu Mar 20 19:11:39 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8/8.12.8) with ESMTP id h2L0BcIs015455 for ; Thu, 20 Mar 2003 19:11:38 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) h2L0BTxW006905 for ; Thu, 20 Mar 2003 19:11:29 -0500 (EST) Received: (qmail 4856 invoked from network); 21 Mar 2003 00:11:06 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (130.129.132.209) by woodstock.binhost.com with SMTP; 21 Mar 2003 00:11:06 -0000 Message-Id: <5.2.0.9.2.20030320191013.0305ce50@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Mar 2003 19:11:21 -0500 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [saag] compound authentication binding problem slides X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 21 Mar 2003 00:11:39 -0000 Here is the URL for the slides used in today's presentation. http://www.drizzle.com/~aboba/IETF56/EAP/EAP-Binding-Problem-0303.ppt Enjoy, Russ From aboba@internaut.com Thu Mar 20 22:48:24 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8/8.12.8) with ESMTP id h2L3mOIs022435 for ; Thu, 20 Mar 2003 22:48:24 -0500 (EST) Received: from internaut.com ([64.38.134.99])h2L3mNOU018761 for ; Thu, 20 Mar 2003 22:48:23 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2L2WWI15680 for ; Thu, 20 Mar 2003 18:32:36 -0800 Date: Thu, 20 Mar 2003 18:32:32 -0800 (PST) From: Bernard Aboba To: saag@mit.edu In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87E66B21@SARATOGA.netscreen.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [saag] Slides from EAP and AAA WGs X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 21 Mar 2003 03:48:24 -0000 Are available at: http://www.drizzle.com/~aboba/IETF56/EAP/ http://www.drizzle.com/~aboba/IETF56/AAA/ From Marc.Blanchet@viagenie.qc.ca Fri Mar 21 00:40:06 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8/8.12.8) with ESMTP id h2L5e6Is023401 for ; Fri, 21 Mar 2003 00:40:06 -0500 (EST) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) h2L5e6Id004891 for ; Fri, 21 Mar 2003 00:40:06 -0500 (EST) Received: from localhost (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id h2L5diu67474; Fri, 21 Mar 2003 00:39:44 -0500 (EST) Date: Fri, 21 Mar 2003 00:39:19 -0500 From: Marc Blanchet To: Bernard Aboba , saag@mit.edu Subject: Re: [saag] Slides from EAP and AAA WGs Message-ID: <34010000.1048225159@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 21 Mar 2003 05:40:07 -0000 -- jeudi, mars 20, 2003 18:32:32 -0800 Bernard Aboba wrote/a ecrit: > Are available at: > > http://www.drizzle.com/~aboba/IETF56/EAP/ > http://www.drizzle.com/~aboba/IETF56/AAA/ AAA empty as of march 21, 21H30 pacific time. Marc. > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag From aboba@internaut.com Fri Mar 21 11:05:56 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8/8.12.8) with ESMTP id h2LG5rIs028370 for ; Fri, 21 Mar 2003 11:05:53 -0500 (EST) Received: from internaut.com ([64.38.134.99])h2LG5rPN003264 for ; Fri, 21 Mar 2003 11:05:53 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2LEo2t25625; Fri, 21 Mar 2003 06:50:03 -0800 Date: Fri, 21 Mar 2003 06:50:02 -0800 (PST) From: Bernard Aboba To: Marc Blanchet Subject: Re: [saag] Slides from EAP and AAA WGs In-Reply-To: <34010000.1048225159@classic.viagenie.qc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 21 Mar 2003 16:05:56 -0000 > AAA empty as of march 21, 21H30 pacific time. The AAA WG slides are now available. From info@caitr.org Thu Mar 27 10:20:47 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8/8.12.8) with ESMTP id h2RFKlIs016396 for ; Thu, 27 Mar 2003 10:20:47 -0500 (EST) Received: from web14809.mail.yahoo.com (web14809.mail.yahoo.com [216.136.224.230])h2RFKkLw011177 for ; Thu, 27 Mar 2003 10:20:47 -0500 (EST) Message-ID: <20030327152043.68504.qmail@web14809.mail.yahoo.com> Received: from [65.213.193.49] by web14809.mail.yahoo.com via HTTP; Thu, 27 Mar 2003 07:20:43 PST Date: Thu, 27 Mar 2003 07:20:43 -0800 (PST) From: CAITR To: saag@mit.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-695082535-1048778443=:68183" Subject: [saag] Internetworking 2003: Call for Papers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: info@caitr.org List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 27 Mar 2003 15:20:48 -0000 --0-695082535-1048778443=:68183 Content-Type: text/plain; charset=us-ascii Dear Colleagues: Our sincere apologies if you receive multiple copies of this announcement. CONFERENCE ANNOUNCEMENT AND CALL FOR PRESENTATIONS Internetworking 2003 June 22-24, 2003 San Jose, California In technical cooperation with IEEE, IFIP, and ACM (Pending) Internetworking 2003 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following: - Voice over IP (VoIP) - IP Video Conferencing - Storage Area Networks (SANs) - Unicast and Multicast Routing and Convergence - QoS Routing - Network Security and Service Integration - Operational Support Systems - Virtual Private Networks - Internetworking Wireless LANs and 3G Wireless Networks - IP-based Infrastructure for Wireless Networks - Internetworking IP and Optical Networks - Internetworking MPLS with Legacy ATM and Frame Relay Networks - Transition from IPv4 to IPv6 and interworking - Pervasive Computing - High Speed Transport Layer Protocols - Peer to Peer Networking and Grid Computing - Video Teleconferencing (VTC) - 802.11 Hotspots The Internetworking 2003 event in June will include participation from industry, government agencies, and academia. If you need additional technical information, please contact the Technical Cochairs Professor Maurice GAGNAIRE , or Daniel Awduche . --0-695082535-1048778443=:68183 Content-Type: text/html; charset=us-ascii

Dear Colleagues:

Our sincere apologies if you receive multiple copies of this announcement.

     CONFERENCE ANNOUNCEMENT AND CALL FOR PRESENTATIONS

                   Internetworking 2003
                      June 22-24, 2003
                   San Jose, California
      In technical cooperation with IEEE, IFIP, and ACM (Pending)


Internetworking 2003 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following:

- Voice over IP (VoIP)
- IP Video Conferencing
- Storage Area Networks (SANs)
- Unicast and Multicast Routing and Convergence
- QoS Routing
- Network Security and Service Integration
- Operational Support Systems
- Virtual Private Networks
- Internetworking Wireless LANs and 3G Wireless Networks
- IP-based Infrastructure for Wireless Networks
- Internetworking IP and Optical Networks
- Internetworking MPLS with Legacy ATM and Frame Relay Networks
- Transition from IPv4 to IPv6 and interworking
- Pervasive Computing
- High Speed Transport Layer Protocols
- Peer to Peer Networking and Grid Computing
- Video Teleconferencing (VTC)
- 802.11 Hotspots


The Internetworking 2003 event in June will include participation from industry, government agencies, and academia. If you need additional technical information, please contact the Technical Cochairs Professor Maurice GAGNAIRE <gagnaire@enst.fr>, or Daniel Awduche <Awduche@awduche.com>.

--0-695082535-1048778443=:68183-- From info@caitr.org Mon Apr 7 12:05:57 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h37G5qkd017408 for ; Mon, 7 Apr 2003 12:05:57 -0400 (EDT) Received: from web41813.mail.yahoo.com (web41813.mail.yahoo.com [66.218.93.147])h37G5p1K000372 for ; Mon, 7 Apr 2003 12:05:52 -0400 (EDT) Message-ID: <20030407160550.60103.qmail@web41813.mail.yahoo.com> Received: from [65.213.193.49] by web41813.mail.yahoo.com via HTTP; Mon, 07 Apr 2003 09:05:50 PDT Date: Mon, 7 Apr 2003 09:05:50 -0700 (PDT) From: CAITR To: saag@mit.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-668037057-1049731550=:59261" Subject: [saag] Internetworking 2003: Call for Papers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: info@caitr.org List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 07 Apr 2003 16:05:58 -0000 --0-668037057-1049731550=:59261 Content-Type: text/plain; charset=us-ascii Call for Papers ============== Internetworking 2003, June 22-24, 2003, San Jose, California http://www.caitr.org/internetworking03/index.htm REMINDER: Deadline for submissions is April 11, 2003 The Internetworking 2003 Technical Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following: - Voice over IP (VoIP) - IP Video Conferencing - Storage Area Networks (SANs) - Unicast and Multicast Routing and Convergence - QoS Routing - Network Security and Service Integration - Operational Support Systems - Virtual Private Networks - Internetworking Wireless LANs and 3G Wireless Networks - IP-based Infrastructure for Wireless Networks - Internetworking IP and Optical Networks - Internetworking MPLS with Legacy ATM and Frame Relay Networks - Transition from IPv4 to IPv6 and interworking - Pervasive Computing - High Speed Transport Layer Protocols - Peer to Peer Networking and Grid Computing - Video Teleconferencing (VTC) - 802.11 Hotspots Conference Technical Co-chairs: - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Vishal Sharma, Metanoia - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez, Co-chair, IETF Working Group on IP Storage - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Tony Przygienda, Co-chair, IETF Working Group on IS-IS for IP Internets - Ran Canetti, Co-chair, IETF Working Group on Multicast Security --0-668037057-1049731550=:59261 Content-Type: text/html; charset=us-ascii

Call for Papers
==============

Internetworking 2003, June 22-24, 2003, San Jose, California
http://www.caitr.org/internetworking03/index.htm

REMINDER: Deadline for submissions is April 11, 2003

The Internetworking 2003 Technical Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following:

- Voice over IP (VoIP)
- IP Video Conferencing
- Storage Area Networks (SANs)
- Unicast and Multicast Routing and Convergence
- QoS Routing
- Network Security and Service Integration
- Operational Support Systems
- Virtual Private Networks
- Internetworking Wireless LANs and 3G Wireless Networks
- IP-based Infrastructure for Wireless Networks
- Internetworking IP and Optical Networks
- Internetworking MPLS with Legacy ATM and Frame Relay Networks
- Transition from IPv4 to IPv6 and interworking
- Pervasive Computing
- High Speed Transport Layer Protocols
- Peer to Peer Networking and Grid Computing
- Video Teleconferencing (VTC)
- 802.11 Hotspots

Conference Technical Co-chairs:
- Dr. Maurice Gagnaire, ENST, France
- Daniel Awduche

Technical Program Committee of the Internetworking 2003 Conference:
- Roberto Sabella, Erisson
- Dr. Moshe Zukerman, Univ. of Melbourne
- Nada Golmie, NIST
- Dr. Guy Pujolle, LIP6, France
- Dr. Samir Tohme, ENST, France
- Stefano Trumpy, Italian National Research Council
- Dr. Ibrahim Habib, City Univ. of NY
- Dr. Vishal Sharma, Metanoia
- Dr. Parviz Yegani, Cisco Systems
- Dr. G.S. Kuo
- Dr. Abbas Jamalipour, Univ. of Sydney
- Dr. Hussein Mouftah, Univ. of Ottawa
- James Kempf
- Elizabeth Rodriguez, Co-chair, IETF Working Group on IP Storage
- Dr. Ferit Yegenoglu, Isocore
- Dr. Ali Zadeh, George Mason University
- Tony Przygienda, Co-chair, IETF Working Group on IS-IS for IP Internets
- Ran Canetti, Co-chair, IETF Working Group on Multicast Security

--0-668037057-1049731550=:59261-- From mcgrew@cisco.com Fri Apr 11 17:28:33 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h3BLSW41013861 for ; Fri, 11 Apr 2003 17:28:32 -0400 (EDT) Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) h3BLSWik012837 for ; Fri, 11 Apr 2003 17:28:32 -0400 (EDT) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3BLSTmi010966; Fri, 11 Apr 2003 14:28:29 -0700 (PDT) Received: from MCGREWW2K (stealth-10-34-251-100.cisco.com [10.34.251.100]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AGA76319; Fri, 11 Apr 2003 14:26:57 -0700 (PDT) From: "David A. Mcgrew" To: Date: Fri, 11 Apr 2003 14:28:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal cc: saag@mit.edu Subject: [saag] Comments on draft-bellovin-mandate-keymgmt-00.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 11 Apr 2003 21:28:33 -0000 Steve, I'm glad that the you're writing up this kind of guideline. Publishing documents outlining policy will help coordinate security work across the IETF. The draft looks pretty good, though I have a couple of questions and a bunch of detailed comments. I like that the draft discusses "automated key management" rather than a key management protocol. This inclusiveness allows systems that don't use explicit key management messages, but that derive session keys from other implicit information, to meet the security requirements. This is surely the right way to go. However, this fact makes me think that "limited available bandwidth or very high round-trip times" (mentioned at the end of Section 2) isn't a valid motivation for not using automated key management. The injunction that automated key management must be used if "a stream cipher such as RC4 or AES counter mode [AESMODE] is used" is certainly needed. But this injunction ought to also be applied to all cipher modes that use implicit IVs rather than explicit random IVs, at least if the re-use of a key would lead to the re-use of IV values. This is the case if the implicit IV generation method defined in Appendix C of [AESMODE] is used. The fundamental cryptographic issue here is that ciphers that implement randomized encryption (e.g. use an random IV) require less synchronization than those who don't. As an aside, some randomized counter mode variants have been defined; it's included in the CTR submission to NIST. We probably don't want to mandate automated key management for these variants. Another related point that's worth making is that key management protocols can and should coordinate other information besides keys. Some systems rely on the uniqueness of device identifiers or other nonce values that are provided as inputs to cryptographic systems. An example of this is when a single counter mode key is used by multiple senders, in which case each sender must include a distinct value in the counter to avoid keystream re-use. It is reasonable to mandate that these per-device values be passed out by an authenticated key management protocol, unless there is a trusted central system that administers them. In multicast or multi-unicast situations, there may be a need to communicate the current value of the anti-replay information. Another kind of information that needs to be synchronized is the crypto parameters. If multiple cipher types can be used, there ought to be an automated check that both sides are in synchronization. I believe that 3DES can be broken if an adversary has access to a DES decryption oracle that uses the initial part of the 3DES key. I think that it might be useful to take a bottom-up approach to some of these requirements. You could require that crypto implementations use automated key management if it is needed meet the requirements of the crypto mechanisms that it uses. For example: * A crypto implementation MUST track the amount of data protected by each key that it uses and prevent its overuse. DES and 3DES keys can be used for no more than 2^32 invocations of the cipher, while AES keys (for all key sizes) can be used for no more than 2^64 invocations of the cipher. * A crypto implementation MUST ensure that initialization vectors are generated appropriately. Ciphers using implicit IVs MUST ensure that the values of the inputs used to compute those IVs are distinct. < ... add more imperatives here ... > * A crypto implementation MUST ensure that all of the above conditions are met. If an automated key management system is needed in order to meet these goals, then such a system MUST be implemented. And now for a bunch of random comments. The draft mandates key management if "a central party will have to manage n^2 static keys". I think that I agree with this requirement, though it might be good to make it more precise. Some might read it to mean that manual keying is acceptable if each of the n parties is responsible for establishing a shared key with its n-1 peers. Was this what you'd intended? I'm not sure that I understand the requirement about when "long-lived session keys are used by more than two parties." Certainly a cryptographic system shouldn't overuse a key. I'm not sure what the restriction to more than two parties means. Do you have in mind the multiple-sender case? A minor point: it might be considered reasonable to allow manual keys for debugging purposes. It would be good to include some disclaimer or discussion about this special case. Yet another minor point: I like the use of the Denning-Sacco and Lowe breaks of the Needham-Schroeder public key protocol as a motivating example for not designing your own KMP. I certainly find it motivating! It might be good to add a references to those breaks. David From housley@vigilsec.com Fri Apr 18 11:14:14 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h3IFEE41018703 for ; Fri, 18 Apr 2003 11:14:14 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) h3IFEC9d014886 for ; Fri, 18 Apr 2003 11:14:13 -0400 (EDT) Received: (qmail 11188 invoked by uid 0); 18 Apr 2003 15:06:54 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.186.161) by woodstock.binhost.com with SMTP; 18 Apr 2003 15:06:54 -0000 Message-Id: <5.2.0.9.2.20030417174438.02d31da0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 17 Apr 2003 17:53:57 -0400 To: "David A. Mcgrew" From: Russ Housley Subject: Re: [saag] Comments on draft-bellovin-mandate-keymgmt-00.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 18 Apr 2003 15:14:14 -0000 David: >I'm glad that the you're writing up this kind of guideline. Publishing >documents outlining policy will help coordinate security work across the IETF. >The draft looks pretty good, though I have a couple of questions and a >bunch of >detailed comments. > >I like that the draft discusses "automated key management" rather than a key >management protocol. This inclusiveness allows systems that don't use >explicit >key management messages, but that derive session keys from other implicit >information, to meet the security requirements. This is surely the right >way to >go. However, this fact makes me think that "limited available bandwidth >or very >high round-trip times" (mentioned at the end of Section 2) isn't a valid >motivation for not using automated key management. > >The injunction that automated key management must be used if "a stream cipher >such as RC4 or AES counter mode [AESMODE] is used" is certainly needed. But >this injunction ought to also be applied to all cipher modes that use implicit >IVs rather than explicit random IVs, at least if the re-use of a key would >lead >to the re-use of IV values. This is the case if the implicit IV generation >method defined in Appendix C of [AESMODE] is used. The fundamental >cryptographic issue here is that ciphers that implement randomized encryption >(e.g. use an random IV) require less synchronization than those who don't. As >an aside, some randomized counter mode variants have been defined; it's >included >in the CTR submission to NIST. We probably don't want to mandate >automated key >management for these variants. I have not had a chance to look at these variants. Do they guarantee that there will not be a collision between the counters, or do they use a large random value and live with the slim possibility of collision? >Another related point that's worth making is that key management protocols can >and should coordinate other information besides keys. Some systems rely >on the >uniqueness of device identifiers or other nonce values that are provided as >inputs to cryptographic systems. An example of this is when a single counter >mode key is used by multiple senders, in which case each sender must include a >distinct value in the counter to avoid keystream re-use. It is reasonable to >mandate that these per-device values be passed out by an authenticated key >management protocol, unless there is a trusted central system that administers >them. In multicast or multi-unicast situations, there may be a need to >communicate the current value of the anti-replay information. Another >kind of >information that needs to be synchronized is the crypto parameters. If >multiple >cipher types can be used, there ought to be an automated check that both sides >are in synchronization. I believe that 3DES can be broken if an adversary has >access to a DES decryption oracle that uses the initial part of the 3DES key. > >I think that it might be useful to take a bottom-up approach to some of these >requirements. You could require that crypto implementations use automated key >management if it is needed meet the requirements of the crypto mechanisms that >it uses. For example: > > * A crypto implementation MUST track the amount of data protected by > each key >that it uses and prevent its overuse. DES and 3DES keys can be used for >no more >than 2^32 invocations of the cipher, while AES keys (for all key sizes) can be >used for no more than 2^64 invocations of the cipher. s/MUST/SHOULD/ I can think of many cases where this is not done because the likelihood of exceeding these limits is so slim. > * A crypto implementation MUST ensure that initialization vectors are >generated appropriately. Ciphers using implicit IVs MUST ensure that the >values >of the inputs used to compute those IVs are distinct. I do not see this as key management. Rather, I see this as properly using a particular algorithm in a particular mode. >< ... add more imperatives here ... > > > * A crypto implementation MUST ensure that all of the above conditions are >met. If an automated key management system is needed in order to meet these >goals, then such a system MUST be implemented. > > >And now for a bunch of random comments. The draft mandates key management >if "a >central party will have to manage n^2 static keys". I think that I agree with >this requirement, though it might be good to make it more precise. Some might >read it to mean that manual keying is acceptable if each of the n parties is >responsible for establishing a shared key with its n-1 peers. Was this what >you'd intended? > >I'm not sure that I understand the requirement about when "long-lived session >keys are used by more than two parties." Certainly a cryptographic system >shouldn't overuse a key. I'm not sure what the restriction to more than two >parties means. Do you have in mind the multiple-sender case? I think this is about multicast keys. At least that is how I interpreted the discussion. >A minor point: it might be considered reasonable to allow manual keys for >debugging purposes. It would be good to include some disclaimer or discussion >about this special case. > >Yet another minor point: I like the use of the Denning-Sacco and Lowe >breaks of >the Needham-Schroeder public key protocol as a motivating example for not >designing your own KMP. I certainly find it motivating! It might be good to >add a references to those breaks. Russ From mcgrew@cisco.com Mon Apr 21 10:06:17 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h3LE6G41019768 for ; Mon, 21 Apr 2003 10:06:16 -0400 (EDT) Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) h3LE4rnV009405 for ; Mon, 21 Apr 2003 10:04:53 -0400 (EDT) Received: from MCGREW-W2K.cisco.com (stealth-10-34-251-100.cisco.com [10.34.251.100]) by sj-core-1.cisco.com (8.12.6/8.12.6) with SMTP id h3LE4mmj018971; Mon, 21 Apr 2003 07:04:49 -0700 (PDT) Message-Id: <4.3.2.7.2.20030421062605.03822b10@mira-sjcm-1.cisco.com> X-Sender: mcgrew@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 Apr 2003 07:04:47 -0700 To: Russ Housley From: David Mcgrew Subject: Re: [saag] Comments on draft-bellovin-mandate-keymgmt-00.txt In-Reply-To: <5.2.0.9.2.20030417174438.02d31da0@mail.binhost.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 21 Apr 2003 14:06:17 -0000 Russ, At 05:53 PM 4/17/2003 -0400, Russ Housley wrote: >David: > >>I'm glad that the you're writing up this kind of guideline. Publishing >>documents outlining policy will help coordinate security work across the >>IETF. >>The draft looks pretty good, though I have a couple of questions and a >>bunch of >>detailed comments. >> >>I like that the draft discusses "automated key management" rather than a key >>management protocol. This inclusiveness allows systems that don't use >>explicit >>key management messages, but that derive session keys from other implicit >>information, to meet the security requirements. This is surely the right >>way to >>go. However, this fact makes me think that "limited available bandwidth >>or very >>high round-trip times" (mentioned at the end of Section 2) isn't a valid >>motivation for not using automated key management. >> >>The injunction that automated key management must be used if "a stream cipher >>such as RC4 or AES counter mode [AESMODE] is used" is certainly needed. But >>this injunction ought to also be applied to all cipher modes that use >>implicit >>IVs rather than explicit random IVs, at least if the re-use of a key >>would lead >>to the re-use of IV values. This is the case if the implicit IV generation >>method defined in Appendix C of [AESMODE] is used. The fundamental >>cryptographic issue here is that ciphers that implement randomized encryption >>(e.g. use an random IV) require less synchronization than those who >>don't. As >>an aside, some randomized counter mode variants have been defined; it's >>included >>in the CTR submission to NIST. We probably don't want to mandate >>automated key >>management for these variants. > >I have not had a chance to look at these variants. Do they guarantee that >there will not be a collision between the counters, or do they use a large >random value and live with the slim possibility of collision? they use a 128-bit random IV and trust that collisions are sufficiently unlikely. As an aside, the new EAX mode does this in the internal counter mode that it uses for encryption. >>Another related point that's worth making is that key management >>protocols can >>and should coordinate other information besides keys. Some systems rely >>on the >>uniqueness of device identifiers or other nonce values that are provided as >>inputs to cryptographic systems. An example of this is when a single counter >>mode key is used by multiple senders, in which case each sender must >>include a >>distinct value in the counter to avoid keystream re-use. It is reasonable to >>mandate that these per-device values be passed out by an authenticated key >>management protocol, unless there is a trusted central system that >>administers >>them. In multicast or multi-unicast situations, there may be a need to >>communicate the current value of the anti-replay information. Another >>kind of >>information that needs to be synchronized is the crypto parameters. If >>multiple >>cipher types can be used, there ought to be an automated check that both >>sides >>are in synchronization. I believe that 3DES can be broken if an >>adversary has >>access to a DES decryption oracle that uses the initial part of the 3DES key. >> >>I think that it might be useful to take a bottom-up approach to some of these >>requirements. You could require that crypto implementations use >>automated key >>management if it is needed meet the requirements of the crypto mechanisms >>that >>it uses. For example: >> >> * A crypto implementation MUST track the amount of data protected by >> each key >>that it uses and prevent its overuse. DES and 3DES keys can be used for >>no more >>than 2^32 invocations of the cipher, while AES keys (for all key sizes) >>can be >>used for no more than 2^64 invocations of the cipher. > >s/MUST/SHOULD/ > >I can think of many cases where this is not done because the likelihood of >exceeding these limits is so slim. Agreed, there are cases where the limits aren't approached. This text would have been better: * A crypto implementation MUST prevent the overuse of each key. An implementation which can be caused to exceed the usage limit MUST track key usage and ensure that usage limits are respected. >> * A crypto implementation MUST ensure that initialization vectors are >>generated appropriately. Ciphers using implicit IVs MUST ensure that the >>values >>of the inputs used to compute those IVs are distinct. > >I do not see this as key management. Rather, I see this as properly using >a particular algorithm in a particular mode. Right, it's a low-level requirement. What I'm proposing is that key management be required whenever it is needed in order to meet low-level requirements. More inline: >>< ... add more imperatives here ... > >> >> * A crypto implementation MUST ensure that all of the above conditions are >>met. If an automated key management system is needed in order to meet these >>goals, then such a system MUST be implemented. ...this is the catch-all requirement. My thinking here is that it might be easier to work from the bottom up than the top down. There are lots of cases to consider in the modes of operation analysis, for example, especially when we consider the possibility that a single key could be used by multiple senders. I think that it would be easier to make a blanket statement than to write specific requirements for all of the different cases separately in the key management draft. What do you think? David >>And now for a bunch of random comments. The draft mandates key >>management if "a >>central party will have to manage n^2 static keys". I think that I agree >>with >>this requirement, though it might be good to make it more precise. Some >>might >>read it to mean that manual keying is acceptable if each of the n parties is >>responsible for establishing a shared key with its n-1 peers. Was this what >>you'd intended? >> >>I'm not sure that I understand the requirement about when "long-lived session >>keys are used by more than two parties." Certainly a cryptographic system >>shouldn't overuse a key. I'm not sure what the restriction to more than two >>parties means. Do you have in mind the multiple-sender case? > >I think this is about multicast keys. At least that is how I interpreted >the discussion. > >>A minor point: it might be considered reasonable to allow manual keys for >>debugging purposes. It would be good to include some disclaimer or >>discussion >>about this special case. >> >>Yet another minor point: I like the use of the Denning-Sacco and Lowe >>breaks of >>the Needham-Schroeder public key protocol as a motivating example for not >>designing your own KMP. I certainly find it motivating! It might be good to >>add a references to those breaks. > >Russ From jari.arkko@piuha.net Tue Apr 22 05:46:15 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h3M9kF41029165 for ; Tue, 22 Apr 2003 05:46:15 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) h3M9kEnW001080 for ; Tue, 22 Apr 2003 05:46:15 -0400 (EDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 74C556A903; Tue, 22 Apr 2003 12:46:13 +0300 (EEST) Message-ID: <3EA50F22.2000002@piuha.net> Date: Tue, 22 Apr 2003 12:45:06 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bellovin@acm.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: saag@mit.edu Subject: [saag] More comments on draft-bellovin-mandate-keymgmt-00.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 22 Apr 2003 09:46:16 -0000 I have some comments on Steven's key management draft. The comments are embedded in the draft itself at the URL http://www.piuha.net/~jarkko/publications/ipsec/mandate_keymgmt_review.txt --Jari From mcgrew@cisco.com Thu Apr 24 14:26:22 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h3OIQM41028592 for ; Thu, 24 Apr 2003 14:26:22 -0400 (EDT) Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) h3OIQL0G024971 for ; Thu, 24 Apr 2003 14:26:21 -0400 (EDT) Received: from MCGREW-W2K.cisco.com (stealth-10-34-251-100.cisco.com [10.34.251.100]) by sj-core-1.cisco.com (8.12.6/8.12.6) with SMTP id h3OIQD09008096; Thu, 24 Apr 2003 11:26:14 -0700 (PDT) Message-Id: <4.3.2.7.2.20030424111405.03044d48@mira-sjcm-1.cisco.com> X-Sender: mcgrew@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Apr 2003 11:26:12 -0700 To: bellovin@acm.org From: David Mcgrew Subject: Re: [saag] Comments on draft-bellovin-mandate-keymgmt-00.txt In-Reply-To: <5.2.0.9.2.20030417174438.02d31da0@mail.binhost.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 24 Apr 2003 18:26:22 -0000 Steve, I ran across the references that I'd mentioned in my earlier mail and realized that I'd misspoke. So I figured I'd correct myself and provide the references, thus making a virtue out of a slip-up. I wrote: >>Yet another minor point: I like the use of the Denning-Sacco and Lowe >>breaks of >>the Needham-Schroeder public key protocol as a motivating example for not >>designing your own KMP. I certainly find it motivating! It might be good to >>add a references to those breaks. It turns out that the first break was on the secret-key version of the NS protocol, while the second was on the public-key version. Not a big deal. The references are: R. Needham and M. Schroeder. Using encryption for authentication in large networks of computers. Communications of the ACM, 21(12), December 1978. D. Denning and G. Sacco. Timestamps in key distributed protocols. Communication of the ACM, 24(8):533--535, 1981. Gavin Lowe. An attack on the Needham-Schroeder public key authentication protocol. Information Processing Letters, 56(3):131--136, November 1995. I got these refs from the Security Protocols Open Repositoty at http://www.lsv.ens-cachan.fr/spore/, which might be worth mentioning as well. David From stephen.farrell@baltimore.ie Thu Apr 24 10:16:13 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h3OEG941026397 for ; Thu, 24 Apr 2003 10:16:13 -0400 (EDT) Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) h3OEG5JN007808 for ; Thu, 24 Apr 2003 10:16:08 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id h3OEAF232765 for ; Thu, 24 Apr 2003 15:10:15 +0100 Received: from ([10.153.25.53]) by Baltimore-FW1; Thu, 24 Apr 2003 15:11:11 +0100 (BST) Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com for ; Thu, 24 Apr 2003 15:15:28 +0100 Received: from ([10.153.25.10]) by Baltimore-FW1; Thu, 24 Apr 2003 15:11:08 +0100 (BST) Received: from baltimore.ie (wks218-25.ie.baltimore.com [10.153.25.218]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA26986; Thu, 24 Apr 2003 15:16:00 +0100 Message-ID: <3EA7F189.FF214073@baltimore.ie> Date: Thu, 24 Apr 2003 15:15:37 +0100 From: Stephen Farrell Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Shivaram Mysore , xme Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 27 Apr 2003 22:21:20 -0400 Subject: [saag] XML Key Management Specification Last Call - need review/feedback X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: stephen.farrell@baltimore.ie List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 24 Apr 2003 14:16:13 -0000 Dear IETF security folks, Firstly, apologies if (or when) you get more than one copy of this. On behalf of the W3C XML Key Managment Service WG [XKMS-WG], we are pleased to announce the publication of the "XML Key Management Specification" Last Call Working Draft. This is one of the deliverables of the WG. The document address is: http://www.w3.org/TR/2003/WD-xkms2-20030418/Overview.html http://www.w3.org/TR/2003/WD-xkms2-bindings-20030418/Overview.html The Last Call review period will end on 23 May, 2003. Please send review comments by that date to the editor - pbaker@verisign.com and cc: www-xkms@w3.org Thanks, Stephen. [XKMS-WG] http://www.w3.org/2001/XKMS -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From uri@bell-labs.com Mon Apr 28 14:49:08 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h3SIn741012150 for ; Mon, 28 Apr 2003 14:49:07 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])h3SIn781000016 for ; Mon, 28 Apr 2003 14:49:07 -0400 (EDT) Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) ESMTP id h3SIn5r01644 for ; Mon, 28 Apr 2003 14:49:05 -0400 (EDT) Received: by nwmail.wh.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h3SIn5q28551; Mon, 28 Apr 2003 14:49:05 -0400 (EDT) Received: from bell-labs.com by nwmail.wh.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h3SIn1t28528; Mon, 28 Apr 2003 14:49:01 -0400 (EDT) Message-ID: <3EAD779A.7030900@bell-labs.com> Date: Mon, 28 Apr 2003 14:48:58 -0400 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: jari.arkko@piuha.net Original-CC: saag@mit.edu Subject: Re: [saag] More comments on draft-bellovin-mandate-keymgmt-00.txt References: <3EA50F22.2000002@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 28 Apr 2003 18:49:08 -0000 Jari Arkko wrote: > I have some comments on Steven's key management draft. The comments > are embedded in the draft itself at the URL > > http://www.piuha.net/~jarkko/publications/ipsec/mandate_keymgmt_review.txt A quick reply to one of the comments: > JARI: What are the key change provisions in automatic key management? > Obviously, its easy to change session keys. But do we need > mechanisms for dealing with e.g. the change of an IKE preshared > secret? If yes, will the above mechanism be applicable? Is this > documented somewhere? No, the "automatic key management" in fact is just a session key agreement mechanism. Its purpose is to protect the "long-term" keys from vulterabilities they incur when used to protect one session after another. Now they will be used only to sign the session key agreement exchange - much safer. How these "long-term" keys get there in the first place is (and should be) beyond the scope of this document (IMHO). From jari.arkko@piuha.net Mon Apr 28 17:08:53 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h3SL8q41013474 for ; Mon, 28 Apr 2003 17:08:53 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) h3SL8q0N021403 for ; Mon, 28 Apr 2003 17:08:52 -0400 (EDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 74D606A901; Tue, 29 Apr 2003 00:08:50 +0300 (EEST) Message-ID: <3EAD9817.2030708@piuha.net> Date: Tue, 29 Apr 2003 00:07:35 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Uri Blumenthal Subject: Re: [saag] More comments on draft-bellovin-mandate-keymgmt-00.txt References: <3EA50F22.2000002@piuha.net> <3EAD779A.7030900@bell-labs.com> In-Reply-To: <3EAD779A.7030900@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 28 Apr 2003 21:08:53 -0000 Uri Blumenthal wrote: >> JARI: What are the key change provisions in automatic key management? >> Obviously, its easy to change session keys. But do we need >> mechanisms for dealing with e.g. the change of an IKE preshared >> secret? If yes, will the above mechanism be applicable? Is this >> documented somewhere? > > No, the "automatic key management" in fact is just a session key > agreement mechanism. Its purpose is to protect the "long-term" > keys from vulterabilities they incur when used to protect one > session after another. Now they will be used only to sign > the session key agreement exchange - much safer. How > these "long-term" keys get there in the first place > is (and should be) beyond the scope of this document (IMHO). I know the long-term secrets are protected from the usual "wear out" that keys for actual payload crypto get. But there might be other reasons to change secrets than that. Say, it might be a good idea to change your secrets once a year in any case. And when you do, it might not be possible to do an instantaneous change for both parties. So there might be a need to have two secrets at a time, I wasn't sure if IKE (for instance) could do that. Anyway, I agree that this is perhaps getting out of scope of the original discussion. My point was that there might be similar key change issues in automatic key management protocols as well, even if they are needed less frequently... --Jari From uri@bell-labs.com Mon Apr 28 18:05:11 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h3SM5B41014075 for ; Mon, 28 Apr 2003 18:05:11 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163])h3SM560N009076 for ; Mon, 28 Apr 2003 18:05:06 -0400 (EDT) Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) ESMTP id h3SM53Q13987 for ; Mon, 28 Apr 2003 18:05:03 -0400 (EDT) Received: by nwmail.wh.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h3SM52922762; Mon, 28 Apr 2003 18:05:03 -0400 (EDT) Received: from bell-labs.com by nwmail.wh.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h3SM50t22737; Mon, 28 Apr 2003 18:05:00 -0400 (EDT) Message-ID: <3EADA588.6090808@bell-labs.com> Date: Mon, 28 Apr 2003 18:04:56 -0400 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: jari.arkko@piuha.net Original-CC: saag@mit.edu Subject: Re: [saag] More comments on draft-bellovin-mandate-keymgmt-00.txt References: <3EA50F22.2000002@piuha.net> <3EAD779A.7030900@bell-labs.com> <3EAD9817.2030708@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 28 Apr 2003 22:05:11 -0000 Jari Arkko wrote: >>> JARI: What are the key change provisions in automatic key management? >> >> No, the "automatic key management" in fact is just a session key >> agreement mechanism. > > I know the long-term secrets are protected from the usual > "wear out" that keys for actual payload crypto get. But > there might be other reasons to change secrets than that. Of course. But it is not what this simple mechanism is for. Its main purpose IMHO is merely eliminate the abominable case of manually keyed sessions. That it does. IKE it is not. > Anyway, I agree that this is perhaps getting out of scope > of the original discussion. My point was that there > might be similar key change issues in automatic key > management protocols as well, even if they are needed > less frequently... And just one more small feature, and yet another tiny option... IKEv2 is the answer to those. From info@caitr.org Mon May 5 12:46:57 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h45Gkvw5015236 for ; Mon, 5 May 2003 12:46:57 -0400 (EDT) Received: from web41806.mail.yahoo.com (web41806.mail.yahoo.com [66.218.93.140])h45GkFZx029024 for ; Mon, 5 May 2003 12:46:16 -0400 (EDT) Message-ID: <20030505164615.39430.qmail@web41806.mail.yahoo.com> Received: from [65.213.193.49] by web41806.mail.yahoo.com via HTTP; Mon, 05 May 2003 09:46:15 PDT Date: Mon, 5 May 2003 09:46:15 -0700 (PDT) From: CAITR To: saag@mit.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-308588202-1052153175=:39066" Subject: [saag] Internetworking 2003: Call for Participation X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: info@caitr.org List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 05 May 2003 16:46:58 -0000 --0-308588202-1052153175=:39066 Content-Type: text/plain; charset=us-ascii Internetworking 2003 International Conference Hilton San Jose & Towers Hotel, California June 22-June 24, 2003 http://www.caitr.org/internetworking03/index.htm You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials.Registration for the conference is underway. Please visit http://www.caitr.org/internetworking03/registration.htm and follow instructions for registration. The early registration discounts are extremely attractive and are valid till June 1, 2003.Important Dates: --------------------- - Early Registration Rates Cut-Off Date: Sept 30 - Tutorials: Oct 27, 1:00-6:00 pm - Conference sessions: October 28-29 8:30am-6:00pmProgram: ------------- (visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details)Sunday June 22 Tutorial-1: MPLS VPNs Tutorial-2: IPv6 Tutorial-3: Mobile Wireless Internet Architecture and Protocols Tutorial-4: Voice over Packet Monday June 23 Welcome and Keynote Session: Network Technology Trends - Forwarding Element and Control Separation - Evolution of Inter-Domain Routing - Network Processing Building Blocks: Enabling the Routers of the Future Session: Network Architecture - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6 - A new routing architecture: Atomised Routing - Internetworking MPLS Layer 2 Transport with an IP Services Network Session: Storage Area Networks - Storage as a Network Node - Object-Based Storage - Design, Implementation, and Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP - SANs Considerations Session: Mobile & Wireless Networks - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6 - Challenges and Roadmap of UMTS Network Deployment - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS - Mobile Authentication and QoS - Mobile Handoff Technologies Tuesday June 24 Session: Inter-Domain Routing - Optimizing Route Convergence - Traceroute and BGP AS Path Incongruities - Domain Constrained Multicast: A New Approach for IP Multicast Routing Session: Applications & Services - Securing the Web with Next Generation Encryption Technologies - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21 - A novel EAC semantic for the RTSP protocol - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet Session: Network Management & Planning - Pseudowire OAM: A Mandatory Yet Often Overlooked Feature - A Multicommodity Flow Formulation for the MPLS Layout Design: Reduced Complexity Layout and Minimum Relayout Probems - Design Of Fast Fault Restoration System For WDM Networks - Cross-domain multimedia service provisioning, the EVOLUTE solution Session: QoS Based Routing - QoS Routing in Networks with Non-Deterministic Information - Active Dynamic Routing - QoS routing for Differentiated Services: simulations and prototype experiments - Probabilistic routing for QoS improvement in GPS networks - Fluid flow network modeling for hop-by-hop feedback control design and analysis We look forward to seeing you at the Conference. Regards, Conference Technical Co-chairs: - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Marc Lobelle, UCL University, Belgium - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Dr. Tony Przygienda, Xebeo - Ran Canetti, IBM --0-308588202-1052153175=:39066 Content-Type: text/html; charset=us-ascii
     Internetworking 2003 International Conference
     Hilton San Jose & Towers Hotel, California
              June 22-June 24, 2003
    http://www.caitr.org/internetworking03/index.htm
  
You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials.
Registration for the conference is underway. Please visit http://www.caitr.org/internetworking03/registration.htm and follow instructions for registration. The early registration discounts are extremely attractive and are valid till June 1, 2003.
Important Dates:
---------------------
- Early Registration Rates Cut-Off Date: Sept 30
- Tutorials: Oct 27, 1:00-6:00 pm
- Conference sessions: October 28-29 8:30am-6:00pm
Program:
-------------
(visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details)
Sunday June 22
    Tutorial-1: MPLS VPNs 
    Tutorial-2: IPv6 
    Tutorial-3: Mobile Wireless Internet Architecture and Protocols
    Tutorial-4: Voice over Packet 
Monday June 23
    Welcome and Keynote 
    Session: Network Technology Trends
      - Forwarding Element and Control Separation
      - Evolution of Inter-Domain Routing
      - Network Processing Building Blocks: Enabling the Routers of the Future
    Session: Network Architecture
      - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6
      - A new routing architecture: Atomised Routing
      - Internetworking MPLS Layer 2 Transport with an IP Services Network
    Session: Storage Area Networks
      - Storage as a Network Node
      - Object-Based Storage
      - Design, Implementation, and ! Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP
      - SANs Considerations
 
    Session: Mobile & Wireless Networks
      - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6
      - Challenges and Roadmap of UMTS Network Deployment
      - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS 
      - Mobile Authentication and QoS 
      - Mobile Handoff Technologies 
Tuesday June 24
    Session: Inter-Domain Routing
      - Optimizing Route Convergence
      - Traceroute and BGP AS Path Incongruities 
      - Domain Constrained Multicast: A New Approach for IP Multicast Routing
 
    Session: Applications & Services
     -  Securing the Web with Next Generation Encryption Technologies
     - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21
     - A novel EAC semantic for the RTSP protocol
     - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet
 
    Session: Network Management & Planning
     -  Pseudowire OAM: A Mandatory Ye! t Often Overlooked Feature 
     - A Multicommodity Flow Formulation for the MPLS Layout Design: Reduced Complexity Layout and Minimum Relayout Probems
     - Design Of Fast Fault Restoration System For WDM Networks
     - Cross-domain multimedia service provisioning, the EVOLUTE solution
 
    Session: QoS Based Routing
     - QoS Routing in Networks with Non-Deterministic Information
     - Active Dynamic Routing
     - QoS routing for Differentiated Services: simulations and prototype experiments
     - Probabilistic routing for QoS improvement in GPS networks
     - Fluid flow network modeling for hop-by-hop feedback control design and analysis
 
We look forward to seeing you at the Conference.
Regards,
 Conference Technical Co-chai! rs:
 - Dr. Maurice Gagnaire, ENST, France
 - Daniel Awduche
 Technical Program Committee of the Internetworking 2003 Conference:
 - Roberto Sabella, Erisson
 - Dr. Moshe Zukerman, Univ. of Melbourne
 - Nada Golmie, NIST
 - Dr. Guy Pujolle, LIP6, France
 - Dr. Samir Tohme, ENST, France
 - Stefano Trumpy, Italian National Research Council
 - Dr. Ibrahim Habib, City Univ. of NY
 - Dr. Marc Lobelle, UCL University, Belgium
 - Dr. Parviz Yegani, Cisco Systems
 - Dr. G.S. Kuo
 - Dr. Abbas Jamalipour, Univ. of Sydney
 - Dr. Hussein Mouftah, Univ. of Ottawa
 - James Kempf
 - Elizabeth Rodriguez
 - Dr. Ferit Yegenoglu, Isocore
 - Dr. Ali Zadeh, George Mason University
 - Dr. Tony Przygienda, Xebeo
 - Ran Canetti, IBM
--0-308588202-1052153175=:39066-- From pekka.nikander@nomadiclab.com Tue Jun 10 04:21:32 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5A8LVNJ004315 for ; Tue, 10 Jun 2003 04:21:32 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) h5A8LU9k000124 for ; Tue, 10 Jun 2003 04:21:31 -0400 (EDT) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id C4D011C; Tue, 10 Jun 2003 11:31:19 +0300 (EEST) Message-ID: <3EE59545.3040106@nomadiclab.com> Date: Tue, 10 Jun 2003 11:22:29 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: "Steven M. Bellovin" cc: Russ Housley Subject: [saag] Time to reconsider the role of IPsec AH? X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 10 Jun 2003 08:21:32 -0000 Folks, Based on our experiences with IPsec in Mobile IP, SEND, and some other working groups, I am seriously starting to think that it might be a good time to reconsider to role of AH in the Internet architecture. For example, in the SEND (Securing Neighbor Discovery) WG, which I am co-chairing with James Kempf, we have been attempting to use IPsec AH to secure IPv6 Neighbor Discovery messages in a public access network setting. The approach is based on public keys, as suggested by Steven Bellovin in his presentation at the SEND BoF in Yokohama. This work has certainly progressed, but the road has been fairly bumby due to the current practice on how IPsec has been implemented in most IP stacks. In general, it looks like the IPsec working group has mostly concentrated on perfecting ESP and IKE/IKEv2, and mostly for VPN use. The goal seem to have been securing *applications* end-to-end, and making IPsec as transparent to the applications as possible. The needs towards IPsec in Mobile IP, SEND, and other IP layer control protocols seem to be very different. In these protocols, there is no "application" in the traditional sense. Instead, the protocols create state at the IP layer, thereby affecting the overall operations of all applications. Furthermore, if an attacker can illegitly create such state, the effects can be devastating to the whole Internet, resulting in hijacked connections, untraceable denial-of-service attacks, mysteriously disconnected sessions, black holes, or other large scale malfunctions or security breaches. In some sense, the IP layer control protocols and their security needs resemble routing protocols. However, they are very different from the trust model point of view. Routing protocols usually exchange routing information between peering routers that have some level of trust. On the other hand, the IP layer control protocols often need to exchange IP layer state related information between peers that have no or only minimal trust. For example, in Mobile IP route optimization the mobile node and the corresponding node may have never communicated with each other before, and they may have no shared trust-root. Similarily, nodes running in an ad hoc network may have never met other nodes that they need to perform Neighbor Discovery with. Now, in the IPsec working group there seems to be a fairly large faction of people that want to kill AH. To them, AH seems like a completely useless feature. If I took a very limited VPN point-of-view, I most probably would agree with them. One can even argue that AH, in general, is not suitable for protecting end-to-end application level traffic, since ESP integrity protection makes it better and without less problems with IP headers being modified on the way. As I argued above, the situation is different with IP level control protocols. There the extension headers, and often the actual IP header, do carry information whose integrity is essential. Furthermore, the result of the integrity check is not necessarily a usual black/white result, but it may be necessary to pass additional information to the upper layer protocol, i.e., ICMP, Mobile IP, etc. The same applies to the packets sent out: it is sometimes necessary that the upper layer protocol is able to instruct the IP layer how exactly to protect the packet. The current IPsec policy mechanisms are too inflexible to properly fulfil these needs. Thus, I would propose that we should start to seriously reconsider the role of AH. In fact, I propose that we should effectively re-charter AH to be a security protocol for IP layer control functions only, and start working an in-stack API that AH would provide to the IP layer control protocols. I think that if such an idea sounds good, we should have a new working group for that. The attitude in the IPsec working group seems to be either negative or oblivious towards AH. Thus, it might make sense to move all AH related work the new working group, if one is formed. I would be happy to try to run a pre-BOF at Vienna if there is any support for this idea. --Pekka Nikander From rja@extremenetworks.com Tue Jun 10 09:55:22 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5ADtMNJ007294 for ; Tue, 10 Jun 2003 09:55:22 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) h5ADtJRh004466 for ; Tue, 10 Jun 2003 09:55:19 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 1773767114; Tue, 10 Jun 2003 10:25:42 -0400 (EDT) Date: Tue, 10 Jun 2003 09:55:13 -0400 Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Pekka Nikander From: RJ Atkinson In-Reply-To: <3EE59545.3040106@nomadiclab.com> Message-Id: <28C99EBE-9B4B-11D7-9D51-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 10 Jun 2003 13:55:23 -0000 Pekka, Thanks for your note. A very long standing problem with the IPsec WG membership is that it ended up (circa 1997) self-selecting for "VPN product vendors", whereas it started out with a much more general goal. The original design intent for both AH and ESP was to provide end-to-end security for co-operating hosts. Because it was trivial (both in spec and in running code) to add support for a tunnel-mode that would enable VPN applications, this was done quite early on (well before RFC-1825 -- RFC-1827 were published). It is correct that the current VPN-oriented membership of the IPsec WG is pretty openly hostile to AH -- mainly because AH is not a VPN-oriented protocol. There have also been some (incorrect) gripes that AH cannot be performed at high-speed because of its header design. However I know of ASICs that can perform AH (with key-agility for many streams concurrently) at multiple Gbps, so that claim has proved ill-founded. It would seem quite reasonable to me to make clear that a VPN product need not implement AH as part of its VPN service offering [1]. In the mid-90s there was still an IETF concept of a "mandatory standard", whereas now all IETF standards are considered "elective" (as near as I can tell from the sidelines). A number of applications (e.g. routing protocols, such as PIM and OSPFv3; IGMP, and ICMP) currently benefit from use of AH. In practice, the US Government (and some other governments) have been known to deny general export of authentication-only-ESP. All export applications for AH have been granted. So in practical terms, an authentication approach based on AH is much more likely to be globally deployable than one based on authentication-only-ESP. Beyond that, AH provides different security properties than ESP.[2] However, I would not want to lose the ability to protect my user traffic with AH-only or with a combined AH+ESP if I wished to do so (and my end-system supported that, which mine currently does). As Mike StJohns can confirm, NRL demonstrated the use of AH to protect IPv6 ICMP, including ND, in August 1995. The demo included secure bootstrapping on a LAN. AH is particularly well-suited to that application, not coincidentally since ESP/AH were originally undertaken within the then-SIP (later IPng) WG. I think it might well make sense to move work on AH outside of the IPsec WG. For that matter, I have for many years advocated that key management (e.g. IKE, ISAKMP, and successors) be undertaken in a separate WG; I still believe that would be helpful. Ran Atkinson rja@extremenetworks.com [1] One might, however, consider that a VPN product that implemented a control protocol (e.g. ICMPv6, IPv6 ND, routing protocol) that used AH for authentication would be required to support AH for those particular applications. [2] Some consider those differences important, others do not. I myself am among those who consider the differences important. From rja@extremenetworks.com Tue Jun 10 11:19:23 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5AFJNNJ008366 for ; Tue, 10 Jun 2003 11:19:23 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) h5AFJNBZ000908 for ; Tue, 10 Jun 2003 11:19:23 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 80E7B6711F for ; Tue, 10 Jun 2003 11:49:49 -0400 (EDT) Date: Tue, 10 Jun 2003 11:19:21 -0400 Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: RJ Atkinson To: saag@mit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <28C99EBE-9B4B-11D7-9D51-00039357A82A@extremenetworks.com> Message-Id: X-Mailer: Apple Mail (2.552) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 10 Jun 2003 15:19:24 -0000 On Tuesday, Jun 10, 2003, at 09:55 America/Montreal, RJ Atkinson wrote: > A very long standing problem with the IPsec WG membership > is that it ended up (circa 1997) self-selecting for "VPN product > vendors", whereas it started out with a much more general goal. That text above is poorly phrased. The self-selection started whilst I was IPsec Co-Chair, so it should have said (circa 1996-1997) instead of the actual text above. And I don't know that the self-selection of the IPsec WG membership was an avoidable outcome given the actual circumstances on the ground in that era. So I never intended to blame either my co-chair or the successor co-chairs in the above (quoted) comment. I apologise if my poor initial wording erroneously led any folks to believe that was the intent of my words. Ran rja@extremenetworks.com From phoffman@imc.org Tue Jun 10 11:47:30 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5AFlTNJ008782 for ; Tue, 10 Jun 2003 11:47:29 -0400 (EDT) Received: from above.proper.com (above.proper.com [208.184.76.39]) h5AFlRd5014766 for ; Tue, 10 Jun 2003 11:47:28 -0400 (EDT) Received: from [165.227.249.150] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5AFlPAG079875 for ; Tue, 10 Jun 2003 08:47:25 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 10 Jun 2003 08:41:23 -0700 To: saag@mit.edu From: Paul Hoffman / IMC Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 10 Jun 2003 15:47:30 -0000 On Tuesday, Jun 10, 2003, at 09:55 America/Montreal, RJ Atkinson wrote: > A very long standing problem with the IPsec WG membership >is that it ended up (circa 1997) self-selecting for "VPN product >vendors", whereas it started out with a much more general goal. One can argue that having participation from lots of vendors who are actually deploying the security protocols under discussion in the WG is a good thing. There doesn't appear to have been any stifling of the use of IPsec by non-VPN applications, just not much WG support for it. I may have missed something. If there is a need for changes to AH or ESP for some host-to-host models, they should certainly be made. Given that the IPsec WG is now very close to shutting down (yes, really!), anyone who felt that an important protocol change couldn't get heard in the WG should start talking to the ADs about how to proceed. --Paul Hoffman, Director --Internet Mail Consortium From moore@cs.utk.edu Tue Jun 10 12:20:43 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5AGKgNJ009379 for ; Tue, 10 Jun 2003 12:20:42 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) h5AGKed5027056 for ; Tue, 10 Jun 2003 12:20:41 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h5AGKZk03172; Tue, 10 Jun 2003 12:20:37 -0400 (EDT) Date: Tue, 10 Jun 2003 12:20:35 -0400 From: Keith Moore To: Paul Hoffman / IMC Subject: Re: [saag] Time to reconsider the role of IPsec AH? Message-Id: <20030610122035.4c98ac5b.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: saag@mit.edu cc: moore@cs.utk.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 10 Jun 2003 16:20:43 -0000 > There doesn't appear to have been any stifling of > the use of IPsec by non-VPN applications, just not much WG support > for it. I may have missed something. IPsec is pretty much useless to applications without a) the ability to authenticate applications and users, rather than hosts b) an API that lets apps specify and obtain credentials as long as IPsec doesn't have those, apps will make do with TLS or roll their own. From rja@extremenetworks.com Tue Jun 10 12:56:17 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5AGuHNJ009905 for ; Tue, 10 Jun 2003 12:56:17 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) h5AGuCd5008408 for ; Tue, 10 Jun 2003 12:56:13 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 8D6A76711F; Tue, 10 Jun 2003 13:26:37 -0400 (EDT) Date: Tue, 10 Jun 2003 12:56:08 -0400 Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Paul Hoffman / IMC From: RJ Atkinson In-Reply-To: Message-Id: <6EBFAEAC-9B64-11D7-B33E-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 10 Jun 2003 16:56:18 -0000 On Tuesday, Jun 10, 2003, at 11:41 America/Montreal, Paul Hoffman / IMC wrote: > One can argue that having participation from lots of vendors who are > actually > deploying the security protocols under discussion in the WG is a good > thing. Yes, but having the WG be dominated by VPN box vendors -- somewhat to the exclusion of some host stack implementers -- has not in practice been a good thing with the IPsec WG, IMHO. > There doesn't appear to have been any stifling of the use of IPsec by > non-VPN applications, just not much WG support for it. I may have > missed something. I've seen a fair amount of "stifling of the use of IPsec by non-VPN applications". I'm not alone in that observation. AH hostility from the VPN crowd is merely one obvious example (noted by several folks repeatedly over the past several years). But please, lets focus on moving forward with the discussion that Pekka outlined, rather than continuing this narrow thread. Ran From rja@extremenetworks.com Tue Jun 10 13:08:38 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5AH8cNJ010177 for ; Tue, 10 Jun 2003 13:08:38 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) h5AH8bBZ015005 for ; Tue, 10 Jun 2003 13:08:37 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 6D8966711F; Tue, 10 Jun 2003 13:39:04 -0400 (EDT) Date: Tue, 10 Jun 2003 13:08:35 -0400 Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Keith Moore From: RJ Atkinson In-Reply-To: <20030610122035.4c98ac5b.moore@cs.utk.edu> Message-Id: <2BE48FAC-9B66-11D7-B33E-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 10 Jun 2003 17:08:39 -0000 On Tuesday, Jun 10, 2003, at 12:20 America/Montreal, Keith Moore wrote: >> There doesn't appear to have been any stifling of >> the use of IPsec by non-VPN applications, just not much WG support >> for it. I may have missed something. > > IPsec is pretty much useless to applications without > > a) the ability to authenticate applications and users, rather than > hosts > b) an API that lets apps specify and obtain credentials > > as long as IPsec doesn't have those, apps will make do with TLS or > roll their own. True, though all those capabilities existed *in some form* as far back as 1995 with the NRL IPsec codebase. ESP/AH have *always* had the ability to authenticate applications or users, not just hosts. That's an integral part of the specs. Even the IKE DOI for IPsec has support for a wide range of identities. So I don't think the issues are with the protocol specifications, but rather are with the available host implementations. NRL IPsec had at least 2 APIs in its codebase circa 1995/1996: - PF_KEY for key management traffic, so that key management could be kept outside the kernel. I believe that a later version of this was documented in an RFC. This supported many kinds of identities, including individual users. It was not restricted just to host-granularity identities. - BSD Sockets extensions (and BSD sysctl knobs) to let applications request (and confirm the use of) security services from IPsec. This API supported a range of identities, including individual users. At one time, danmcd had an I-D on some of this, I think, though I'm not sure whether it made it into an RFC. The Sockets options let an application (1) request service, (2) confirm that security was in use for that socket's traffic, and (3) indicate the desired level of security. The BSD sysctl knobs let a privileged user set system-wide default policy settings for whether ESP/AH were always in use even if not specifically requested or were optional to use (i.e. only if the application specifically requested). These capabilities were tested and also were included in one (maybe more) demonstration for ARPA/CSTO during 1995. I believe that Sun probably has some APIs with those capabilities, though I don't have a Sun handy to go check the online manual pages. I'm not sure about other host vendors' implementations. I'm told that MS does not have a key management API -- nor support for manual keying. I've not heard whether MS has an application-enabling API for ESP/AH. Certainly lack of a common, widely deployed, API that is common across multiple vendors is a serious deployment problem for folks writing portable applications. It is entirely tractable to solve if folks are interested in doing so. Ran Atkinson rja@extremenetworks.com From rja@extremenetworks.com Tue Jun 10 14:19:16 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5AIJGNJ011051 for ; Tue, 10 Jun 2003 14:19:16 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) h5AIJApE001671 for ; Tue, 10 Jun 2003 14:19:11 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 65BDD6711F; Tue, 10 Jun 2003 14:49:38 -0400 (EDT) Date: Tue, 10 Jun 2003 14:19:10 -0400 Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: "Christian Huitema" From: RJ Atkinson In-Reply-To: Message-Id: <080A2FAC-9B70-11D7-B33E-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 10 Jun 2003 18:19:17 -0000 On Tuesday, Jun 10, 2003, at 13:36 America/Montreal, Christian Huitema wrote: > I read Pekka's note, which relates to the use of AH in some scenarios, > e.g. SEND. The real issue is, do we need both AH and ESP, or can > something like ESP-NULL be used in lieu of AH and satisfy the AH > scenarios? AH is the right answer for IP-layer authentication, as Pekka noted. Anything using ESP-NULL is actually more complex to implement and less likely to interoperate for things like IPv6 ND or IPv6 ICMP (or IPv4 ICMP/IGMP) authentication. Free running code that interoperates today exists for AH with this application in *BSD and elsewhere. The only thing SEND really needs to address is the key-management. For the BSD stack in my local IPv6 systems, everything is is in place and interoperable today for authenticating IPv6 ND -- except for key management to get the appropriate SA(s) in place. > The question is thus, could ESP-NULL satisfy the SEND requirement? No. Ran rja@extremenetworks.com From pekka.nikander@nomadiclab.com Tue Jun 10 14:26:29 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5AIQTNJ011179 for ; Tue, 10 Jun 2003 14:26:29 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) h5AIQSdJ010231 for ; Tue, 10 Jun 2003 14:26:29 -0400 (EDT) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id ABFA41C; Tue, 10 Jun 2003 21:36:15 +0300 (EEST) Message-ID: <3EE6230C.1060708@nomadiclab.com> Date: Tue, 10 Jun 2003 21:27:24 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [saag] Time to reconsider the role of IPsec AH? References: <2BE48FAC-9B66-11D7-B33E-00039357A82A@extremenetworks.com> In-Reply-To: <2BE48FAC-9B66-11D7-B33E-00039357A82A@extremenetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: saag@mit.edu cc: Keith Moore X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 10 Jun 2003 18:26:30 -0000 Ran, Keith, Keith Moore wrote: >> IPsec is pretty much useless to applications without >> >> a) the ability to authenticate applications and users, rather than hosts >> b) an API that lets apps specify and obtain credentials RJ Atkinson wrote: > True, though all those capabilities existed *in some form* as far back > as 1995 with the NRL IPsec codebase. ... > Certainly lack of a common, widely deployed, API that is common across > multiple vendors is a serious deployment problem for folks writing portable > applications. It is entirely tractable to solve if folks are interested > in doing so. I agree with you both. However, the lack of an application level API was *not* the point of my message. From my point of view, the lack of such an API is an important but *distinct* problem. From my point of view, considering things like ICMPv6, Mobile IPv6, possibly multi6 solutions, and even HIP, there is a need to extend the *role* of IPsec AH. In SEND, we have designed a solution where we are using AH with RSA. However, in order to do so we have been forced to do some serious hoopla to get around limitations in the IPsec policy architecture. If there had been an in-stack API from IPsec to the upper layer protocols (ICMP in this case), the task would have been much easier. Each received, AH protected message could have been annotated with the public key that was used to protect it, allowing the IPv6 neighbor cache to include the public keys in addition to the IP addresses. When sending out, we could have easily sent both AH protected and unprotected messages, allowing easier interoperability between current IPv6 ND and the secure version of ND. Right now it was felt by the WG that assuming such API like facilities within the stack would be too much for many IPsec implementations, and hence we designed around these issues. The result is not the prettiest one, but seems to work well enough. With Mobile IPv6 there was a more-or-less similar story, with the result that MIPv6 Route Optimization does not use IPsec at all. Hence, I really think that we should consider how AH fits into the overall stack structure (architecture, if you will). I think that it could be a great tool for securing lots of ICMP/MIP/... kind of traffic, but currently it is not. The extensions are not necessarily that big; they would be mostly semantic. What I am asking for is to modify IPsec AH so that it can be used for more, and especially in situations where there is clear need to protect the IP layer or extension headers. There the case if often not only about integrity, but also about authorization, and therefore it is not sufficient to know whether a packet was AH protect or not. It is also needed who sent the packet, and to be able to determine what that principal is authorized for. --Pekka Nikander From rja@extremenetworks.com Tue Jun 10 14:32:03 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5AIW3NJ011325 for ; Tue, 10 Jun 2003 14:32:03 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) h5AIW2dJ013560 for ; Tue, 10 Jun 2003 14:32:02 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 35BC16711F; Tue, 10 Jun 2003 15:02:30 -0400 (EDT) Date: Tue, 10 Jun 2003 14:32:02 -0400 Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Pekka Nikander From: RJ Atkinson In-Reply-To: <3EE6230C.1060708@nomadiclab.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 10 Jun 2003 18:32:04 -0000 On Tuesday, Jun 10, 2003, at 14:27 America/Montreal, Pekka Nikander wrote: > I agree with you both. However, the lack of an application level > API was *not* the point of my message. From my point of view, the lack > of such an API is an important but *distinct* problem. Agree. > From my point of view, considering things like ICMPv6, Mobile IPv6, > possibly multi6 solutions, and even HIP, there is a need to extend > the *role* of IPsec AH. AH was originally designed (pre-1995) to support ICMPv6, IPv6 ND, and similar applications. So that would not be an extension of its intended original role, but rather an application of AH for one of its intended roles. (Obviously) I think AH is a very good fit for those issues, while ESP is not a good fit. > Hence, I really think that we should consider how AH fits into the > overall stack structure (architecture, if you will). I think that > it could be a great tool for securing lots of ICMP/MIP/... kind of > traffic, but currently it is not. The extensions are not necessarily > that big; they would be mostly semantic. > > What I am asking for is to modify IPsec AH so that it can be used > for more, and especially in situations where there is clear > need to protect the IP layer or extension headers. There the case > if often not only about integrity, but also about authorization, > and therefore it is not sufficient to know whether a packet was > AH protect or not. It is also needed who sent the packet, and to > be able to determine what that principal is authorized for. What specific changes are you proposing ? AH was already designed to protect the IP header and IP-layer extension headers, so the change to the bits-on-the-wire that you are contemplating is not obvious to me from the above description. Ran rja@extremenetworks.com From ho@alum.mit.edu Tue Jun 10 14:43:21 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5AIhKNJ011519 for ; Tue, 10 Jun 2003 14:43:20 -0400 (EDT) Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) h5AIhHpE009735 for ; Tue, 10 Jun 2003 14:43:18 -0400 (EDT) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h5AIhY1o005888; Tue, 10 Jun 2003 12:43:34 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h5AIiU826580; Tue, 10 Jun 2003 12:44:30 -0600 Date: Tue, 10 Jun 2003 12:44:30 -0600 Message-Id: <200306101844.h5AIiU826580@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: moore@cs.utk.edu In-reply-to: Yourmessage <20030610122035.4c98ac5b.moore@cs.utk.edu> Subject: Re: [saag] Time to reconsider the role of IPsec AH? cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 10 Jun 2003 18:43:21 -0000 Watch IPSP for the PF_POLICY API. Hilarie > IPsec is pretty much useless to applications without > a) the ability to authenticate applications and users, rather than hosts > b) an API that lets apps specify and obtain credentials > as long as IPsec doesn't have those, apps will make do with TLS or > roll their own. From pekka.nikander@nomadiclab.com Tue Jun 10 14:56:08 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5AIu8NJ011736 for ; Tue, 10 Jun 2003 14:56:08 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) h5AIu7dJ024302 for ; Tue, 10 Jun 2003 14:56:07 -0400 (EDT) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id D8C421C; Tue, 10 Jun 2003 22:05:56 +0300 (EEST) Message-ID: <3EE62A01.7020900@nomadiclab.com> Date: Tue, 10 Jun 2003 21:57:05 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [saag] Time to reconsider the role of IPsec AH? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 10 Jun 2003 18:56:09 -0000 RJ Atkinson wrote: > What specific changes are you proposing ? > > AH was already designed to protect the IP header and IP-layer > extension headers, so the change to the bits-on-the-wire that > you are contemplating is not obvious to me from the above description. As I wrote, it may be that after all there would be no bits-on-the-wire modifications. Well, using RSA is certainly such a modification, but that is already going on in the SEND context, and the first draft is out (draft-ietf-send-ipsec-01.txt) and in last call. Anyway, most of the issues relate to implementations, and to what one can reasonably expect from an implementation when designing new protocols or new security solutions for existing protocols. What comes to the the details of this, let me return to the issue tomorrow. It is already late here, and my brains are getting muddy. However, we had a paper at Cambridge Security Protocols workshop that is somewhat related and discusses some of the issues. If you want to have a copy, let me know. --Pekka From rja@extremenetworks.com Tue Jun 10 15:04:01 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5AJ41NJ011888 for ; Tue, 10 Jun 2003 15:04:01 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) h5AJ3wpE017114 for ; Tue, 10 Jun 2003 15:03:59 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id C1FE767103; Tue, 10 Jun 2003 15:34:25 -0400 (EDT) Date: Tue, 10 Jun 2003 15:03:57 -0400 Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Pekka Nikander From: RJ Atkinson In-Reply-To: <3EE62A01.7020900@nomadiclab.com> Message-Id: <49B14A38-9B76-11D7-B33E-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 10 Jun 2003 19:04:02 -0000 On Tuesday, Jun 10, 2003, at 14:57 America/Montreal, Pekka Nikander wrote: > As I wrote, it may be that after all there would be no bits-on-the-wire > modifications. Well, using RSA is certainly such a modification, but > that is already going on in the SEND context, and the first draft is > out (draft-ietf-send-ipsec-01.txt) and in last call. Anyway, most > of the issues relate to implementations, and to what one can reasonably > expect from an implementation when designing new protocols or new > security solutions for existing protocols. Using RSA with AH ought not require any modification to the AH protocol itself. At least one prior AH implementation used public-key authentication with IPv6 ND in the past without any problems. To standardise this, one will need an open spec for exactly how one applies RSA to AH (e.g. an "RSA Transform" for AH), maybe also documentation on how one bootstraps into RSA (e.g. gets the needed public keys from someplace and binds them to end systems). There might also be documentation on the authorisation model, if one has been agreed upon. I would guess that if the key management approach being developed within the SEND WG is reasonably general, it might be reused for similar applications (e.g. PIM authentication) with little or no additional work. If there are other specifics, I'm all ears, either here on the SAAG list or off-list. Ran Atkinson rja@extremenetworks.com From huitema@windows.microsoft.com Tue Jun 10 13:37:02 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5AHb1NJ010557 for ; Tue, 10 Jun 2003 13:37:01 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) h5AHaxd5022656 for ; Tue, 10 Jun 2003 13:36:59 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 10 Jun 2003 10:36:56 -0700 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 10 Jun 2003 10:36:55 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Jun 2003 10:36:56 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Jun 2003 10:36:55 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 10 Jun 2003 10:36:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [saag] Time to reconsider the role of IPsec AH? Date: Tue, 10 Jun 2003 10:36:53 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Time to reconsider the role of IPsec AH? Thread-Index: AcMvcoMixtE+gVANRIiWc0b8xvGsFwAAj+Jg From: "Christian Huitema" To: "RJ Atkinson" , "Paul Hoffman / IMC" X-OriginalArrivalTime: 10 Jun 2003 17:36:54.0977 (UTC) FILETIME=[E288D310:01C32F76] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id h5AHb1NJ010557 X-Mailman-Approved-At: Tue, 10 Jun 2003 17:07:55 -0400 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 10 Jun 2003 17:37:02 -0000 I read Pekka's note, which relates to the use of AH in some scenarios, e.g. SEND. The real issue is, do we need both AH and ESP, or can something like ESP-NULL be used in lieu of AH and satisfy the AH scenarios? The main difference between AH and ESP-NULL is the authentication coverage. Since the ESP-NULL transform only apply to the payload, the header is not protected. If header fields need to be verified, ESP-NULL forces the protocol designers to repeat these header fields in the payload. This can be perceived as a drawback because of the extra overhead, but it also has a solid advantage in terms of implementation and interoperability: there is no need for a "header canonization" procedure and the associated pitfalls. Header canonization can be a royal pain in practice: some header fields are variable, and in IPv6 intermediate elements can insert intermediate headers, e.g. source address options or routing options. SEND is in fact the exception: secure neighbor discovery is a single hop operation, and no router has a chance to intervene and mangle the header. So the SEND scenario is maybe the only one in which header canonization will not be an issue. The question is thus, could ESP-NULL satisfy the SEND requirement? In the SEND scenario, a key information is the link-local address, and it is actually repeated in the payload of the Neighbor advertisement message. It would be protected by ESP-NULL. The other key information is the IPv6 source address. It is not part of the payload, but it is linked to the credentials used to set up the association, and may well in practice be covered. Bottom line, we need to take a hard look at whether ESP-NULL would satisfy the SEND requirements. -- Christian Huitema From huitema@windows.microsoft.com Tue Jun 10 16:53:18 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5AKrINJ014497 for ; Tue, 10 Jun 2003 16:53:18 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) h5AKrG1n023169 for ; Tue, 10 Jun 2003 16:53:16 -0400 (EDT) Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 10 Jun 2003 13:53:10 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 10 Jun 2003 13:53:10 -0700 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 10 Jun 2003 13:53:10 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Jun 2003 13:53:09 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Jun 2003 13:53:11 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 10 Jun 2003 13:53:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Jun 2003 13:53:08 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Is there such a thing as "IP superSEC"? Thread-Index: AcMvgZJFJ2RXZ2RXQweHDuaIiVVutQAEDZbA From: "Christian Huitema" To: X-OriginalArrivalTime: 10 Jun 2003 20:53:09.0426 (UTC) FILETIME=[4CA72920:01C32F92] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id h5AKrINJ014497 X-Mailman-Approved-At: Tue, 10 Jun 2003 17:07:55 -0400 Subject: [saag] Is there such a thing as "IP superSEC"? X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 10 Jun 2003 20:53:19 -0000 In an interview to CNET, Jeff Jaffe, president of Lucent Technologies' Bell Labs, states: "So we had IPsec (a wireless security standard that's short for "Internet protocol security"), and we've since developed an approach called IP SuperSEC... It essentially is a standardized way of encrypting, to the edge of the network, that gives the service provider choices and access. We'd only use it once it's standardized... The standards process takes two years. It started two or three months ago, so it's fresh off the presses." (http://news.com.com/2008-1082_3-1014912.html?tag=lh) Does anybody know what this "IP superSEC" is? -- Christian Huitema From crawdad@gungnir.fnal.gov Tue Jun 10 17:57:51 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5ALvoNJ015342 for ; Tue, 10 Jun 2003 17:57:51 -0400 (EDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) h5ALvo1n012219 for ; Tue, 10 Jun 2003 17:57:50 -0400 (EDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.12.8/8.12.8) with ESMTP id h5ALvnV1017037; Tue, 10 Jun 2003 16:57:49 -0500 (CDT) Message-Id: <200306102157.h5ALvnV1017037@gungnir.fnal.gov> To: Christian Huitema From: "Matt Crawford" Subject: Re: [saag] Time to reconsider the role of IPsec AH? In-reply-to: Your message of Tue, 10 Jun 2003 10:36:53 PDT. Date: Tue, 10 Jun 2003 16:57:49 -0500 Sender: crawdad@gungnir.fnal.gov cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 10 Jun 2003 21:57:51 -0000 > If header fields need to be verified, ESP-NULL forces the protocol > designers to repeat these header fields in the payload. This can be > perceived as a drawback because of the extra overhead, but it also > has a solid advantage in terms of implementation and > interoperability: there is no need for a "header canonization" > [sic] procedure and the associated pitfalls. But then the protocol has to know all the valid discrepancies which may exist between the actual header and the repeated field copies inside the payload -- knowledge which is complex but constant and is already part of AH processing. From mcgrew@cisco.com Tue Jun 10 21:25:59 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5B1PwNJ017584 for ; Tue, 10 Jun 2003 21:25:58 -0400 (EDT) Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) h5B1Pul2025065 for ; Tue, 10 Jun 2003 21:25:56 -0400 (EDT) Received: from MCGREW-W2K.cisco.com (stealth-10-34-251-100.cisco.com [10.34.251.100]) by sj-core-3.cisco.com (8.12.6/8.12.6) with SMTP id h5B1PdI3016498; Tue, 10 Jun 2003 18:25:40 -0700 (PDT) Message-Id: <4.3.2.7.2.20030610181241.022120c8@mira-sjcm-1.cisco.com> X-Sender: mcgrew@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Jun 2003 18:25:38 -0700 To: "Christian Huitema" From: David Mcgrew Subject: RE: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: Paul Hoffman / IMC cc: RJ Atkinson cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 01:25:59 -0000 Christian, At 10:36 AM 6/10/2003 -0700, Christian Huitema wrote: >I read Pekka's note, which relates to the use of AH in some scenarios, >e.g. SEND. The real issue is, do we need both AH and ESP, or can >something like ESP-NULL be used in lieu of AH and satisfy the AH >scenarios? > >The main difference between AH and ESP-NULL is the authentication >coverage. Since the ESP-NULL transform only apply to the payload, the >header is not protected. If header fields need to be verified, ESP-NULL >forces the protocol designers to repeat these header fields in the >payload. This can be perceived as a drawback because of the extra >overhead, but it also has a solid advantage in terms of implementation >and interoperability: there is no need for a "header canonization" >procedure and the associated pitfalls. > >Header canonization can be a royal pain in practice: some header fields >are variable, and in IPv6 intermediate elements can insert intermediate >headers, e.g. source address options or routing options. it is not clear to me how repeating some header fields within ESP NULL has an advantage over AH. Presumably we are authenticating those fields because we are going to parse them at the receiving end and make a security decision based on their contents. I can see that canonization can be a pain, but OTOH if we copy some fields into the ESP payload, we'll still need to marshal them on the sending side and to parse them and make the security check on the receiving side. I assume that this check would compare the authenticated values to the unauthenticated values, which implies that the headers would need to be parsed anyway. Also, we would have to standardize on a format for how the headers are stored within the ESP payload. Is there something that I'm missing here? David >SEND is in fact >the exception: secure neighbor discovery is a single hop operation, and >no router has a chance to intervene and mangle the header. So the SEND >scenario is maybe the only one in which header canonization will not be >an issue. > >The question is thus, could ESP-NULL satisfy the SEND requirement? In >the SEND scenario, a key information is the link-local address, and it >is actually repeated in the payload of the Neighbor advertisement >message. It would be protected by ESP-NULL. The other key information is >the IPv6 source address. It is not part of the payload, but it is linked >to the credentials used to set up the association, and may well in >practice be covered. Bottom line, we need to take a hard look at whether >ESP-NULL would satisfy the SEND requirements. > >-- Christian Huitema > > >_______________________________________________ >saag mailing list >saag@mit.edu >https://jis.mit.edu/mailman/listinfo/saag From pekka.nikander@nomadiclab.com Wed Jun 11 03:09:34 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5B79YNJ021115 for ; Wed, 11 Jun 2003 03:09:34 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) h5B79XIu025707 for ; Wed, 11 Jun 2003 03:09:34 -0400 (EDT) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 751911C; Wed, 11 Jun 2003 10:19:22 +0300 (EEST) Message-ID: <3EE6D5E7.7040906@nomadiclab.com> Date: Wed, 11 Jun 2003 10:10:31 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema Subject: Re: [saag] Time to reconsider the role of IPsec AH? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 07:09:35 -0000 Christian, > ... or can something like ESP-NULL be used in lieu of AH and satisfy > the AH scenarios? The difficultiws with this were covered well by others, and I don't have anyting to add. However, ... > Header canonization can be a royal pain in practice: some header > fields are variable, and in IPv6 intermediate elements can insert > intermediate headers, e.g. source address options or routing options. > Agreed. > SEND is in fact the exception: secure neighbor discovery is a single > hop operation, and no router has a chance to intervene and mangle the > header. Well, I almost agree. There are certainly other link-local operations too, like MLD. Some of those don't have very good or scalable enough security yet. > So the SEND scenario is maybe the only one in which header > canonization will not be an issue. Here I must disagree. Even though SEND and other link local scenarios may be the only ones where header canonization is less an issue than in non-local protocols, there are still protocols that need to preserve the integrity of the information in the IPv6 header. Mobile IPv6 is certainly one which could benefit from that. I have a strong suspicion that some multi-address multi-homing scenarios may belong to that class, too. It is not always sufficient that you rely on routing to make sure that the destination address has not been changed on the route. You sometimes want to have something stronger. More importantly, there are situations where the integrity of the source address is important. With the current IPv6 architecture, AH is a perfect match for these needs. It is a completely different issue if you move to an architecture where the destination address is just a routing token and there is no (semantically meaningful) source address. (For some ramblings about that, see our 2001 Nordsec paper, "IPv6 Source addresses considered harmful", http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf) --Pekka NIkander From pekka.nikander@nomadiclab.com Wed Jun 11 03:16:25 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5B7GONJ021215 for ; Wed, 11 Jun 2003 03:16:24 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) h5B7GOeD018034 for ; Wed, 11 Jun 2003 03:16:24 -0400 (EDT) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 902401C; Wed, 11 Jun 2003 10:26:13 +0300 (EEST) Message-ID: <3EE6D782.3080908@nomadiclab.com> Date: Wed, 11 Jun 2003 10:17:22 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: RJ Atkinson Subject: Using RSA with AH (was Re: [saag] Time to reconsider the role of IPsec AH?) References: <49B14A38-9B76-11D7-B33E-00039357A82A@extremenetworks.com> In-Reply-To: <49B14A38-9B76-11D7-B33E-00039357A82A@extremenetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 07:16:25 -0000 RJ Atkinson wrote: > Using RSA with AH ought not require any modification to the AH > protocol itself. If "protocol" == bits-on-the-wire, agreed. If "protocol" is something more, including behaviour, I am not so sure. > At least one prior AH implementation used public-key authentication > with IPv6 ND in the past without any problems. Any pointers? > To standardise this, one will need an open spec for exactly how one > applies RSA to AH (e.g. an "RSA Transform" for AH), maybe also > documentation on how one bootstraps into RSA (e.g. gets the needed > public keys from someplace and binds them to end systems). There is text about both of these in the send spec, but I don't know if they are generic enough for anything else. Our focus has been on SEND only, at this stage, with the idea of looking at possible generalizations once we have something out. In fact, I personally expect largish changes to SEND on the road from PS to DS. > There might also be documentation on the authorisation model, if one > has been agreed upon. To me, it looks like authorization is always application dependent. Thus, the authorization model for SEND is probably not good, as such, for anything else. > I would guess that if the key management approach being developed > within the SEND WG is reasonably general, it might be reused for > similar applications (e.g. PIM authentication) with little or no > additional work. Maybe. However, currently the IETF politics makes it hard to consider that without the danger of slowing down the speed of the SEND WG. > If there are other specifics, I'm all ears, either here on the SAAG > list or off-list. I'll send a separate message about those (cc:ing to the list). --Pekka Nikander From rja@extremenetworks.com Wed Jun 11 08:55:19 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5BCtENJ024442 for ; Wed, 11 Jun 2003 08:55:19 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) h5BCtDbI018802 for ; Wed, 11 Jun 2003 08:55:13 -0400 (EDT) Received: from extremenetworks.com (unknown [10.0.8.75]) by gnat.inet.org (Postfix) with ESMTP id 3BE9567103; Wed, 11 Jun 2003 09:25:47 -0400 (EDT) Date: Wed, 11 Jun 2003 08:55:08 -0400 Subject: Re: Using RSA with AH (was Re: [saag] Time to reconsider the role of IPsec AH?) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Pekka Nikander From: RJ Atkinson In-Reply-To: <3EE6D782.3080908@nomadiclab.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 12:55:20 -0000 On Wednesday, Jun 11, 2003, at 03:17 America/Montreal, Pekka Nikander wrote: >> At least one prior AH implementation used public-key authentication >> with IPv6 ND in the past without any problems. > > Any pointers? NRL's reference implementation of IPsec and IPv6 for 4.4 BSD. And Mike StJohns can confirm seeing the demonstration of authenticated bootstrapping of IPv6 (including ND) in August 1995; he was at ARPA in those days. I noted all this publicly during the SEND BOF in Yokohama, so I'm surprised you haven't heard it before. Because of patent issues, the IETF was not interested (at that time) in standardising use of RSA with AH/ESP. >> To standardise this, one will need an open spec for exactly how one >> applies RSA to AH (e.g. an "RSA Transform" for AH), maybe also >> documentation on how one bootstraps into RSA (e.g. gets the needed >> public keys from someplace and binds them to end systems). > > There is text about both of these in the send spec, but I don't > know if they are generic enough for anything else. Our focus > has been on SEND only, at this stage, with the idea of looking > at possible generalizations once we have something out. In fact, > I personally expect largish changes to SEND on the road from PS to DS. Architecturally, it might be cleaner to have 2 documents, one with an "RSA transform" for AH and the second with the bootstrap process. This partitioning would facilitate other folks/protocols/WGs re-using the 'transform' piece in other contexts, for example. >> There might also be documentation on the authorisation model, >> if one has been agreed upon. > > To me, it looks like authorization is always application dependent. > Thus, the authorization model for SEND is probably not good, as such, > for anything else. I'm not convinced that authorisation is always application-dependent. It is easy to believe that someone might devise an authorisation model for SEND that might not be fully general. Ran rja@extremenetworks.com From mcr@sandelman.ottawa.on.ca Wed Jun 11 09:16:25 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5BDGPNJ024688 for ; Wed, 11 Jun 2003 09:16:25 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78])h5BDGMbI025065 for ; Wed, 11 Jun 2003 09:16:24 -0400 (EDT) Received: from sandelman.ottawa.on.ca ([192.139.46.66])h5BDFqs17197 verified OK); Wed, 11 Jun 2003 09:15:56 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) h5ANZxdK007890; Tue, 10 Jun 2003 19:37:00 -0400 Message-Id: <200306102337.h5ANZxdK007890@sandelman.ottawa.on.ca> To: Pekka Nikander Subject: Re: [saag] Time to reconsider the role of IPsec AH? In-reply-to: Your message of "Tue, 10 Jun 2003 11:22:29 +0300." <3EE59545.3040106@nomadiclab.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 10 Jun 2003 19:35:59 -0400 From: Michael Richardson cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 13:16:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- A good message. Your points are all well taken to me. I have been saying for awhile that we need to keep AH - the reasons for it are not yet established, and have nothing to do with VPN. I do not know if we need an "AH" WG group. I'm not sure that it would be more effective than just doing the work in SEND. {I'd rather see a proper VPN profile of IPsec so that so that the *IP* security (not encryption) WG can progress on *securing* IP. But, that is a pipe dream.} ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPuZrXIqHRg3pndX9AQGClwP+N5x2NNi5NdG1gX1p+dj7iigYvOMT/TBv +Sm/37E4aV0/RotEp0oSrPawLuf5XVJr4It1gb0j8ax8PdcHkI88AQd/3bmTnmyY YSy37nHHTyqrW+xTzFz0aN9hQJj28kBHCf6ll5rH/U1xxjXecjmH0eEz4ih82hhf NAFyBgBn3Fg= =jsqE -----END PGP SIGNATURE----- From pekka.nikander@nomadiclab.com Wed Jun 11 09:55:47 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5BDtkNJ025225 for ; Wed, 11 Jun 2003 09:55:47 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) h5BDtibI007595 for ; Wed, 11 Jun 2003 09:55:45 -0400 (EDT) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 59F8B1C; Wed, 11 Jun 2003 17:05:29 +0300 (EEST) Message-ID: <3EE73517.6050601@nomadiclab.com> Date: Wed, 11 Jun 2003 16:56:39 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: RJ Atkinson Subject: Re: Using RSA with AH (was Re: [saag] Time to reconsider the role of IPsec AH?) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 13:55:48 -0000 RJ Atkinson wrote: > ... I noted all this publicly during the SEND BOF in Yokohama, > so I'm surprised you haven't heard it before. Sorry, Ran, I remember now that you mention it. I am unfortunately one of those people who have real difficulty remembering afterwards what people have talked about, especially if it has *not* taken place in my mother tongue. I seem to remember things much much better when written (but details badly even then). Anyway, I was more looking for real references, i.e., publications or other publicly available material that I could study. Mostly to see if we are missing something in our current work. > Because of patent issues, the IETF was not interested (at that time) in > standardising use of RSA with AH/ESP. I see. >>> To standardise this, one will need an open spec for exactly how one >>> applies RSA to AH (e.g. an "RSA Transform" for AH), maybe also >>> documentation on how one bootstraps into RSA (e.g. gets the needed >>> public keys from someplace and binds them to end systems). >> > Architecturally, it might be cleaner to have 2 documents, one with an > "RSA transform" for AH and the second with the bootstrap process. This > partitioning would facilitate other folks/protocols/WGs re-using the > 'transform' piece in other contexts, for example. Architecturally, it would be cleaner if we had about 4 documents in SEND instead of the currently two. However, James is really pushing speed, and I don't mind. >> To me, it looks like authorization is always application dependent. >> Thus, the authorization model for SEND is probably not good, as such, >> for anything else. > > I'm not convinced that authorisation is always application-dependent. Would you care to clarify? I am somewhat surprised. --Pekka Nikander From warlord@MIT.EDU Wed Jun 11 10:30:44 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5BEUiNJ025697 for ; Wed, 11 Jun 2003 10:30:44 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82])h5BEUebI019492; Wed, 11 Jun 2003 10:30:41 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71])h5BEUdgg005960; Wed, 11 Jun 2003 10:30:40 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) h5BEUdFJ016764; Wed, 11 Jun 2003 10:30:39 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id KAA23835; Wed, 11 Jun 2003 10:30:39 -0400 (EDT) To: RJ Atkinson From: Derek Atkins Subject: Re: [saag] Time to reconsider the role of IPsec AH? References: <080A2FAC-9B70-11D7-B33E-00039357A82A@extremenetworks.com> Date: 11 Jun 2003 10:30:39 -0400 In-Reply-To: <080A2FAC-9B70-11D7-B33E-00039357A82A@extremenetworks.com> Message-ID: Lines: 63 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: saag@MIT.EDU cc: Christian Huitema X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 14:30:44 -0000 Ran, It's time for me to play devil's advocate here. I don't have a strong preference about AH v. ESP-NULL, but at the same time I see a very strong "I'm right, you're wrong, this is the right way!" attitude from a number of people in this thread. So, please bear with me as I ask a few pointed (albeit short) questions herein.... RJ Atkinson writes: > On Tuesday, Jun 10, 2003, at 13:36 America/Montreal, Christian Huitema > wrote: > > I read Pekka's note, which relates to the use of AH in some scenarios, > > e.g. SEND. The real issue is, do we need both AH and ESP, or can > > something like ESP-NULL be used in lieu of AH and satisfy the AH > > scenarios? > > AH is the right answer for IP-layer authentication, as Pekka noted. Ok, _why_ is it "the right answer"? What particular features of AH, that do NOT exist in ESP-NULL, make it "the right answer"? Or vice-versa, what particular features of ESP-NULL make it "not the right answer"? Please be specific. > Anything using ESP-NULL is actually more complex to implement and > less likely to interoperate for things like IPv6 ND or IPv6 ICMP > (or IPv4 ICMP/IGMP) authentication. Free running code that > interoperates > today exists for AH with this application in *BSD and elsewhere. Ok.... On what basis do you conclude that ESP-NULL is less likely to interoperate? Why do you consider ESP-NULL more complex than AH? Why do you feel that using ESP-NULL for IPv6 ND or IPv6 ICMP is any less of an interop issue than ESP-NULL for TCP? In a similar vein, on what basis do you conclude that AH is any easier to implement? > The only thing SEND really needs to address is the key-management. > For the BSD stack in my local IPv6 systems, everything is is in place > and interoperable today for authenticating IPv6 ND -- except for key > management to get the appropriate SA(s) in place. > > > The question is thus, could ESP-NULL satisfy the SEND requirement? > > No. Ok, could you be more explicit? What feature(s) is(are) missing from ESP-NULL such that it does not satisfy the SEND requirements? I'm specifically looking for "it cannot do foo", not "AH does foo better". I'm trying to understand what is so intrinsically different about ESP-NULL (or about the SEND requirements) that resulted in such a terse reply. > Ran > rja@extremenetworks.com -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From mcr@sandelman.ottawa.on.ca Wed Jun 11 13:04:47 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5BH4kNJ027619 for ; Wed, 11 Jun 2003 13:04:46 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78])h5BH4hro014110 for ; Wed, 11 Jun 2003 13:04:46 -0400 (EDT) Received: from sandelman.ottawa.on.ca ([192.139.46.66])h5BH4cq18020 verified OK) for ; Wed, 11 Jun 2003 13:04:40 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) h5BH4XFl007357 for ; Wed, 11 Jun 2003 13:04:33 -0400 Message-Id: <200306111704.h5BH4XFl007357@sandelman.ottawa.on.ca> To: saag@mit.edu Subject: Re: [saag] Time to reconsider the role of IPsec AH? In-reply-to: Your message of "11 Jun 2003 10:30:39 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 11 Jun 2003 13:04:32 -0400 From: Michael Richardson X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 17:04:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Derek" == Derek Atkins writes: >> AH is the right answer for IP-layer authentication, as Pekka noted. Derek> Ok, _why_ is it "the right answer"? What particular features of AH, Derek> that do NOT exist in ESP-NULL, make it "the right answer"? Or Derek> vice-versa, what particular features of ESP-NULL make it "not the Derek> right answer"? Please be specific. AH *guarantees* that the data that follows the packet are not encrypted. As such, one can look at the things that follow, decide if they are even interesting, and *only* then, calculate the authenticator. (Which might involve doing RSA, finding the right public key, etc...) ESP does not make this guarantee. The recipient who assigned the SPI# possibly look up the algorithm in the SPD and find out that it was NULL, but nobody else can. (Nor can the recipient if they have rebooted since) So, AH is appropriate for securing things like ARP/ND, which are likely to be broadcast/multicast. ESP-null can only be used between consenting parties that know about each other already. Now, to backtrack a bit - an RSA Transform for AH would like use a well-known SPI#. That *could* be done for ESP-null, but I do not see the advantage of doing so, if the things you wanted to authenticate were extension headers. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPudhH4qHRg3pndX9AQGNsQP/RSpCQA4vEDFdHMxYkcMd+FM/cBt9BofS dljYCMXy7wnb7oVmm1/KFyQOOse3z/g1hHaBqn3apF0nQJ1ZtyI74nr9SLCrWW5E 0dw7v4/AJ/Fat/a0ElZb42Sm2IQrAfnIWIKs/pQCNOAfq61LPef712zUeHM84LF6 9HkDmxOnc4g= =NKhr -----END PGP SIGNATURE----- From pekka.nikander@nomadiclab.com Wed Jun 11 14:17:37 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5BIHbNJ028640 for ; Wed, 11 Jun 2003 14:17:37 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) h5BIHaSC008663 for ; Wed, 11 Jun 2003 14:17:36 -0400 (EDT) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 05D8B1C; Wed, 11 Jun 2003 21:27:25 +0300 (EEST) Message-ID: <3EE7727B.8090407@nomadiclab.com> Date: Wed, 11 Jun 2003 21:18:35 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [saag] Time to reconsider the role of IPsec AH? References: <3EE62A01.7020900@nomadiclab.com> In-Reply-To: <3EE62A01.7020900@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 18:17:38 -0000 RJ Atkinson wrote: >> What specific changes are you proposing ? >> >> AH was already designed to protect the IP header and IP-layer >> extension headers, so the change to the bits-on-the-wire that you >> are contemplating is not obvious to me from the above description. I wrote: > As I wrote, it may be that after all there would be no > bits-on-the-wire modifications. ... Anyway, most of the issues > relate to implementations, and to what one can reasonably expect from > an implementation when designing new protocols or new security > solutions for existing protocols. > > What comes to the the details of this, let me return to the issue > tomorrow. From my point of view, the big issue here is authorization. AH, as deployed today, protects the integrity and authenticity of the packet. That is, at AH layer it is known who sent the message and that the message was not modified while in transit. However, in many implementations this information is not available to the upper layers. The source IP address can act as a hint, but it is not an ideal identifier. One issue here is, of course, what I mean with authorization. Let me take a couple of examples. In SEND, the question to answer is to say who is authorized to say which MAC address to use when sending unicast messages to a given IP address. That is, the authority over creating IPv6 address -> MAC address bindings. Respectively, in Mobile IP the question is about the right to create IP address -> IP address bindings. In both of these cases, therefore, the question is on who is authorized to create state wrt. a given IP address, but the exact nature of the state is different. In other cases, the state and the right to create state could be different. One could argue that AH should completely perform the required authorization check and only pass authorized packets to the upper layer. However, that turns out to pretty hard, resulting in duplicating or moving some application specific code to AH. --Pekka Nikander From rja@extremenetworks.com Wed Jun 11 14:44:57 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5BIiuNJ029088 for ; Wed, 11 Jun 2003 14:44:56 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) h5BIirSC018804 for ; Wed, 11 Jun 2003 14:44:54 -0400 (EDT) Received: from extremenetworks.com (unknown [10.0.8.109]) by gnat.inet.org (Postfix) with ESMTP id 5713067103; Wed, 11 Jun 2003 15:15:28 -0400 (EDT) Date: Wed, 11 Jun 2003 14:43:54 -0400 Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Pekka Nikander From: RJ Atkinson In-Reply-To: <3EE7727B.8090407@nomadiclab.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 18:44:57 -0000 On Wednesday, Jun 11, 2003, at 14:18 America/Montreal, Pekka Nikander wrote: > From my point of view, the big issue here is authorization. > AH, as deployed today, protects the integrity and authenticity > of the packet. That is, at AH layer it is known who sent the > message and that the message was not modified while in transit. > However, in many implementations this information is not > available to the upper layers. The source IP address can act > as a hint, but it is not an ideal identifier. Implementation details vary of course. The NRL IPv6+IPsec code had (IPv6, IPv4, ICMP, IPv6 ND, ESP/AH, and hooks to key management) all inside a single "layer. The KAME code is different from NRL in details, but has a lot of similarities in terms of layering (no surprise since both KAME and NRL were working from 4.4 BSD sources). The cisco IOS IPv6 code that I wrote also had IPv6 ND and IPv6 ICMP as an integral part of the IPv6 "layer" (that code might have changed in the intervening years, of course, though I can't immediately think of why anyone would have changed that aspect of the code). Back when I was coding on cisco IOS IPv6, the ESP/AH code (then) only supported IPv4 and was written by other folks (in the security group; I was in the routing group) -- so I'm not sure how integrated/decoupled the ESP/AH code in IOS is from the IPv6 code. Most 4.3/4.4 BSD implementations do not have strict layering boundaries in their source code (e.g. between TCP and IP). Cisco IOS is not very BSDish, but also did not have rigid layering boundaries (at least when I was working with it). The absence of standardised APIs to make information such as "sender identity" or "packet was received and authentication succeeded" is a significant issue, though I view it as more of a concern for applications (e.g. SMTP, FTP) than for protocols (e.g. ND, ICMP) that are internal-to IPv6 or IPv4. Many ESP/AH implementations do have APIs for those things, though the details of such APIs probably vary annoyingly. I know that some folks are trying to sort out those API issues, but am not sure where that discussion stands today. > One issue here is, of course, what I mean with authorization. > Let me take a couple of examples. In SEND, the question to > answer is to say who is authorized to say which MAC address to > use when sending unicast messages to a given IP address. That > is, the authority over creating > > IPv6 address -> MAC address > > bindings. Since (IPv6 ND, IPv6 ICMP, AH, and ESP) are all inside the same layer, namely the IP layer, I would bet that most implementations have all the information resulting from receive-side AH processing fully available to the ND code without any API issues getting in the way. > Respectively, in Mobile IP the question is about > the right to create > > IP address -> IP address > > bindings. > > In both of these cases, therefore, the question is on who > is authorized to create state wrt. a given IP address, but > the exact nature of the state is different. In other cases, > the state and the right to create state could be different. > > One could argue that AH should completely perform the > required authorization check and only pass authorized > packets to the upper layer. However, that turns out to > pretty hard, resulting in duplicating or moving some > application specific code to AH. I have not myself ever coded up "Mobile IPv6". However, I still see this as (1) an API issue if Mobile IPv6 is implemented very separately from IPv6/ICMP/ND/AH/ESP or (2) not an issue if Mobile IPv6 is implemented as part of the IPv6 "layer". The issues you raise in this note are very important. To me, they seem mostly to be implementation-oriented concerns rather than "protocol spec"/"bits on the wire"/"protocol architecture" concerns. Maybe I've missed one of your points, not sure. If so, my apologies. Ran Atkinson rja@extremenetworks.com From rja@extremenetworks.com Wed Jun 11 14:58:40 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5BIweNJ029344 for ; Wed, 11 Jun 2003 14:58:40 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) h5BIwdSC023745 for ; Wed, 11 Jun 2003 14:58:39 -0400 (EDT) Received: from extremenetworks.com (unknown [10.0.8.109]) by gnat.inet.org (Postfix) with ESMTP id 4E07967103 for ; Wed, 11 Jun 2003 15:29:16 -0400 (EDT) Date: Wed, 11 Jun 2003 14:58:35 -0400 Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: RJ Atkinson To: saag@mit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <200306111704.h5BH4XFl007357@sandelman.ottawa.on.ca> Message-Id: X-Mailer: Apple Mail (2.552) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 18:58:41 -0000 On Wednesday, Jun 11, 2003, at 13:04 America/Montreal, Michael Richardson wrote: > AH *guarantees* that the data that follows the packet are not > encrypted. > As such, one can look at the things that follow, decide if they are > even > interesting, and *only* then, calculate the authenticator. (Which might > involve doing RSA, finding the right public key, etc...) > > ESP does not make this guarantee. The recipient who assigned the SPI# > possibly look up the algorithm in the SPD and find out that it was > NULL, > but nobody else can. (Nor can the recipient if they have rebooted > since) > > So, AH is appropriate for securing things like ARP/ND, which are > likely > to be broadcast/multicast. ESP-null can only be used between consenting > parties that know about each other already. > > Now, to backtrack a bit - an RSA Transform for AH would like use a > well-known SPI#. That *could* be done for ESP-null, but I do not see > the > advantage of doing so, if the things you wanted to authenticate were > extension headers. All good points. I'll add a few more, though this is not by any means a comprehensive list yet. Additionally, IPv6 ICMP/ND uses the contents of the IPv6 base header (and potentially also some extension headers) in their processing. - ESP Null could only authenticate copies of those headers -- which means the sender has to copy all those fields (an extra step) and the receiver would need to compare all those fields (outer header contents against encapsulated header contents) (another extra step). No one has all this coded up today. The extra processing is complicated, easy to get wrong, and not likely to interoperate the first time. Most IPv6 implementations already support AH, interoperate today with AH, and AH already authenticates all those fields without any need for copying on the sending side or for comparison on the receiving side. Bottom line is that AH was *designed* to address the ND/ICMP/routing-protocol authentication problem space, while ESP-Null was designed for the authentication-only VPN problem space. The SEND archives are also worth reading if one wants to understand how that WG reached the conclusion that AH was the best approach. Ran rja@extremenetworks.com From jari.arkko@piuha.net Wed Jun 11 18:56:18 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5BMuINJ002156 for ; Wed, 11 Jun 2003 18:56:18 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) h5BMuGh7007531 for ; Wed, 11 Jun 2003 18:56:17 -0400 (EDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 84DB26A906; Thu, 12 Jun 2003 01:56:14 +0300 (EEST) Message-ID: <3EE7B328.3060909@piuha.net> Date: Thu, 12 Jun 2003 01:54:32 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [saag] Time to reconsider the role of IPsec AH? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 22:56:19 -0000 Hello folks, Thank you Pekka for raising this discussion. I think we need to seriously consider the fate of AH, and perhaps even more generally the use of IPsec in the context of IP layer control protocols or applications (the non-VPN uses). Over the last few years I've worked with securing ND using a number of alternative techniques techniques. I am also the editor of the current protocol specification for SEND. The discussion in this thread seems to be centered around three subjects so far: - the original question of refocusing AH for IP layer tasks - availability and properties of the required APIs - adequacy of null ESP vs. AH for the task in SEND - history for the focus of the IPsec WG Here's my take on the issues: I'm happy to hear that there's more work on the APIs than I realized before. I think we should resist the temptation to talk about the ESP vs. AH issue. The difference is largely insignificant from the 10.000 ft level, and we will miss more important issues while debating this. Say, how good match are SPD mechanisms for problems like SEND? I'd like to focus on Pekka's questions. The way he phrased it was: can we make AH more suitable for various IP layer control protocols? I'd like to suggest another question which allows us to look at the problem, not the hammer: How should we secure the IP layer control functions? And what are the alternatives and their respective advantages and disadvantages? 1) Use of IPsec -- some support from an existing protocol but also some extensions and implementation work needed. 2) "Application" specific security solutions -- a perfect match to the needs of the applications, but different and new solutions required for the different applications. I'm coming to the conclusion that approach 2 is the right choice. (I realize that this may be strange coming from the editor of the SEND document, but editors don't get to make decisions, WG consensus makes decisions.) But let me explain why I'm coming to this conclusion. Basically, all the IP level control protocols have very specific security needs. It is possible to satisfy them using IPsec, but I doubt that the cost(s) are worth it. As an example, in SEND the use of IPsec instead of ND options causes the following: - Need to extend AH with public key crypto algorithms. Also need to make a number of other smaller extensions, such as ICMP type selectors or making it possible to look up SAs based on the SPI and not the destination address (the latter I believe is a part of 2406bis work, too). - Need to rely on the existence of an API between the IPsec and ND parts. And not just a simple configuration API, but I fear that we may need a per-packet API. - Need to modify ND behaviour, since ND as-is uses addresses in a way that isn't representable in the SPD easily. - Need to provide a (small) part of the security solution anyway in the ND layer since some issues can not be handled at the IPsec layer due to their inter-packet nature. - Need to make compromises on how well the end result works in a mixed secure/non-secure environments. All of the above issues are solvable. In fact the current specification solves them. But I believe the alternative solution would have been simpler, would not imply so many implementation requirements, would be contained in a single module, would not be so fragile if something changes in the protocol to be secured, and could be deployed faster. --Jari From randy@psg.com Wed Jun 11 20:57:31 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5C0vUNJ003253 for ; Wed, 11 Jun 2003 20:57:30 -0400 (EDT) Received: from psg.com (psg.com [147.28.0.62])h5C0vUso002455 for ; Wed, 11 Jun 2003 20:57:30 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19QGPB-0004Jf-00; Thu, 12 Jun 2003 00:57:29 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19QGPA-00057o-Co; Thu, 12 Jun 2003 09:57:28 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 12 Jun 2003 09:57:27 +0900 To: saag@mit.edu Message-Id: cc: "George M. Jones" Subject: [saag] Security Requirements Intnernet Draft (a request for comments) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 12 Jun 2003 00:57:31 -0000 From: "George M. Jones" I've published an Internet Draft on "Security Requirements for Devices Implementing IP". You can view it at: http://www.ietf.org/internet-drafts/draft-jones-opsec-00.txt This is an outgrowth of a document used by UUNET (my former employer) to sanity check/security qualify equipment for connection to the backbone. The point of publishing the document is to start discussion. There is a mailing list set up: opsec@ops.ietf.org. Subscribe by sending a message to "majordomo@ops.ietf.org" with "subscribe opsec" in the body. The point of the document is to create a useful list that network operators can use to communicate their securtiy requirements to vendors. Please have a look and comment. Thanks, ---George Jones From rja@extremenetworks.com Wed Jun 11 21:05:37 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5C15aNJ003421 for ; Wed, 11 Jun 2003 21:05:37 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) h5C15Zso003970 for ; Wed, 11 Jun 2003 21:05:35 -0400 (EDT) Received: from extremenetworks.com (unknown [10.0.8.149]) by gnat.inet.org (Postfix) with ESMTP id 779BE6711B; Wed, 11 Jun 2003 21:30:52 -0400 (EDT) Date: Wed, 11 Jun 2003 21:04:32 -0400 Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: jari.arkko@piuha.net From: RJ Atkinson In-Reply-To: <3EE7B328.3060909@piuha.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: saag@mit.edu cc: Pekka Nikander X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 12 Jun 2003 01:05:37 -0000 On Wednesday, Jun 11, 2003, at 18:54 America/Montreal, Jari Arkko wrote: > I'm happy to hear that there's more work on the APIs > than I realized before. As I noted in a note earlier today, the actual implementation of ND inside a single layer, along with IPv6, AH, and ESP, means that APIs are not generally a proximal issue for the use of either AH/ESP with IPv6 ND. > Say, how good match are SPD mechanisms for problems like > SEND? RFC-1825 through RFC-1827 don't mention "SPD" at all. SPDs are a useful conceptual construct to clarify aspects of AH/ESP. My understanding has been that the SPD was not intended to be restrictive so much as descriptive, maybe I've misread the current drafts for AH/ESP. In any event, adding selectors to the current draft ought not be difficult if folks felt it were useful/needed. > can we make AH more suitable for various IP layer > control protocols? Again, I repeat my earlier question: Which specific changes are being contemplated (beyond the AH transform for RSA and the boostrap process to get initial keys for ND to use) and why would those changes be needed ? > I'd like to suggest another question which > allows us to look at the problem, not the hammer: How > should we secure the IP layer control functions? And > what are the alternatives and their respective > advantages and disadvantages? 1) Use of IPsec -- some > support from an existing protocol but also some extensions > and implementation work needed. 2) "Application" specific > security solutions -- a perfect match to the needs of > the applications, but different and new solutions required > for the different applications. If one devised a general solution to applying Public Key cryptography for authentication with AH, that solution would likely be applicable (without substantial additional work) to at least: - OSPFv3 - PIM - IGMP - ICMP The SEND WG has chosen not to work on that general problem, but instead has focused on a very ND-centric approach. That's a legitimate choice for the WG to make. A side effect of that choice is that the approach in the SEND documents might not be the "general solution" I mentioned in the previous paragraph. > I'm coming to the conclusion that approach 2 is the right > choice. (I realize that this may be strange coming from the > editor of the SEND document, but editors don't get to make > decisions, WG consensus makes decisions.) But let me explain > why I'm coming to this conclusion. Basically, all the IP level > control protocols have very specific security needs. It is > possible to satisfy them using IPsec, but I doubt that the > cost(s) are worth it. As an example, in SEND the use of > IPsec instead of ND options causes the following: > > - Need to extend AH with public key crypto algorithms. This is a pretty modest amount of work -- and is useful for things well beyond ND/SEND, so ought to be done regardless, IMHO. Earlier on, patent issues were an impediment that they no longer are. > Also > need to make a number of other smaller extensions, such > as ICMP type selectors or making it possible to look up > SAs based on the SPI and not the destination address > (the latter I believe is a part of 2406bis work, too). Running code from NRL in 1995 showed that one could easily do the lookup using both Dest Addr and SPI (even when Dest Addr is a multicast group). We had AH-authenticated IPv6 ND running back in late August 1995, so there is strong experimental evidence that this can work fine without necessarily changing the SA lookup code. Of course alternate approaches probably also exist. I'm just noting that at least one approach doesn't necessarily require all those tweaks. > - Need to rely on the existence of an API between the > IPsec and ND parts. And not just a simple configuration > API, but I fear that we may need a per-packet API. Those "parts" are normally (always ?) implemented as a single layer inside real-world IPv6 software, so an API is not normally needed between them. > - Need to modify ND behaviour, since ND as-is uses addresses > in a way that isn't representable in the SPD easily. Again, we did not have to modify ND in 1995 to get AH to work with IPv6 ND. Now, ND has mutated a fair bit since 1995, but it still is not immediately obvious (to me) why such a modification to ND behaviour is really necessary today. > - Need to provide a (small) part of the security solution > anyway in the ND layer since some issues can not be > handled at the IPsec layer due to their inter-packet > nature. They aren't separate layers !!! > - Need to make compromises on how well the end result > works in a mixed secure/non-secure environments. Which compromises ? Why needed ? > All of the above issues are solvable. In fact the > current specification solves them. But I believe the > alternative solution would have been simpler, would > not imply so many implementation requirements, would > be contained in a single module, would not be so > fragile if something changes in the protocol to be > secured, and could be deployed faster. My impression from your note and Pekka's notes is that you all have done a very thorough theoretical analysis, but that a number of the issues raised exist only in theory, but not really in practice in deployed software. In at least the KAME and NRL codebases, many of the issues you identify above do not exist. I am pretty sure that KAME is the basis for a plurality (maybe even a majority) of the IPv6 implementations out there. KAME is in *BSD, MacOS, etc. KAME is also the basis for numerous other products built on various RTOSs (e.g. I know of several routers that include the KAME IPv6 stack). So the KAME implementation is a useful reference point, IMHO. Yours, Ran Atkinson rja@extremenetworks.com From mankin@psg.com Tue Jun 10 23:14:52 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5B3EqNJ018643 for ; Tue, 10 Jun 2003 23:14:52 -0400 (EDT) Received: from psg.com (psg.com [147.28.0.62])h5B3Eq89007292 for ; Tue, 10 Jun 2003 23:14:52 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19Pw4Z-00028G-00; Wed, 11 Jun 2003 03:14:51 +0000 To: "Christian Huitema" Subject: Re: [saag] Is there such a thing as "IP superSEC"? In-Reply-To: Message from "Christian Huitema" Date: Tue, 10 Jun 2003 20:14:50 -0700 From: Allison Mankin Message-Id: X-Mailman-Approved-At: Wed, 11 Jun 2003 21:18:19 -0400 cc: jon.peterson@neustar.biz cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 03:14:53 -0000 Christian, IPSuperSec is the Lucent name for approaching the problem of IPsec blocking the ability of networks to perform services such as RFC 3135 PEPs. SAAG saw a presentation in Atlanta on the original approach under this name, by Sneha Kasera from Lucent. This original approach was an extension of IPsec, and the SAAG recommendation was that this work not go forward. Lucent took the recommendation to change gears, while still aiming to work on the problem at IETF. The name just stayed on. In IETF, it seemed possible to some transport and security folks that the endsystem (or both endsystems) and the intermediary could have a new protocol approach for handling this problem, one at a transport level, so in Yokohama, Transport sponsored the Intersec BOF to begin discussing the problem in ways that would give transport services (and secure them) outside of IPsec, without being an IPsec extension. The group from Lucent wrote a requirements document, (draft-faynberg-transport-intermediary-00.txt) for the BOF. The BOF called for continued work in IETF, so there will be further developments. There's a mailing list (intersec-request@psg.com). Disclosure: I'm Transport Co-AD, but I also work for Bell Labs. I think the work is important, but I'm ensuring the BOFs etc are evaluated by others than myself to be careful about conflict of interest. Allison > > In an interview to CNET, Jeff Jaffe, president of Lucent Technologies' > Bell Labs, states: "So we had IPsec (a wireless security standard > that's short for "Internet protocol security"), and we've since > developed an approach called IP SuperSEC... It essentially is a > standardized way of encrypting, to the edge of the network, that gives > the service provider choices and access. We'd only use it once it's > standardized... The standards process takes two years. It started two or > three months ago, so it's fresh off the presses." > (http://news.com.com/2008-1082_3-1014912.html?tag=lh) > > Does anybody know what this "IP superSEC" is? > > -- Christian Huitema > > > > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag From smb@research.att.com Wed Jun 11 21:32:32 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5C1WWNJ003889 for ; Wed, 11 Jun 2003 21:32:32 -0400 (EDT) Received: from linux.research.att.com (H-135-207-24-16.research.att.com [135.207.24.16])h5C1WWso009358 for ; Wed, 11 Jun 2003 21:32:32 -0400 (EDT) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101])h5C1c9EI007136 for ; Wed, 11 Jun 2003 21:38:09 -0400 Received: from berkshire.research.att.com (sigaba.research.att.com [135.207.23.169])h5C1RgV28906 for ; Wed, 11 Jun 2003 21:27:42 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 8F3637B4D for ; Wed, 11 Jun 2003 20:52:45 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: Steve Bellovin To: saag@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Jun 2003 20:52:45 -0400 Message-Id: <20030612005245.8F3637B4D@berkshire.research.att.com> Subject: [saag] Security Requirements Intnernet Draft (a request for comments) (F orwarded) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 12 Jun 2003 01:32:33 -0000 Comments welcome. ------- Forwarded Message Message-ID: <3EE7C8A6.8080706@mitre.org> Date: Wed, 11 Jun 2003 20:26:14 -0400 From: "George M. Jones" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nanog@merit.edu Subject: Security Requirements Intnernet Draft (a request for comments) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-nanog@merit.edu Precedence: bulk Errors-To: owner-nanog-outgoing@merit.edu X-Loop: nanog X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_MOZILLA_UA,X_LOOP autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) I've published an Internet Draft on "Security Requirements for Devices Implementing IP". You can view it at: http://www.ietf.org/internet-drafts/draft-jones-opsec-00.txt This is an outgrowth of a document used by UUNET (my former employer) to sanity check/security qualify equipment for connection to the backbone. The point of publishing the document is to start discussion. There is a mailing list set up: opsec@ops.ietf.org. Subscribe by sending a message to "majordomo@ops.ietf.org" with "subscribe opsec" in the body. The point of the document is to create a useful list that network operators can use to communicate their securtiy requirements to vendors. Please have a look and comment. Thanks, - ---George Jones ------- End of Forwarded Message --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) From jari.arkko@piuha.net Thu Jun 12 02:45:49 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5C6jnNJ006706 for ; Thu, 12 Jun 2003 02:45:49 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) h5C6jmgE018165 for ; Thu, 12 Jun 2003 02:45:48 -0400 (EDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id AA8666A907; Thu, 12 Jun 2003 09:45:46 +0300 (EEST) Message-ID: <3EE82134.5040901@piuha.net> Date: Thu, 12 Jun 2003 09:44:04 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [saag] Time to reconsider the role of IPsec AH? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: saag@mit.edu cc: Pekka Nikander X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 12 Jun 2003 06:45:50 -0000 RJ Atkinson wrote: > SPDs are a useful conceptual construct to clarify aspects > of AH/ESP. My understanding has been that the SPD was > not intended to be restrictive so much as descriptive, > maybe I've misread the current drafts for AH/ESP. In > any event, adding selectors to the current draft ought > not be difficult if folks felt it were useful/needed. Ok, great! > If one devised a general solution to applying Public Key > cryptography for authentication with AH, that solution > would likely be applicable (without substantial additional > work) to at least: > - OSPFv3 > - PIM > - IGMP > - ICMP > > The SEND WG has chosen not to work on that general problem, > but instead has focused on a very ND-centric approach. > That's a legitimate choice for the WG to make. A side > effect of that choice is that the approach in the SEND > documents might not be the "general solution" I mentioned > in the previous paragraph. Actually, I believe the solution we have is quite general. This is a bit visible in the name of the new transform which is AH_RSA_Sig rather than, say, AH_SEND. However, the documentation of the feature is in a section of the SEND spec, not its free standing specification. And we are not marketing the solution for a large number of folks, collecting their requirements, and getting everyone's agreements and so forth. This is so mainly in the interest of publishing the spec in a reasonable amount of time. Still, I believe the exact mechanism could be applied in other contexts as well. One technical thing that is not general is the retrieval of cert chains for the peer. We've chosen to do this outside AH for efficiency reasons (don't have to send it every time). This means that we still expect AH_RSA_Sig to get the necessary cert chains from ND. However, you could perhaps argue that in a different application there'd be something else that is feeding the same information to AH via an API. >> - Need to rely on the existence of an API between the >> IPsec and ND parts. And not just a simple configuration >> API, but I fear that we may need a per-packet API. > > > Those "parts" are normally (always ?) implemented as a > single layer inside real-world IPv6 software, so an API > is not normally needed between them. Well, an interface is probably internally needed in any case. But I agree this is easier given that they are in the same layer. What about BITS implementations? >> - Need to modify ND behaviour, since ND as-is uses addresses >> in a way that isn't representable in the SPD easily. > > > Again, we did not have to modify ND in 1995 to get AH to work > with IPv6 ND. Now, ND has mutated a fair bit since 1995, but > it still is not immediately obvious (to me) why such a modification > to ND behaviour is really necessary today. Part of the reason for the need of the changes is probably that we attempt to treat the authorization issues at a demanding level. In particular, it is not sufficient for us to use a good guys - bad guys separation. We are also making sure that one of the good guys doesn't spoof another good guy's addresses, for instance. Your model from 1995 may have had a slightly different security model so it didn't need to treat this. This translates into a need to worry about who is making what changes to Neighbor Caches etc. As a result, we are in some cases using a tentative address source rather than the currently mandated unspecified address. > My impression from your note and Pekka's notes is that you > all have done a very thorough theoretical analysis, but > that a number of the issues raised exist only in theory, > but not really in practice in deployed software. Well, like I said the current documents are based on the use of IPsec. I believe its implementable at least in most cases, and may even have some aspects of the generality that you wanted. That's not the question. I just believe it would be easier in another way. I also look it from this point: if we are not using SPDs like you suggest, if the application is in direct control of AH packet processing, if the current algorithms are not used, if the format for the Authentication Data field looks very different from current formats, if sequence number field is not used, why are we reusing AH? I mean it has to be not just possible, but also useful, right? Perhaps the generality aspects are the useful thing that justifies this? Maybe... and that's part of the reason we're having this discussion. But its still a tradeoff, and I think an "application" solution would produce an overall better result. --Jari From rja@extremenetworks.com Thu Jun 12 10:17:35 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5CEHTNJ011118 for ; Thu, 12 Jun 2003 10:17:34 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) h5CEHSFW025813 for ; Thu, 12 Jun 2003 10:17:29 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id DB01667106; Thu, 12 Jun 2003 10:42:55 -0400 (EDT) Date: Thu, 12 Jun 2003 10:17:26 -0400 Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: jari.arkko@piuha.net From: RJ Atkinson In-Reply-To: <3EE82134.5040901@piuha.net> Message-Id: <9813572E-9CE0-11D7-A5E6-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 12 Jun 2003 14:17:35 -0000 On Thursday, Jun 12, 2003, at 02:44 America/Montreal, Jari Arkko wrote: > One technical thing that is not general is the retrieval > of cert chains for the peer. We've chosen to do this outside > AH for efficiency reasons (don't have to send it every time). > This means that we still expect AH_RSA_Sig to get the necessary > cert chains from ND. However, you could perhaps argue that > in a different application there'd be something else that is > feeding the same information to AH via an API. My personal view is that it is architecturally sensible to separate this function out from AH. Other folks mileage might vary. At one time there was a Sun proposal for an lightweight protocol to push/pull certificates around. This was run over UDP, if I recall, and was a nicely general way to move certificates around for a variety of uses/applications. So I think that a general solution to that issue is possible, if folks choose to adopt one. >>> - Need to rely on the existence of an API between the >>> IPsec and ND parts. And not just a simple configuration >>> API, but I fear that we may need a per-packet API. >> Those "parts" are normally (always ?) implemented as a >> single layer inside real-world IPv6 software, so an API >> is not normally needed between them. > > Well, an interface is probably internally needed in any case. Maybe. In a typical BSD stack, one might not need a formal interface. And since this is clearly an implementation detail, there would not be any need for IETF to define such an interface -- the implementer can sort this all out her/himself without any IETF help. > What about BITS implementations? IPv6 requires that there be an in-stack implementation of AH/ESP. BITS doesn't meet that requirement, so it is safe to assume that AH/ESP will really be there for hosts implementing IPv6 ND. In practice, Bump-in-the-Stack has a bunch of flaws for this scenario. One of those flaws is that BITS is logically a kind of outboard VPN crypto, not an integrated part of the host IP stack. To protect ND, one needs something that is logically part of the host itself -- not outboard from the host. >>> - Need to modify ND behaviour, since ND as-is uses addresses >>> in a way that isn't representable in the SPD easily. >> Again, we did not have to modify ND in 1995 to get AH to work >> with IPv6 ND. Now, ND has mutated a fair bit since 1995, but >> it still is not immediately obvious (to me) why such a modification >> to ND behaviour is really necessary today. > > Part of the reason for the need of the changes is probably > that we attempt to treat the authorization issues at a > demanding level. In particular, it is not sufficient for > us to use a good guys - bad guys separation. We are also > making sure that one of the good guys doesn't spoof another > good guy's addresses, for instance. We assumed that no one was trusted, so we actually worried not only about the above, but also about hosts impersonating a router, a router impersonating a host, and a pretty comprehensive range of other threats. To put the 1995 work in context, consider that we were working for the US Navy and we assumed that there existed multiple hostile and well-funded parties wanting to attack USN operational networks. (Our paranoia level was reasonably high. :-) > This translates into a need to worry about who is making > what changes to Neighbor Caches etc. As a result, we are > in some cases using a tentative address source rather than > the currently mandated unspecified address. A range of design approaches can work for the ND problem. The SEND WG has picked one. That one might or might not be the best one, but "best" is irrelevant as a metric since the IETF operates on WG rough consensus. >> My impression from your note and Pekka's notes is that you >> all have done a very thorough theoretical analysis, but >> that a number of the issues raised exist only in theory, >> but not really in practice in deployed software. > > Well, like I said the current documents are based on the > use of IPsec. I believe its implementable at least in > most cases, and may even have some aspects of the generality > that you wanted. That's not the question. I just believe it > would be easier in another way. I wonder if you'd reach different conclusions if you spent more time considering the source code of some actual existing IPv6, AH/ESP implementations. Maybe you would not, but I really wonder if it wouldn't change your perspective somewhat to have a better understanding of how these pieces are all actually implemented (e.g. in KAME). > I also look it from this > point: if we are not using SPDs like you suggest, if the > application is in direct control of AH packet processing, > if the current algorithms are not used, if the format for > the Authentication Data field looks very different from > current formats, if sequence number field is not used, > why are we reusing AH? I mean it has to be not just > possible, but also useful, right? The solution we reached in 1995 did not require any architectural changes to AH, bottomline. So I believe that at least one approach exists that doesn't require such changes. That does not mean that SEND has to use such an approach. It does make one wonder about claims that those changes are required in order to address authentication for IPv6 ND. So far, I'm not persuaded that any significant architectural change to AH is needed or especially useful here. However, the IETF operates on rough consensus, so my opinion is literally not important -- the rough consensus of the SEND WG is the only thing that really matters. Ran rja@extremenetworks.com From jari.arkko@piuha.net Thu Jun 12 13:11:06 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5CHB5NJ013216 for ; Thu, 12 Jun 2003 13:11:05 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) h5CHB4U8019863 for ; Thu, 12 Jun 2003 13:11:05 -0400 (EDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E4E476A907; Thu, 12 Jun 2003 20:11:02 +0300 (EEST) Message-ID: <3EE8B3C1.2070804@piuha.net> Date: Thu, 12 Jun 2003 20:09:21 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [saag] Time to reconsider the role of IPsec AH? References: <9813572E-9CE0-11D7-A5E6-00039357A82A@extremenetworks.com> In-Reply-To: <9813572E-9CE0-11D7-A5E6-00039357A82A@extremenetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 12 Jun 2003 17:11:06 -0000 RJ Atkinson wrote: > At one time there was a Sun proposal for an lightweight protocol > to push/pull certificates around. This was run over UDP, > if I recall, and was a nicely general way to move certificates > around for a variety of uses/applications. So I think that > a general solution to that issue is possible, if folks choose > to adopt one. Yes, our protocol is quite similar to that except that it runs on top of ICMP. It has both solicited and unsolicited mode, and it uses multicast to get the same chain to a number of receivers in the same go. > Maybe. In a typical BSD stack, one might not need a formal > interface. And since this is clearly an implementation detail, > there would not be any need for IETF to define such an interface > -- the implementer can sort this all out her/himself without > any IETF help. Yes, and generally IETF hasn't been that active on the API area anyway. Even if an interface is needed between different layers, it does not necessarily imply that such an interface has to be standardized. Of course, portability and so forth would be better with a standard interface. But I don't think that is an issue in this case. I wouldn't port, say, ND from one stack to another ;-) > We assumed that no one was trusted, so we actually worried > not only about the above, but also about hosts impersonating > a router, a router impersonating a host, and a pretty comprehensive > range of other threats. Yes, these threats were also considered by us. Perhaps the difference is then in the nature of the networks that we were thinking about? Our goal was public access networks where we couldn't know beforehand all the parties. Did you assume that as well, or fixed, known set of participants? > I wonder if you'd reach different conclusions if you spent > more time considering the source code of some actual existing > IPv6, AH/ESP implementations. Maybe you would not, but I > really wonder if it wouldn't change your perspective somewhat > to have a better understanding of how these pieces are all > actually implemented (e.g. in KAME). Perhaps, particularly a look at KAME might be useful. I really don't have any experience of that. But its not like I'd never seen that stuff... I have implemented IPsec myself, for instance. I think the same goes to the rest of our design team. Of course, I'm more or less the only one who thinks we should use "application" layer security, but at least the rest of the team felt that the extensions we did for IPsec were necessary. > That does not mean that SEND has to use such an approach. > It does make one wonder about claims that those changes > are required in order to address authentication for IPv6 ND. Well, I'm willing to learn new ways of doing it, if its written down somewhere, and documented how it addressed the various threats. It could well be that we have missed something. --Jari From rja@extremenetworks.com Thu Jun 12 13:59:23 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5CHxNNJ013838 for ; Thu, 12 Jun 2003 13:59:23 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) h5CHxL3f011209 for ; Thu, 12 Jun 2003 13:59:22 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 2A73467106; Thu, 12 Jun 2003 14:24:49 -0400 (EDT) Date: Thu, 12 Jun 2003 13:59:18 -0400 Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: jari.arkko@piuha.net From: RJ Atkinson In-Reply-To: <3EE8B3C1.2070804@piuha.net> Message-Id: <9681B1A0-9CFF-11D7-A5E6-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 12 Jun 2003 17:59:24 -0000 On Thursday, Jun 12, 2003, at 13:09 America/Montreal, Jari Arkko wrote: > Yes, our protocol is quite similar to that except that it > runs on top of ICMP. It has both solicited and unsolicited > mode, and it uses multicast to get the same chain to a number > of receivers in the same go. Sounds great. I don't recall that the previous proposal had that useful multicast feature, so this is probably better suited to SEND. :-) > Our goal was public access networks > where we couldn't know beforehand all the parties. Did you > assume that as well, or fixed, known set of participants? We assumed use over wireless links (e.g. HF radio) where an adversary would have direct access over the wire, so I suspect the assumptions were not very different from yours. No matter at this point what we did long ago, since our old implementation is very clearly dead at this point. The SEND WG's collective opinions are the opinions that matter now. > Perhaps, particularly a look at KAME might be useful. > I really don't have any experience of that. But its > not like I'd never seen that stuff... I have implemented > IPsec myself, for instance. I think the same goes to > the rest of our design team. Of course, I'm more or > less the only one who thinks we should use "application" > layer security, but at least the rest of the team felt > that the extensions we did for IPsec were necessary. Sounds like we just reached different conclusions from similar data. Not an unusual occurrence in IETF-land. :-) >> That does not mean that SEND has to use such an approach. >> It does make one wonder about claims that those changes >> are required in order to address authentication for IPv6 ND. > > Well, I'm willing to learn new ways of doing it, if its > written down somewhere, and documented how it addressed > the various threats. It could well be that we have missed > something. An excellent point and a very good reason to go forward with the current SEND approach. The old approach is not written down anyplace (or at least anyplace I'm likely to find in my basement anytime soon), while the SEND approach is clearly documented and has SEND WG consensus behind it. We all agree its important that WG consensus be the metric for moving forward. :-) Cheers, Ran rja@extremenetworks.com From rja@extremenetworks.com Thu Jun 12 15:01:55 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5CJ1sNJ014678 for ; Thu, 12 Jun 2003 15:01:54 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) h5CJ1o3f002759 for ; Thu, 12 Jun 2003 15:01:51 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 8976A67106 for ; Thu, 12 Jun 2003 15:27:20 -0400 (EDT) Date: Thu, 12 Jun 2003 15:01:50 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: RJ Atkinson To: saag@mit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <3EE8ADEC.7040002@piuha.net> Message-Id: <52CC8903-9D08-11D7-A5E6-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.552) Subject: [saag] Retraction Re: IPv6 BITS IPsec X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 12 Jun 2003 19:01:55 -0000 On Thursday, Jun 12, 2003, at 12:44 America/Montreal, Jari Arkko wrote: Earlier Ran wrote: >> IPv6 requires that there be an in-stack implementation of AH/ESP. >> BITS doesn't meet that requirement, so it is safe to assume that >> AH/ESP will really be there for hosts implementing IPv6 ND. > > Really? Where does it say so? If this really is a requirement > written down somewhere, I could use that as an argument in > a certain other issue. But I haven't seen this written down > myself. Could have missed something, though. Retraction: Jari is correct that this is not written down anyplace; I was at least out-of-date (and possibly confused in the first place). In the course of updating both the ESP/AH specs and the IPv6 specs, things seem to have changed somewhat, at least with regards to clarity of requirements. In skimming RFC-2401 and RFC-2460 just now, there is nothing obviously prohibiting BITS as a sufficient implementation approach for IPv6 hosts. RFC-1825 thru RFC-1827 have several requirements that are roughly impossible for a BITS implementation to meet (this was no accident). RFC-2401 specifically allows BITS and BITW implementations of IPsec. That noted, I'm not aware of any specific IPv6 host implementations of ESP/AH that are either BITS or BITW. There might well be some out there; the most common IPv6 implementation (KAME) is neither BITS nor BITW. My mistake. Terribly sorry, Ran From warlord@MIT.EDU Thu Jun 12 18:01:04 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5CM13NJ016932 for ; Thu, 12 Jun 2003 18:01:03 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72])h5CM0x4o005715; Thu, 12 Jun 2003 18:00:59 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86])h5CM0wON006142; Thu, 12 Jun 2003 18:00:59 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) h5CM0wU8007969; Thu, 12 Jun 2003 18:00:58 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id SAA27238; Thu, 12 Jun 2003 18:00:58 -0400 (EDT) To: Michael Richardson From: Derek Atkins Subject: Re: [saag] Time to reconsider the role of IPsec AH? References: <200306111704.h5BH4XFl007357@sandelman.ottawa.on.ca> Date: 12 Jun 2003 18:00:58 -0400 In-Reply-To: <200306111704.h5BH4XFl007357@sandelman.ottawa.on.ca> Message-ID: Lines: 64 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: saag@MIT.EDU X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 12 Jun 2003 22:01:05 -0000 Michael Richardson writes: > >>>>> "Derek" == Derek Atkins writes: > >> AH is the right answer for IP-layer authentication, as Pekka noted. > > Derek> Ok, _why_ is it "the right answer"? What particular features of AH, > Derek> that do NOT exist in ESP-NULL, make it "the right answer"? Or > Derek> vice-versa, what particular features of ESP-NULL make it "not the > Derek> right answer"? Please be specific. > > AH *guarantees* that the data that follows the packet are not encrypted. > As such, one can look at the things that follow, decide if they are even > interesting, and *only* then, calculate the authenticator. (Which might > involve doing RSA, finding the right public key, etc...) So? What does being unencrypted buy you? You shouldn't trust the packet unless you do verify the authenticator... If you don't follow that then I could easily feed you false packets that "look" right even if they don't authenticate properly./ > ESP does not make this guarantee. The recipient who assigned the SPI# > possibly look up the algorithm in the SPD and find out that it was NULL, > but nobody else can. (Nor can the recipient if they have rebooted since) Nobody else should... Nobody else should ever need to.. Nobody else can even verify that the packet is authentic, so they shouldn't trust it regardless. > So, AH is appropriate for securing things like ARP/ND, which are likely > to be broadcast/multicast. ESP-null can only be used between consenting > parties that know about each other already. Well, an intermediary cannot (indeed SHOULD not) be peering into a packet, even if it is known to be unencrypted. As I already said, one can certainly send a packet with an AH header that _looks_ correct but doesn't verify. An intermediary has no way to trust it is correct, so shouldn't even try. If you're using a broadcast/multicast, you should use GSAKMP for key agreement, or at least to publish the RSA key used to sign messages. > Now, to backtrack a bit - an RSA Transform for AH would like use a > well-known SPI#. That *could* be done for ESP-null, but I do not see the > advantage of doing so, if the things you wanted to authenticate were > extension headers. I'm not convinced that a well-known SPI would work well either. You're going to have to specify not only algorithm but also key information and traffic-selector information. So a single well-known spi wont work because there is no way to specify which keys/TSs are involved. That means you need to perform the SAD/SPD lookup on every packet anyways, so don't try to optimize around that. Similarly, you cannot optimize around the unencrypted nature of AH. As I mentioned, an intermediary cannot trust the packet regardless, and as I just showed the endpoint (recipient) still has to look up the SPI in the SAD. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From mouse@Sparkle.Rodents.Montreal.QC.CA Thu Jun 12 18:43:40 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5CMheNJ017394 for ; Thu, 12 Jun 2003 18:43:40 -0400 (EDT) Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7])h5CMhd4o016502 for ; Thu, 12 Jun 2003 18:43:39 -0400 (EDT) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id SAA27919; Thu, 12 Jun 2003 18:43:38 -0400 (EDT) From: der Mouse Message-Id: <200306122243.SAA27919@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Thu, 12 Jun 2003 18:21:45 -0400 (EDT) To: saag@mit.edu Subject: Re: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: References: <200306111704.h5BH4XFl007357@sandelman.ottawa.on.ca> X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 12 Jun 2003 22:43:41 -0000 > So? What does being unencrypted buy you? You shouldn't trust the > packet unless you do verify the authenticator... No, but in the presence of the right traffic statistics, it allows you to do a fast check and thereby identify some packets as being ones you don't care about the authenticator on, because their content indicates that they're either not what you're looking for or they're corrupted. If your traffic includes a significant proportion of packets with authentication info but which you don't care about, this can be a win. (As an example of a case where this can win: Suppose Alice has a connection with Bob which is protected with AH. Chris wants to DoS Alice but cannot sniff Alice<->Bob traffic. Chris sends Alice a flood of traffic with garbage AH headers. Alice could burn the cycles to check them all - but it's a lot cheaper for Alice to note that her only AH-protected connection is with Bob, so any packet not claiming to be from Bob doesn't even need to be checked. Even if Chris knows who Bob is, as long as Chris can't sniff Alice<->Bob traffic, the forged packets will probably have at least one port number wrong and thus can be discarded quickly. Even if Chris knows enough to know what range of ports is dynamically assigned by the relevant end, that's still at least a factor of a few hundred reduction in wasted work.) That is, it doesn't speed up processing of authenticated packets; it speeds up processing of unauthenticated packets. > Well, an intermediary cannot (indeed SHOULD not) be peering into a > packet, even if it is known to be unencrypted. As I already said, > one can certainly send a packet with an AH header that _looks_ > correct but doesn't verify. An intermediary has no way to trust it > is correct, so shouldn't even try. But if the action to be taken for a verified AH header equals the action to be taken for a forged packet, there's no reason not to. For example, a firewall that permits only TCP connections to port 22 doesn't need to authenticate packets not claiming to involve port 22; forged or not, the right thing to do is drop them. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From Michael.G.Williams@nokia.com Wed Jun 11 22:51:32 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5C2pWNJ004730 for ; Wed, 11 Jun 2003 22:51:32 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com ([63.78.179.217])h5C2pVbc008109 for ; Wed, 11 Jun 2003 22:51:32 -0400 (EDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])h5C2pUG04069 for ; Wed, 11 Jun 2003 21:51:30 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com ; Wed, 11 Jun 2003 21:51:39 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 11 Jun 2003 19:51:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [saag] Security Requirements Intnernet Draft (a request for comments)(F orwarded) Date: Wed, 11 Jun 2003 19:51:19 -0700 Message-ID: <59A36C4D2F9E7243BEB522274F72C303B0E09C@mvebe001.americas.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Security Requirements Intnernet Draft (a request for comments)(F orwarded) Thread-Index: AcMwgzIAePfQGOYvR/Czz+2WUuyB6QACJlpQ From: To: , X-OriginalArrivalTime: 12 Jun 2003 02:51:22.0747 (UTC) FILETIME=[82156CB0:01C3308D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id h5C2pWNJ004730 X-Mailman-Approved-At: Fri, 13 Jun 2003 17:25:18 -0400 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 12 Jun 2003 02:51:33 -0000 A general comment, and a tangent. This seems to be very "wired" centric and could use another pass with the wireless world kept in mind side by side with the wired. There seems to be a tremendous emphasis on security (in all walks of life). There is an opening up to acknowledge that some of the current solutions for security get in the way of others, or aren't aware of others. Idealists vs. pragmatists debate how high to raise the bar for the next "jump." There is a fair amount of idealism in this draft. Best Regards, Michael -----Original Message----- From: Steve Bellovin [mailto:smb@research.att.com] Sent: Wednesday, June 11, 2003 5:53 PM To: saag@mit.edu Subject: [saag] Security Requirements Intnernet Draft (a request for comments)(F orwarded) Comments welcome. ------- Forwarded Message Message-ID: <3EE7C8A6.8080706@mitre.org> Date: Wed, 11 Jun 2003 20:26:14 -0400 From: "George M. Jones" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nanog@merit.edu Subject: Security Requirements Intnernet Draft (a request for comments) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-nanog@merit.edu Precedence: bulk Errors-To: owner-nanog-outgoing@merit.edu X-Loop: nanog X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_MOZILLA_UA,X_LOOP autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) I've published an Internet Draft on "Security Requirements for Devices Implementing IP". You can view it at: http://www.ietf.org/internet-drafts/draft-jones-opsec-00.txt This is an outgrowth of a document used by UUNET (my former employer) to sanity check/security qualify equipment for connection to the backbone. The point of publishing the document is to start discussion. There is a mailing list set up: opsec@ops.ietf.org. Subscribe by sending a message to "majordomo@ops.ietf.org" with "subscribe opsec" in the body. The point of the document is to create a useful list that network operators can use to communicate their securtiy requirements to vendors. Please have a look and comment. Thanks, - ---George Jones ------- End of Forwarded Message --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) _______________________________________________ saag mailing list saag@mit.edu https://jis.mit.edu/mailman/listinfo/saag From pekka.nikander@nomadiclab.com Mon Jun 16 03:22:09 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5G7M8NJ000167 for ; Mon, 16 Jun 2003 03:22:09 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) h5G7M89X017693 for ; Mon, 16 Jun 2003 03:22:08 -0400 (EDT) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 8F06323; Mon, 16 Jun 2003 10:31:49 +0300 (EEST) Message-ID: <3EED7056.9000306@nomadiclab.com> Date: Mon, 16 Jun 2003 10:23:02 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Steve Bellovin cc: Russ Housley Subject: [saag] Summary: Time to reconsider AH.... X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 16 Jun 2003 07:22:10 -0000 About a week ago I posted a message on this list, proposing that the role of AH should be considered in the Internet architecture. This message is an attempt to summarise the discussion that followed. In this message, I am ignoring those parts of the discussion that do not relate directly to the topic of my original message. However, please correct me if I am missing something important. My original proposal was to reposition AH as an IP layer control protection protocol, and not so much as an end-to-end application protection protocol. The difference is subtle, but important, IMHO. Ran Atkinson pointed out that AH has been used as an IP layer control protection protocol, already as early as in 1995. Thus, my request to reposition might be, in fact, very much in line with the original design of AH. It looks like that Ran's and my opinion differ in one sense, however. Ran wants to preserve AH as an end-to-end application layer protection protocol, in addition to using it to protect IP layer control functions. I do understand that desire, but don't consider it very important. Much of the discussion attempted to clarify whether AH, as such, already fulfils the requirements that we have in mind. One aspect here was that I tend to see IPsec as a separate "layer" within the IP stack, while Ran strongly suggested that we must consider AH as a part of the same "layer" together with IP, ICMP, MIP, etc. One real difference here turned out to be between the original set of IPsec RFCs (RFC1825-1827) and the current set of RFCs (at least RFC2401 and RFC2460). In particular, the new set of RFCs allow a BITS or BITW implementation, with considerably less control over AH/ESP than in the original design. From our point of view, the technical problem here is the amount of control an IP layer control protocol can assume to have over AH. If we stick with the SPD approach, requiring that the AH "layer" makes separately the decision whether to protect a packet or not, or whether to allow an unprotected packet to pass to the upper layerers or not, there will be some trouble. The information available in the typical SPD selectors, especially in the incoming packet case, are just not enough. The current set of RFCs do not forbid a typical implementation from allowing more control over AH. However, since such control is not required from an implementation, it is hard to assume such a facility in any protocol relying on IPsec. After all this technical discussion, I tend to consider the attitude towards AH more important. If we collectively continue to mostly consider AH as an almost useless cripled down version of ESP, an overly complex end-to-end application protection protocol whose only benefit is lack of export restrictions, we are missing some points. What I propose is that we must better recognize the potential role AH has in protecting IP layer functions, such as ICMP, MIP, etc, and work towards realizing them in a scalable way. To me, it looks like such an approach requires a change in the attitude people have towards AH. Correspondingly, AH should be repositioned in the IETF work, and the WG structure should be updated accordingly. --Pekka Nikander From rja@extremenetworks.com Mon Jun 16 10:34:35 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5GEYZNJ004722 for ; Mon, 16 Jun 2003 10:34:35 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) h5GEYVbu016890 for ; Mon, 16 Jun 2003 10:34:32 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 8F97967105 for ; Mon, 16 Jun 2003 11:00:38 -0400 (EDT) Date: Mon, 16 Jun 2003 10:34:26 -0400 Subject: Re: [saag] Summary: Time to reconsider AH.... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: RJ Atkinson To: saag@mit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <3EED7056.9000306@nomadiclab.com> Message-Id: X-Mailer: Apple Mail (2.552) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 16 Jun 2003 14:34:36 -0000 On Monday, Jun 16, 2003, at 03:23 America/Montreal, Pekka Nikander wrote: > From our point of view, the technical problem here > is the amount of control an IP layer control protocol > can assume to have over AH. If we stick with the > SPD approach, requiring that the AH "layer" makes > separately the decision whether to protect a packet > or not, or whether to allow an unprotected packet > to pass to the upper layerers or not, there will > be some trouble. Merely having the SPD concept does NOT mean that "AH is a separate layer". The NRL AH/ESP implementation always had the equivalent of an SPD, but was totally integrated (layer-wise) with the rest of IP. The KAME implementation is similar to the NRL implementation in this architectural respect. A large percentage of current IPv6 implementations are KAME-based, perhaps over 50% of current implementations. So many/most existing IPv6 AH implementations do NOT have any of the hypothetical layer issues that Pekka perceives as problems. > The information available in > the typical SPD selectors, especially in the > incoming packet case, are just not enough. Adding more selectors ought to be easy and appears to be sufficient to address your concern. Ran Atkinson rja@extremenetworks.com From rja@extremenetworks.com Mon Jun 16 10:38:03 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5GEc3NJ004796 for ; Mon, 16 Jun 2003 10:38:03 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) h5GEc3bu018335 for ; Mon, 16 Jun 2003 10:38:03 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id B38CA67105 for ; Mon, 16 Jun 2003 11:04:13 -0400 (EDT) Date: Mon, 16 Jun 2003 10:38:01 -0400 Subject: Re: [saag] Summary: Time to reconsider AH.... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: RJ Atkinson To: saag@mit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <3EED7056.9000306@nomadiclab.com> Message-Id: <21C97DC6-A008-11D7-842C-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.552) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 16 Jun 2003 14:38:04 -0000 On Monday, Jun 16, 2003, at 03:23 America/Montreal, Pekka Nikander wrote: > After all this technical discussion, I tend to > consider the attitude towards AH more important. > If we collectively continue to mostly consider AH > as an almost useless cripled down version of ESP, > an overly complex end-to-end application protection > protocol whose only benefit is lack of export > restrictions, we are missing some points. Agree. Certainly I've never viewed AH as a crippled version of ESP. In fact, I would never willingly use ESP without also using AH on those sessions. > What I propose is that we must better recognize > the potential role AH has in protecting IP layer > functions, such as ICMP, MIP, etc, and work towards > realizing them in a scalable way. To me, it looks > like such an approach requires a change in the > attitude people have towards AH. Correspondingly, > AH should be repositioned in the IETF work, and > the WG structure should be updated accordingly. I'm unable to understand exactly what you are proposing in the above paragraph. Maybe it is just me, but I'm not sure what action/change you are requesting. :-) Ran Atkinson rja@extremenetworks.com PS: And I would not be upset with banning BITS/BITW implementations of ESP/AH for IPv6 hosts, either. No BITS/BITW implementation can have sufficient data to provide the same security properties as an integrated in-stack implementation -- which seems sufficient reason to discard BITS/BITW for IPv6 hosts. From kent@bbn.com Tue Jun 17 13:36:55 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5HHatNJ022519 for ; Tue, 17 Jun 2003 13:36:55 -0400 (EDT) Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) h5HHasUk017432 for ; Tue, 17 Jun 2003 13:36:54 -0400 (EDT) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5HHadDD010601; Tue, 17 Jun 2003 13:36:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20030610122035.4c98ac5b.moore@cs.utk.edu> References: <20030610122035.4c98ac5b.moore@cs.utk.edu> Date: Tue, 17 Jun 2003 13:37:09 -0400 To: Keith Moore From: Stephen Kent Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) cc: saag@mit.edu cc: Paul Hoffman / IMC X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 17 Jun 2003 17:36:56 -0000 At 12:20 PM -0400 6/10/03, Keith Moore wrote: > > There doesn't appear to have been any stifling of >> the use of IPsec by non-VPN applications, just not much WG support >> for it. I may have missed something. > >IPsec is pretty much useless to applications without > >a) the ability to authenticate applications and users, rather than hosts >b) an API that lets apps specify and obtain credentials > >as long as IPsec doesn't have those, apps will make do with TLS or >roll their own. >_______________________________________________ IPsec can authenticate a person, not just a device, so "a" above is not a valid criticism. It has been said many time previously, but it's still not correct :-) Steve From mcr@sandelman.ottawa.on.ca Tue Jun 17 15:40:28 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5HJeSNJ023981 for ; Tue, 17 Jun 2003 15:40:28 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78])h5HJeNf4013976 for ; Tue, 17 Jun 2003 15:40:27 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2])h5HJeKq17494 verified NO) for ; Tue, 17 Jun 2003 15:40:22 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20])h5HJfum06081 for ; Tue, 17 Jun 2003 15:41:56 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) h5HJe7XB011840 for ; Tue, 17 Jun 2003 15:40:08 -0400 Message-Id: <200306171940.h5HJe7XB011840@sandelman.ottawa.on.ca> To: saag@mit.edu Subject: Re: [saag] Time to reconsider the role of IPsec AH? In-reply-to: Your message of "Tue, 17 Jun 2003 13:37:09 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 17 Jun 2003 15:40:07 -0400 From: Michael Richardson X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 17 Jun 2003 19:40:28 -0000 Keith and others, >b) an API that lets apps specify and obtain credentials work is underway (finally!) in the IPSP WG on this. Expect drafts RSN. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From rgm-sec@htt-consult.com Tue Jun 17 16:44:59 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5HKixNJ024758 for ; Tue, 17 Jun 2003 16:44:59 -0400 (EDT) Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) h5HKiuks019839 for ; Tue, 17 Jun 2003 16:44:58 -0400 (EDT) Received: from port3490.htt-consult.com ([65.84.78.209]) by htt-consult.com ; Tue, 17 Jun 2003 16:44:57 -0400 Message-Id: <5.1.0.14.2.20030617163529.02d4fea8@localhost> X-Sender: rgm-sec@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 17 Jun 2003 16:43:27 -0400 To: saag@mit.edu From: Robert Moskowitz Subject: Re: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: References: <20030610122035.4c98ac5b.moore@cs.utk.edu> <20030610122035.4c98ac5b.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Rcpt-To: X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 17 Jun 2003 20:44:59 -0000 At 01:37 PM 6/17/2003 -0400, Stephen Kent wrote: >At 12:20 PM -0400 6/10/03, Keith Moore wrote: >> > There doesn't appear to have been any stifling of >>> the use of IPsec by non-VPN applications, just not much WG support >>> for it. I may have missed something. >> >>IPsec is pretty much useless to applications without >> >>a) the ability to authenticate applications and users, rather than hosts >>b) an API that lets apps specify and obtain credentials >> >>as long as IPsec doesn't have those, apps will make do with TLS or >>roll their own. >>_______________________________________________ > >IPsec can authenticate a person, not just a device, so "a" above is not a >valid criticism. It has been said many time previously, but it's still not >correct :-) This is a problem in implementation, not is the standard. Though tying IPsec to an app **IS** a problem and the reason why you see many in AAA perfering TLS to IPsec for Diameter's security. But ESP in transport mode, with IKE using 2 user certificates definitely ties to the user. And most client implementations support this to some extent. For an app, there is no API to use to query if there is an IPsec SA for the app. This is an API issue, not normally a selector issue. But given my current work in 802-land, this work to secure what are basically layer2 frames with layer3 security is, well, interesting. Of course in layer2-land we are discussing how to protect 'sub-MAC' (MAC management) frames!!! I suggest that people here look over in the 802.1 task group and the LinkSec study group. Robert Moskowitz TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com From pbaker@verisign.com Tue Jun 17 20:47:47 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5I0lhNJ026959 for ; Tue, 17 Jun 2003 20:47:43 -0400 (EDT) Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) h5I0lgmx008445 for ; Tue, 17 Jun 2003 20:47:42 -0400 (EDT) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h5I0lauv004843; Tue, 17 Jun 2003 17:47:40 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 17:47:36 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2248@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Robert Moskowitz'" , saag@mit.edu Subject: RE: [saag] Time to reconsider the role of IPsec AH? Date: Tue, 17 Jun 2003 17:47:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 00:47:48 -0000 > This is a problem in implementation, not is the standard. > Though tying > IPsec to an app **IS** a problem and the reason why you see > many in AAA > perfering TLS to IPsec for Diameter's security. On the contrary it is a basic limitation of the architecture. Security at the packet layer is not going to be accessible to the application for good reasons of structured layered architecture. Each layer in the stack should only be communicating to the layers immediately above and below it. Trying to wormhole information through the layers is not recommended. Phill From pekka.nikander@nomadiclab.com Wed Jun 18 04:00:39 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5I80cNJ002579 for ; Wed, 18 Jun 2003 04:00:39 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) h5I7uc2x000008 for ; Wed, 18 Jun 2003 03:56:38 -0400 (EDT) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 097AA1C; Wed, 18 Jun 2003 11:06:25 +0300 (EEST) Message-ID: <3EF01B73.3000706@nomadiclab.com> Date: Wed, 18 Jun 2003 10:57:39 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [saag] Summary: Time to reconsider AH.... References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 08:00:39 -0000 Ran, RJ Atkinson wrote: > So many/most existing IPv6 AH implementations > do NOT have any of the hypothetical layer issues > that Pekka perceives as problems. YMMV. I am working with KAME code myself. IMHO, in KAME the IPsec code is quite neatly separated into a "sublayer", or a subsystem with a fairly small interface with the rest of the IP stack. I think that it is a good design. Making the interface larger between the subsystems is not an easy decision; there must be a reason for adding such complexity. Now, I think that there is a reason for adding such complexity. Furthermore, I think that such reasons should be discussed within the IETF, and that such discussion most probably will result in slight changes into the current IPsec architecture document (RFC2401). > Adding more selectors ought to be easy and > appears to be sufficient to address your > concern. Adding more selectors does not seem to be easy, as you may have noticed from the on-going discussion at the IPsec WG. --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Jun 18 04:02:31 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5I82VNJ002612 for ; Wed, 18 Jun 2003 04:02:31 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) h5I82U2x000911 for ; Wed, 18 Jun 2003 04:02:30 -0400 (EDT) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 6F38C1C; Wed, 18 Jun 2003 11:12:17 +0300 (EEST) Message-ID: <3EF01CD3.9080708@nomadiclab.com> Date: Wed, 18 Jun 2003 11:03:31 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: RJ Atkinson Subject: Preliminary BOF proposal (was Re: [saag] Summary: Time to reconsider AH....) References: <21C97DC6-A008-11D7-842C-00039357A82A@extremenetworks.com> In-Reply-To: <21C97DC6-A008-11D7-842C-00039357A82A@extremenetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Steve Bellovin cc: Russ Housley cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 08:02:31 -0000 RJ Atkinson wrote: >> What I propose is that we must better recognize >> the potential role AH has in protecting IP layer >> functions, such as ICMP, MIP, etc, and work towards >> realizing them in a scalable way. To me, it looks >> like such an approach requires a change in the >> attitude people have towards AH. Correspondingly, >> AH should be repositioned in the IETF work, and >> the WG structure should be updated accordingly. > > I'm unable to understand exactly what you are proposing > in the above paragraph. Maybe it is just me, but > I'm not sure what action/change you are requesting. I think that we should have a BOF, and discuss the future of AH, among other things. People are hoping that IPsec will be finally closed. Maybe so, but I tend to doubt. Independent of that, I propose that all future work of AH would be moved to a separate, new WG. The BOF should be in the security area, and should focus on how to secure IP layer signalling protocols, including ICMP, IPv6 ND (part of ICMP), MIP, etc. I think that it would be possible to come up with a fairly unified solution for security all or at least most of these, using AH and recent ideas. However, much work needs to be done. I think that it would be beneficial to continue such work in a single security area WG instead of distributing it over several Internet area WGs. One of the purposes of this discussion has been to see if there is any support for having such a BOF. So far I haven't seen any real interest, but lots of discussion on related aspects, without any clear conclusions. --Pekka Nikander From rja@extremenetworks.com Wed Jun 18 07:52:14 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5IBqENJ004635 for ; Wed, 18 Jun 2003 07:52:14 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) h5IBqEcJ000872 for ; Wed, 18 Jun 2003 07:52:14 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 5F1B567103; Wed, 18 Jun 2003 08:17:51 -0400 (EDT) Date: Wed, 18 Jun 2003 07:52:10 -0400 Subject: Re: [saag] Summary: Time to reconsider AH.... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Pekka Nikander From: RJ Atkinson In-Reply-To: <3EF01B73.3000706@nomadiclab.com> Message-Id: <4B0260CE-A183-11D7-BF35-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 11:52:15 -0000 On Wednesday, Jun 18, 2003, at 03:57 America/Montreal, Pekka Nikander wrote: > YMMV. I am working with KAME code myself. IMHO, > in KAME the IPsec code is quite neatly separated > into a "sublayer", or a subsystem with a fairly > small interface with the rest of the IP stack. I would not agree with the notion that KAME's implementation is rigidly layered or makes it in any way difficult to use AH to protect ND. Clearly milage varies on this. I'd encourage folks to examine the code for themselves and draw their own conclusions, which ought to be straight forward since the code is freely distributed as source. Ran rja@extremenetworks.com From warlord@MIT.EDU Wed Jun 18 12:04:51 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5IG4pNJ007650 for ; Wed, 18 Jun 2003 12:04:51 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82])h5IG4jeI022508; Wed, 18 Jun 2003 12:04:47 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86])h5IG4eP4025540; Wed, 18 Jun 2003 12:04:40 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) h5IG4ZU8019598; Wed, 18 Jun 2003 12:04:39 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id MAA20252; Wed, 18 Jun 2003 12:04:35 -0400 (EDT) To: "Hallam-Baker, Phillip" From: Derek Atkins Subject: Re: [saag] Time to reconsider the role of IPsec AH? References: <2A1D4C86842EE14CA9BC80474919782E0D2248@mou1wnexm02.verisign.com> Date: 18 Jun 2003 12:04:35 -0400 In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2248@mou1wnexm02.verisign.com> Message-ID: Lines: 38 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: 'Robert Moskowitz' cc: saag@MIT.EDU X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 16:04:52 -0000 "Hallam-Baker, Phillip" writes: > > This is a problem in implementation, not is the standard. > > Though tying > > IPsec to an app **IS** a problem and the reason why you see > > many in AAA > > perfering TLS to IPsec for Diameter's security. > > On the contrary it is a basic limitation of the architecture. > > Security at the packet layer is not going to be accessible to > the application for good reasons of structured layered architecture. > > Each layer in the stack should only be communicating to the layers > immediately above and below it. Trying to wormhole information through > the layers is not recommended. Eh? This is what meta-data is for! Sure, each layer shouldn't pass it's transport data up/down the layers, however that doesn't imply that ancillary metadata cannot be stored alongside the packet. For example, an application at layer 7 can CERTAINLY get the IP Address (from layer 3)... How does this not violate your assertion? Similarly, if an app can obtain the layer-3 IP Address, why not also the "later 3.5" IPsec SA information? No, this is not an architectural problem; it is an implementation problem. Granted, it requires an integrated IPsec stack, but it's a perfectly reasonable goal and easily implementable using the current specifications. > Phill -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From warlord@MIT.EDU Wed Jun 18 12:17:44 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5IGHiNJ007838 for ; Wed, 18 Jun 2003 12:17:44 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72])h5IGHh9Z000616; Wed, 18 Jun 2003 12:17:43 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86])h5IGHhBb005705; Wed, 18 Jun 2003 12:17:43 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) h5IGHgU8023144; Wed, 18 Jun 2003 12:17:42 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id MAA20280; Wed, 18 Jun 2003 12:17:42 -0400 (EDT) To: der Mouse From: Derek Atkins Subject: Re: [saag] Time to reconsider the role of IPsec AH? References: <200306111704.h5BH4XFl007357@sandelman.ottawa.on.ca> <200306122243.SAA27919@Sparkle.Rodents.Montreal.QC.CA> Date: 18 Jun 2003 12:17:42 -0400 In-Reply-To: <200306122243.SAA27919@Sparkle.Rodents.Montreal.QC.CA> Message-ID: Lines: 79 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: saag@MIT.EDU X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 16:17:45 -0000 If you make the assumption that Chris cannot sniff the Alice<->Bob link, then the liklihood that Chris will choose a valid SPI to spoof Alice<->Bob is approximately 1 in 2^-24 (I'm assuming that Chris knows that Alice and Bob are using SPI values >= 256). This means that if Alice is _just_ looking for valid SPI values, Chris will only get Alice to accept one in 16 million packets. That's doing pretty well just by checking the SPI value. Note that we haven't even verified the IP Address or performed ANY cryptographic verification yet. So, I think any argument that you need to look into the packet to verify it's authenticity is fallacious. You don't need to look at the transport headers to see if they are valid, you can start with the SPI. As Alice<->Bob will be changing SPIs periodically (every rekey), if Chris cannot see the traffic she cannot find the proper SPI. So again I ask you, what does being unencrypted buy you? Based on your assumption about Chris' abilities, and that Alice is only talking to Bob, Alice can throw out 99.99999% of Chris' packets just by looking at the SPI... So, why does Alice need to look inside the packet? -derek der Mouse writes: > > So? What does being unencrypted buy you? You shouldn't trust the > > packet unless you do verify the authenticator... > > No, but in the presence of the right traffic statistics, it allows you > to do a fast check and thereby identify some packets as being ones you > don't care about the authenticator on, because their content indicates > that they're either not what you're looking for or they're corrupted. > > If your traffic includes a significant proportion of packets with > authentication info but which you don't care about, this can be a win. > (As an example of a case where this can win: Suppose Alice has a > connection with Bob which is protected with AH. Chris wants to DoS > Alice but cannot sniff Alice<->Bob traffic. Chris sends Alice a flood > of traffic with garbage AH headers. Alice could burn the cycles to > check them all - but it's a lot cheaper for Alice to note that her only > AH-protected connection is with Bob, so any packet not claiming to be > from Bob doesn't even need to be checked. Even if Chris knows who Bob > is, as long as Chris can't sniff Alice<->Bob traffic, the forged > packets will probably have at least one port number wrong and thus can > be discarded quickly. Even if Chris knows enough to know what range of > ports is dynamically assigned by the relevant end, that's still at > least a factor of a few hundred reduction in wasted work.) > > That is, it doesn't speed up processing of authenticated packets; it > speeds up processing of unauthenticated packets. > > > Well, an intermediary cannot (indeed SHOULD not) be peering into a > > packet, even if it is known to be unencrypted. As I already said, > > one can certainly send a packet with an AH header that _looks_ > > correct but doesn't verify. An intermediary has no way to trust it > > is correct, so shouldn't even try. > > But if the action to be taken for a verified AH header equals the > action to be taken for a forged packet, there's no reason not to. For > example, a firewall that permits only TCP connections to port 22 > doesn't need to authenticate packets not claiming to involve port 22; > forged or not, the right thing to do is drop them. > > /~\ The ASCII der Mouse > \ / Ribbon Campaign > X Against HTML mouse@rodents.montreal.qc.ca > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From moore@cs.utk.edu Wed Jun 18 13:27:44 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5IHRiNJ008811 for ; Wed, 18 Jun 2003 13:27:44 -0400 (EDT) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62])h5IHRh9Z028505 for ; Wed, 18 Jun 2003 13:27:43 -0400 (EDT) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19Sgif-0000Jr-00; Wed, 18 Jun 2003 10:27:38 -0700 Date: Wed, 18 Jun 2003 13:24:45 -0400 From: Keith Moore To: "Hallam-Baker, Phillip" Subject: Re: [saag] Time to reconsider the role of IPsec AH? Message-Id: <20030618132445.0c0e4e84.moore@cs.utk.edu> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2248@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D2248@mou1wnexm02.verisign.com> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: rgm-sec@htt-consult.com cc: moore@cs.utk.edu cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 17:27:45 -0000 On Tue, 17 Jun 2003 17:47:28 -0700 "Hallam-Baker, Phillip" wrote: > Each layer in the stack should only be communicating to the layers > immediately above and below it. I don't know who came up with that idea, but it's not grounded in sanity. There needs to be clear separation of function between layers. That doesn't mean that layers should only communicate with immediately higher or lower layers. Indeed, if layer 7 needs to specify some layer 3 functionality, it makes a lot more sense for the layers to communicate directly than for each layer to have to tunnel the requests, or for layer 3 to have to guess what layer 7 needs. From mouse@Sparkle.Rodents.Montreal.QC.CA Wed Jun 18 16:30:24 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5IKUONJ010822 for ; Wed, 18 Jun 2003 16:30:24 -0400 (EDT) Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7])h5IKULMp022248 for ; Wed, 18 Jun 2003 16:30:21 -0400 (EDT) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id QAA12143; Wed, 18 Jun 2003 16:30:18 -0400 (EDT) From: der Mouse Message-Id: <200306182030.QAA12143@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Wed, 18 Jun 2003 16:26:40 -0400 (EDT) To: saag@MIT.EDU Subject: Re: [saag] Time to reconsider the role of IPsec AH? In-Reply-To: References: <200306111704.h5BH4XFl007357@sandelman.ottawa.on.ca> <200306122243.SAA27919@Sparkle.Rodents.Montreal.QC.CA> X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 20:30:25 -0000 > [...choosing SPI values...] > So again I ask you, what does being unencrypted buy you? Hmm. All I can think of then are debuggability and legality. There are places where encryption is illegal (last I heard, at least) and thus ESP cannot be used for legal reasons. (I can easily imagine similar restrictions being placed administratively in places like companies, so that corporate security can sniff traffic.) And debugging networking problems is a lot easier when you can actually see what's on the wire. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From kent@bbn.com Wed Jun 25 18:39:42 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h5PMdfXn005856 for ; Wed, 25 Jun 2003 18:39:41 -0400 (EDT) Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) h5PMdUXL017388 for ; Wed, 25 Jun 2003 18:39:40 -0400 (EDT) Received: from [10.1.71.211] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5PMc4DT011829; Wed, 25 Jun 2003 18:39:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <3EF01CD3.9080708@nomadiclab.com> References: <21C97DC6-A008-11D7-842C-00039357A82A@extremenetworks.com> <3EF01CD3.9080708@nomadiclab.com> Date: Wed, 25 Jun 2003 14:25:30 -0400 To: Pekka Nikander , RJ Atkinson From: Stephen Kent Subject: Re: Preliminary BOF proposal (was Re: [saag] Summary: Time to reconsider AH....) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 25 Jun 2003 22:39:43 -0000 At 11:03 AM +0300 6/18/03, Pekka Nikander wrote: >RJ Atkinson wrote: >>>What I propose is that we must better recognize >>>the potential role AH has in protecting IP layer >>>functions, such as ICMP, MIP, etc, and work towards >>>realizing them in a scalable way. To me, it looks >>>like such an approach requires a change in the >>>attitude people have towards AH. Correspondingly, >>>AH should be repositioned in the IETF work, and >>>the WG structure should be updated accordingly. >> >>I'm unable to understand exactly what you are proposing >>in the above paragraph. Maybe it is just me, but >>I'm not sure what action/change you are requesting. > >I think that we should have a BOF, and discuss the future >of AH, among other things. People are hoping that IPsec >will be finally closed. Maybe so, but I tend to doubt. >Independent of that, I propose that all future work of >AH would be moved to a separate, new WG. > >The BOF should be in the security area, and should focus >on how to secure IP layer signalling protocols, including >ICMP, IPv6 ND (part of ICMP), MIP, etc. I think that >it would be possible to come up with a fairly unified >solution for security all or at least most of these, >using AH and recent ideas. However, much work needs to >be done. I think that it would be beneficial to continue >such work in a single security area WG instead of distributing >it over several Internet area WGs. > >One of the purposes of this discussion has been to see >if there is any support for having such a BOF. So far >I haven't seen any real interest, but lots of discussion >on related aspects, without any clear conclusions. > i think it would be a god idea to have a BOF on the topic of securing IP layer, inbadn signalling. I think it would not be a good idea to refer to this as a "future of AH" BOF. Steve From kent@bbn.com Thu Jul 3 09:21:44 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h63DLiXn000085 for ; Thu, 3 Jul 2003 09:21:44 -0400 (EDT) Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) h63DLc9N008128 for ; Thu, 3 Jul 2003 09:21:43 -0400 (EDT) Received: from [128.89.89.40] (dhcp89-089-040.bbn.com [128.89.89.40]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h63DLTD9002267; Thu, 3 Jul 2003 09:21:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3EE59545.3040106@nomadiclab.com> References: <3EE59545.3040106@nomadiclab.com> Date: Thu, 3 Jul 2003 09:21:10 -0400 To: Pekka Nikander From: Stephen Kent Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) cc: "Steven M. Bellovin" cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 03 Jul 2003 13:21:45 -0000 I was away on vacation when you initiated this thread, and have not had a chance to formulate a response until the relative quite of this pre-holiday time here in the US. Although the discussion stopped over 2 weeks ago, having reviewed all of the messages on this thread, I feel it is still worthwhile to comment on some of the comments made by you and by Ran, to help clarify what I see as the issues surrounding IPsec in general, and AH specifically. >Folks, > >Based on our experiences with IPsec in Mobile IP, SEND, >and some other working groups, I am seriously starting >to think that it might be a good time to reconsider to >role of AH in the Internet architecture. For example, >in the SEND (Securing Neighbor Discovery) WG, which I >am co-chairing with James Kempf, we have been >attempting to use IPsec AH to secure IPv6 Neighbor >Discovery messages in a public access network setting. >The approach is based on public keys, as suggested by >Steven Bellovin in his presentation at the SEND BoF in >Yokohama. This work has certainly progressed, but the >road has been fairly bumby due to the current practice >on how IPsec has been implemented in most IP stacks. > >In general, it looks like the IPsec working group has >mostly concentrated on perfecting ESP and IKE/IKEv2, >and mostly for VPN use. The goal seem to have been >securing *applications* end-to-end, and making IPsec >as transparent to the applications as possible. VPNs certainly are an important focus of the IPsec WG, and bpth you and Ran have touched on the question of whether VPNs have become the sole focus of IPsec. In practice, VPNs are the primary use to which IPsec has been put. This is not a side effect of the involvement of VPN product vendors in the WG, but rather a natural evolution of security technology use, and a realization of the real world problems associated with management of security technology. Let me explain. Most security technology has been deployed at the perimeter of networks, rather than on individual end systems. This is motivated both by the "keep the evil packets out" model of security, and by the realization that network admins have a very hard time tracking, much less controlling, the software on desktop computers. Thus it is not surprising that IPsec, which can be deployed in intermediate systems as well as in end systems, has been deployed at the perimeter more than in end systems. Such deployment is also motivated by the desire to support intranets constructed over the public Internet, a largely economic motivation. Remote access over the public Internet also has been a prime motivator for IPsec deployment, and this involves both end system and intermediate system deployment. Here too, economics are a prime driver for the choice of deployment strategies. Thus, I thin it fair to say that IPsec has focused extensively on mode of use that are supportive of VPNs, because that is what users need and want now, not just because VPN vendors have participated in the WG. >The needs towards IPsec in Mobile IP, SEND, and other >IP layer control protocols seem to be very different. >In these protocols, there is no "application" in the >traditional sense. Instead, the protocols create >state at the IP layer, thereby affecting the overall >operations of all applications. Furthermore, if an >attacker can illegitly create such state, the effects >can be devastating to the whole Internet, resulting in >hijacked connections, untraceable denial-of-service >attacks, mysteriously disconnected sessions, black >holes, or other large scale malfunctions or security >breaches. I have been working on security for BGP for several years, and for that problem the words you use are appropriate, i.e., the effects of security lapses can have very widespread effects. But for SEND it is not clear that the scope of security failures would be so widespread, unless we assume that everyone will be using this particular technology. Nonetheless, I agree that the proposed use of AH to secure signaling IS fundamentally different fro either the VPN mode of use OR the original end-to-end mode. To me, this suggests that it is inappropriate to try to use AH for this purpose. >In some sense, the IP layer control protocols and their >security needs resemble routing protocols. However, >they are very different from the trust model point of >view. Routing protocols usually exchange routing >information between peering routers that have some >level of trust. On the other hand, the IP layer >control protocols often need to exchange IP layer state >related information between peers that have no or only >minimal trust. For example, in Mobile IP route >optimization the mobile node and the corresponding node >may have never communicated with each other before, and >they may have no shared trust-root. Similarily, nodes >running in an ad hoc network may have never met other >nodes that they need to perform Neighbor Discovery >with. We very much disagree here! The fundamental problem we have with current routing protocols like BGP is precisely the notion of trusting peers, something you suggest above is appropriate behavior. Trust has no place in solution to these problems, We have extant, authoritative organizations that are responsible for identifying who has the right to use different portions of (public) IP address space and we should plan to take advantage of this authoritative infrastructure to solve routing security and the neighbor discovery problem. Any solution based on trust will; be vulnerable to a variety of failures or the sort that plague us today. >Now, in the IPsec working group there seems to be a >fairly large faction of people that want to kill AH. >To them, AH seems like a completely useless feature. >If I took a very limited VPN point-of-view, I most >probably would agree with them. One can even argue >that AH, in general, is not suitable for protecting >end-to-end application level traffic, since ESP >integrity protection makes it better and without less >problems with IP headers being modified on the way. I assume you meant to say "with fewer problems" not "without less problems." But the point is that AH is rarely preferable to integrity-only ESP for VPN OR end-to-end security. What you have is an end-to-next-hop security problem which is very hard to solve, and for which I think AH is ill-suited. Thus has lead you to try to redefine it. >As I argued above, the situation is different with IP >level control protocols. There the extension headers, >and often the actual IP header, do carry information >whose integrity is essential. Furthermore, the result >of the integrity check is not necessarily a usual >black/white result, but it may be necessary to pass >additional information to the upper layer protocol, >i.e., ICMP, Mobile IP, etc. The same applies to the >packets sent out: it is sometimes necessary that the >upper layer protocol is able to instruct the IP layer >how exactly to protect the packet. The current IPsec >policy mechanisms are too inflexible to properly fulfil >these needs. Integrity checks give back yes/no answers, period. So we seem to have a serious technical disconnect here. IPsec, through the SPD, allows for changes in the controls that specify how different traffic flows are to be treated. A compliant IPsec implementation MUST provide a management interface that permits control over traffic disposition in a fashion consistent with the SPD. Most vendors choose to provide this management interface via a separate path that is not very dynamic, but as others have noted, an API for controlling the SPD is not precluded/ Again, I get the sense from some of the comments that there is a misunderstanding about the role of the SPD. It is a central feature of IPsec, because IPsec is NOT a crypto protocol, but rather a security protocol, and access control is at the heart of what most IPsec users really need and want. >Thus, I would propose that we should start to seriously >reconsider the role of AH. In fact, I propose that we >should effectively re-charter AH to be a security protocol >for IP layer control functions only, and start working an >in-stack API that AH would provide to the IP layer control >protocols. Why do you feel the need to appropriate the AH name to solve a separate security problem? >I think that if such an idea sounds good, we should >have a new working group for that. The attitude in the >IPsec working group seems to be either negative or >oblivious towards AH. Thus, it might make sense to >move all AH related work the new working group, if one >is formed. I think it would be appropriate to create a WG to define a suitable protocol to solve your problem, but I would guess that SEND could be authorized to do that. Your co-chair now seems to agree that this would be a preferable path as well Steve From kent@bbn.com Thu Jul 3 09:26:28 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h63DQSXn000188 for ; Thu, 3 Jul 2003 09:26:28 -0400 (EDT) Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) h63DQRXq025838 for ; Thu, 3 Jul 2003 09:26:27 -0400 (EDT) Received: from [128.89.89.40] (dhcp89-089-040.bbn.com [128.89.89.40]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h63DQQD9002593; Thu, 3 Jul 2003 09:26:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <28C99EBE-9B4B-11D7-9D51-00039357A82A@extremenetworks.com> References: <28C99EBE-9B4B-11D7-9D51-00039357A82A@extremenetworks.com> Date: Thu, 3 Jul 2003 09:25:16 -0400 To: RJ Atkinson From: Stephen Kent Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) cc: saag@mit.edu cc: Pekka Nikander X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 03 Jul 2003 13:26:29 -0000 Ran, >Pekka, > > Thanks for your note. > > A very long standing problem with the IPsec WG membership >is that it ended up (circa 1997) self-selecting for "VPN product >vendors", whereas it started out with a much more general goal. I think my comment to Pekka address this issue. I see the VPN vendor participation as an effect, not a cause, related to underlying customer needs. > The original design intent for both AH and ESP was to provide >end-to-end security for co-operating hosts. Because it was trivial >(both in spec and in running code) to add support for a tunnel-mode >that would enable VPN applications, this was done quite early on >(well before RFC-1825 -- RFC-1827 were published). Since you were the initial author for ESP and AH, I cannot dispute you characterization of intent. But in the intervening 5+ years, the IPsec WG and the user community have come to see tunnel mode as a critical feature of IPsec, necessary for the ways in which users want to deploy IPsec. > It is correct that the current VPN-oriented membership of the IPsec WG >is pretty openly hostile to AH -- mainly because AH is not a VPN-oriented >protocol. There have also been some (incorrect) gripes that AH cannot be >performed at high-speed because of its header design. However I know of >ASICs that can perform AH (with key-agility for many streams >concurrently) at multiple Gbps, so that claim has proved ill-founded. >It would seem quite reasonable to me to make clear that a VPN product >need not implement AH as part of its VPN service offering [1]. In >the mid-90s there was still an IETF concept of a "mandatory standard", >whereas now all IETF standards are considered "elective" (as near >as I can tell from the sidelines). Yes, Moore's law has made it feasible to implement AH at ever higher speeds. But, fundamentally, ESP in integrity-only ode will always be easier to implement at high speeds. > A number of applications (e.g. routing protocols, such as PIM >and OSPFv3; IGMP, and ICMP) currently benefit from use of AH. In practice, >the US Government (and some other governments) have been known to deny >general export of authentication-only-ESP. All export applications >for AH have been granted. So in practical terms, an authentication >approach based on AH is much more likely to be globally deployable >than one based on authentication-only-ESP. Beyond that, AH provides >different security properties than ESP.[2] However, I would not want >to lose the ability to protect my user traffic with AH-only or with a >combined AH+ESP if I wished to do so (and my end-system supported that, >which mine currently does). I am unfamiliar with the cases that you cite re denial of export license for integrity-only ESP. Can you provide specific examples that show that it was this aspect of the product that caused the refusal to grant a license? > As Mike StJohns can confirm, NRL demonstrated the use of AH to protect >IPv6 ICMP, including ND, in August 1995. The demo included secure >bootstrapping on a LAN. AH is particularly well-suited to that application, >not coincidentally since ESP/AH were originally undertaken within the >then-SIP (later IPng) WG. > > I think it might well make sense to move work on AH outside of the >IPsec WG. For that matter, I have for many years advocated that key >management (e.g. IKE, ISAKMP, and successors) be undertaken in a separate >WG; I still believe that would be helpful. We do have examples of using AH in mobile IP that do not break the model the way the SEND work does. That suggest to me that SEND probably has different requirements and thus might best be served by a different protocol. Steve From kent@bbn.com Thu Jul 3 09:31:41 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h63DVfXn000354 for ; Thu, 3 Jul 2003 09:31:41 -0400 (EDT) Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) h63DVeXq027560 for ; Thu, 3 Jul 2003 09:31:40 -0400 (EDT) Received: from [128.89.89.40] (dhcp89-089-040.bbn.com [128.89.89.40]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h63DVdD9002944; Thu, 3 Jul 2003 09:31:39 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3EE7727B.8090407@nomadiclab.com> References: <3EE62A01.7020900@nomadiclab.com> <3EE7727B.8090407@nomadiclab.com> Date: Thu, 3 Jul 2003 09:29:20 -0400 To: Pekka Nikander From: Stephen Kent Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) cc: RJ Atkinson cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 03 Jul 2003 13:31:41 -0000 Pekka, >RJ Atkinson wrote: >>>What specific changes are you proposing ? >>> >>>AH was already designed to protect the IP header and IP-layer >>>extension headers, so the change to the bits-on-the-wire that you >>>are contemplating is not obvious to me from the above description. > >I wrote: >>As I wrote, it may be that after all there would be no >>bits-on-the-wire modifications. ... Anyway, most of the issues >>relate to implementations, and to what one can reasonably expect from >>an implementation when designing new protocols or new security >>solutions for existing protocols. >> >>What comes to the the details of this, let me return to the issue >>tomorrow. > >From my point of view, the big issue here is authorization. >AH, as deployed today, protects the integrity and authenticity >of the packet. That is, at AH layer it is known who sent the >message and that the message was not modified while in transit. >However, in many implementations this information is not >available to the upper layers. The source IP address can act >as a hint, but it is not an ideal identifier. Depending on the context of an implementation, the receiver may have secure access to a symbolic name for the peer, not just the IP address. The SPD provides means for this to be represented, and in host implementations it is certainly possible to manage the SPD in those terms, via a TLI. >One issue here is, of course, what I mean with authorization. >Let me take a couple of examples. In SEND, the question to >answer is to say who is authorized to say which MAC address to >use when sending unicast messages to a given IP address. That >is, the authority over creating > > IPv6 address -> MAC address > >bindings. Respectively, in Mobile IP the question is about >the right to create > > IP address -> IP address > >bindings. > >In both of these cases, therefore, the question is on who >is authorized to create state wrt. a given IP address, but >the exact nature of the state is different. In other cases, >the state and the right to create state could be different. Both of these questions have to do with who has the right to use the IP addresses in question. IPsec does not address that issue, and since you note that SEND is trying to do address this first concern, this too should be a hint that IPsec is NOT the right protocol for the job! >One could argue that AH should completely perform the >required authorization check and only pass authorized >packets to the upper layer. However, that turns out to >pretty hard, resulting in duplicating or moving some >application specific code to AH. So, what should we infer from this ...? Steve From kent@bbn.com Thu Jul 3 09:34:27 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h63DYRXn000415 for ; Thu, 3 Jul 2003 09:34:27 -0400 (EDT) Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) h63DYRXq028387 for ; Thu, 3 Jul 2003 09:34:27 -0400 (EDT) Received: from [128.89.89.40] (dhcp89-089-040.bbn.com [128.89.89.40]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h63DYPD9003087; Thu, 3 Jul 2003 09:34:25 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 3 Jul 2003 09:34:04 -0400 To: RJ Atkinson From: Stephen Kent Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) cc: saag@mit.edu cc: jari.arkko@piuha.net X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 03 Jul 2003 13:34:28 -0000 Ran, >On Wednesday, Jun 11, 2003, at 18:54 America/Montreal, Jari Arkko wrote: >>I'm happy to hear that there's more work on the APIs >>than I realized before. > >As I noted in a note earlier today, the actual implementation >of ND inside a single layer, along with IPv6, AH, and ESP, >means that APIs are not generally a proximal issue for >the use of either AH/ESP with IPv6 ND. > >>Say, how good match are SPD mechanisms for problems like >>SEND? > >RFC-1825 through RFC-1827 don't mention "SPD" at all. No, but these documents were superceded by RFCs 2401, 2402, & 2406. >SPDs are a useful conceptual construct to clarify aspects >of AH/ESP. My understanding has been that the SPD was >not intended to be restrictive so much as descriptive, >maybe I've misread the current drafts for AH/ESP. In >any event, adding selectors to the current draft ought >not be difficult if folks felt it were useful/needed. The SPD defines a minimal, required management capability for access control (and other security management facilities) in a compliant IPsec implementation. We are in the process of adding new selector types to 2401bis, but we must do so carefully, since each new type represents a burden on implementations, especially hardware implementations operating at high speeds. Steve From carl.m.ellison@intel.com Thu Jul 3 11:58:02 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h63Fw2Xn004509 for ; Thu, 3 Jul 2003 11:58:02 -0400 (EDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) h63Fw1mK021805 for ; Thu, 3 Jul 2003 11:58:02 -0400 (EDT) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) 21:17:36 rfjohns1 Exp $) with ESMTP id h63Fr7b26420 for ; Thu, 3 Jul 2003 15:53:07 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h63Fp1p19368 for ; Thu, 3 Jul 2003 15:51:01 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) M2003070308575703037 ; Thu, 03 Jul 2003 08:57:57 -0700 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Jul 2003 08:57:58 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: IPsec as VPN-friendly (was RE: [saag] Time to reconsider the role of IPsec AH?) Date: Thu, 3 Jul 2003 08:57:57 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPsec as VPN-friendly (was RE: [saag] Time to reconsider the role of IPsec AH?) Thread-Index: AcMvWKfW3v4wqmcvRFmJTzF0V8mRFgSIm1hg From: "Ellison, Carl M" To: "RJ Atkinson" , "Pekka Nikander" X-OriginalArrivalTime: 03 Jul 2003 15:57:58.0429 (UTC) FILETIME=[DF93BCD0:01C3417B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id h63Fw2Xn004509 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 03 Jul 2003 15:58:03 -0000 Odd, isn't it, that a simple setup like mine at home (2 layers of firewall, each doing NAT) should interfere with IPsec VPNs (I'm told). [My VPN doesn't use IPsec, so I'm OK getting through these, but I have been discouraged from using an IPsec VPN by claims that it won't work.] If IPsec WG was run by VPN product vendors, how did this situation happen, or have I been misled by scare-stories? - Carl +--------------------------------------------------------+ |Carl Ellison Intel R & D E: cme@jf.intel.com | |2111 NE 25th Ave T: +1-503-264-2900 | |Hillsboro OR 97124 F: +1-503-264-3375 | |PGP Key ID: 0xFE5AF240 | | 1FDB 2770 08D7 8540 E157 AAB4 CC6A 0466 FE5A F240 | +--------------------------------------------------------+ >-----Original Message----- >From: RJ Atkinson [mailto:rja@extremenetworks.com] >Sent: Tuesday, June 10, 2003 6:55 AM >To: Pekka Nikander >Cc: saag@mit.edu >Subject: Re: [saag] Time to reconsider the role of IPsec AH? > > > >Pekka, > > Thanks for your note. > > A very long standing problem with the IPsec WG membership >is that it ended up (circa 1997) self-selecting for "VPN product >vendors", whereas it started out with a much more general goal. From warlord@MIT.EDU Fri Jul 4 10:11:16 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h64EBGXn001949 for ; Fri, 4 Jul 2003 10:11:16 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82])h64EBDSv004566; Fri, 4 Jul 2003 10:11:13 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71])h64EBC2e009246; Fri, 4 Jul 2003 10:11:12 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) h64EBBFJ026955; Fri, 4 Jul 2003 10:11:12 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h64EBBFV003937; Fri, 4 Jul 2003 10:11:11 -0400 (EDT) To: "Ellison, Carl M" Subject: Re: IPsec as VPN-friendly (was RE: [saag] Time to reconsider the role of IPsec AH?) References: From: Derek Atkins Date: 04 Jul 2003 10:11:11 -0400 In-Reply-To: Message-ID: Lines: 52 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: Pekka Nikander cc: RJ Atkinson cc: saag@MIT.EDU X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 04 Jul 2003 14:11:17 -0000 NATs sort of crept into the world "under the radar" during the original IPsec work.. Current IPsec drafts contain NAT Traversal support. -derek "Ellison, Carl M" writes: > Odd, isn't it, that a simple setup like mine at home (2 layers of > firewall, each doing NAT) should interfere with IPsec VPNs (I'm told). > [My VPN doesn't use IPsec, so I'm OK getting through these, but I have > been discouraged from using an IPsec VPN by claims that it won't work.] > If IPsec WG was run by VPN product vendors, how did this situation > happen, or have I been misled by scare-stories? > > - Carl > > +--------------------------------------------------------+ > |Carl Ellison Intel R & D E: cme@jf.intel.com | > |2111 NE 25th Ave T: +1-503-264-2900 | > |Hillsboro OR 97124 F: +1-503-264-3375 | > |PGP Key ID: 0xFE5AF240 | > | 1FDB 2770 08D7 8540 E157 AAB4 CC6A 0466 FE5A F240 | > +--------------------------------------------------------+ > > >-----Original Message----- > >From: RJ Atkinson [mailto:rja@extremenetworks.com] > >Sent: Tuesday, June 10, 2003 6:55 AM > >To: Pekka Nikander > >Cc: saag@mit.edu > >Subject: Re: [saag] Time to reconsider the role of IPsec AH? > > > > > > > >Pekka, > > > > Thanks for your note. > > > > A very long standing problem with the IPsec WG membership > >is that it ended up (circa 1997) self-selecting for "VPN product > >vendors", whereas it started out with a much more general goal. > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From rja@extremenetworks.com Mon Jul 7 14:23:09 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h67IN4Xn015684 for ; Mon, 7 Jul 2003 14:23:09 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) h67IN34c016052 for ; Mon, 7 Jul 2003 14:23:03 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.105]) by gnat.inet.org (Postfix) with ESMTP id C244867106; Mon, 7 Jul 2003 14:49:26 -0400 (EDT) Date: Mon, 7 Jul 2003 14:22:59 -0400 Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Stephen Kent From: RJ Atkinson In-Reply-To: Message-Id: <09CCD218-B0A8-11D7-9E7F-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 07 Jul 2003 18:23:10 -0000 On Thursday, Jul 3, 2003, at 09:25 America/Montreal, Stephen Kent wrote: > I am unfamiliar with the cases that you cite re denial of export > license > for integrity-only ESP. Can you provide specific examples that show > that it was this aspect of the product that caused the refusal to > grant a license? There is no question that this is the aspect that caused refusal. Due to NDAs, I'm not at liberty to name the particular products involved in the particular cases that I'm familiar with and have noted here. It is possible that someone could retrieve some data about the cases from the USG -- I'm not sure what information the USG might consider public or not public. I don't doubt for a minute that the root issue with USG is inconsistency in rulings, since I've heard anecdotally that some requests for ESP null-encryption have been granted. Nonetheless, it is clear that the easiest (and lowest cost) approach to gaining USG export approval is to use AH rather than null-encryption ESP. > That suggest to me that SEND probably has different requirements > and thus might best be served by a different protocol. It is not at all obvious to me that SEND's requirements are incompatible with existing AH, particularly given that running code existed for this in 1995 and demonstrated a viable approach to the issue. In any event, we seem pretty far from SAAG list's charter. Ran rja@extremenetworks.com From kent@bbn.com Tue Jul 8 11:54:45 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h68FsjXn003805 for ; Tue, 8 Jul 2003 11:54:45 -0400 (EDT) Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) h68FsXo0018255 for ; Tue, 8 Jul 2003 11:54:44 -0400 (EDT) Received: from [10.150.155.105] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h68FsODF013711; Tue, 8 Jul 2003 11:54:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <09CCD218-B0A8-11D7-9E7F-00039357A82A@extremenetworks.com> References: <09CCD218-B0A8-11D7-9E7F-00039357A82A@extremenetworks.com> Date: Tue, 8 Jul 2003 11:53:56 -0400 To: RJ Atkinson From: Stephen Kent Subject: Re: [saag] Time to reconsider the role of IPsec AH? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Jul 2003 15:54:46 -0000 At 14:22 -0400 7/7/03, RJ Atkinson wrote: >On Thursday, Jul 3, 2003, at 09:25 America/Montreal, Stephen Kent wrote: >>I am unfamiliar with the cases that you cite re denial of export license >>for integrity-only ESP. Can you provide specific examples that show >>that it was this aspect of the product that caused the refusal to >>grant a license? > >There is no question that this is the aspect that caused refusal. > >Due to NDAs, I'm not at liberty to name the particular products >involved in the particular cases that I'm familiar with and have >noted here. It is possible that someone could retrieve some data >about the cases from the USG -- I'm not sure what information the >USG might consider public or not public. I don't doubt for a minute >that the root issue with USG is inconsistency in rulings, since >I've heard anecdotally that some requests for ESP null-encryption >have been granted. Nonetheless, it is clear that the easiest >(and lowest cost) approach to gaining USG export approval is to use >AH rather than null-encryption ESP. > >>That suggest to me that SEND probably has different requirements >>and thus might best be served by a different protocol. > >It is not at all obvious to me that SEND's requirements are >incompatible with existing AH, particularly given that running >code existed for this in 1995 and demonstrated a viable approach >to the issue. > >In any event, we seem pretty far from SAAG list's charter. > This last comment may be the only one on which we agree at this time :-) steve From smb@research.att.com Sun Jul 20 12:22:33 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h6KGMWql029990 for ; Sun, 20 Jul 2003 12:22:32 -0400 (EDT) Received: from mailman.research.att.com (H-135-207-24-32.research.att.com [135.207.24.32])h6KGMWjM011206 for ; Sun, 20 Jul 2003 12:22:32 -0400 (EDT) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101])h6KGEm3j031455 for ; Sun, 20 Jul 2003 12:14:48 -0400 Received: from berkshire.research.att.com (raptor.research.att.com [135.207.23.32])h6KGMVV00954 for ; Sun, 20 Jul 2003 12:22:32 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id A6DD87B4D for ; Sun, 20 Jul 2003 12:22:31 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: Steve Bellovin To: saag@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Jul 2003 12:22:31 -0400 Message-Id: <20030720162231.A6DD87B4D@berkshire.research.att.com> Subject: [saag] saag meeting slides X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 20 Jul 2003 16:22:33 -0000 The slides from the saag meeting are at http://sec.ietf.org/saag/17-July-2003/index.html --Steve Bellovin, http://www.research.att.com/~smb From pekka.nikander@nomadiclab.com Mon Jul 21 15:20:34 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h6LJKYql014738 for ; Mon, 21 Jul 2003 15:20:34 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) h6LJJnK1011346 for ; Mon, 21 Jul 2003 15:20:14 -0400 (EDT) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 8A8B11C; Mon, 21 Jul 2003 22:29:27 +0300 (EEST) Message-ID: <3F1C3CD4.4090603@nomadiclab.com> Date: Mon, 21 Jul 2003 22:19:48 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu, ipsec@lists.tislabs.com, rpsec@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] New mailing list to discuss IP layer signalling security X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: Pekka Nikander List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 21 Jul 2003 19:20:35 -0000 As agreed at SAAG at IETF-57, Vienna, we now have a mailing list to discuss IP layer signalling security. The aim is to discuss the problem, and find out whether there would be enough of interest to look at the more generic problem to warrant an IETF working group. The ML is kindly hosted by VPNC (thanks, Paul). To subscribe, either access the web page at http://www.vpnc.org/ietf-ipsigsec/index.html or simply send a message to with the single word subscribe in the body of the message. To give people time to subscribe to the list, it is not yet possible to post to the list. Once posting becomes possible I will send a separate note to the *list* (not here). The mailing list is chartered as follows. If you think that this chartering is not what was earlier discussed at the saag ML or at the meeting, please send e-mail to me. ------------------------------ Initial ML Charter: The ietf-ipsigsec mailing list is for discussing standizing protocols or protocol components for securing IP layer signalling protocols, such as IPv6 Neighbor Discovery and Autoconfiguration, Mobile IP, Mobile IP optimization protocols, and perhaps some routing protocols. This mailing list may turn into an IETF Working Group. As a background, experience has shown that the IPsec Authentication Header (AH), as it is currently standardized, does not cover the requirements. Hence, for example, the Mobile IPv6 Route Optimization and Secure IPv6 Neighbor Discovery (SEND) both use more-or-less ad hoc, protocol specific mechanisms to reach their security goals. One purpose of this mailing list is to see if something can be learned from these experiences. The topics, to be discussed on the mailing list, are the following: * Address the need for generic protocol components that could be used to secure current and future IP layer (internetworking layer) signalling protocols. Examples of components to consider include Return Routability (RR) and Cryptographically Generated Addresses (CGA). * Progress towards a security model that would cover all or most IP layer signalling protocol security requirements. The focus is on situations where one cannot rely on existing or supposed security infrastructures. * Understand how the proposed separation of the identifier and locator roles of IP addresses may affect the security requirements in the IP layer signalling scope. * Based on the topics above, consider the applicability of the IPsec AH protocol. That is, it is allowed to state that there seems to be no use of AH within this space, or that AH seems to be a perfect match to the needs, as long as such statements are well founded and based on discussion on the items above. However, it is strictly out of scope to state opinions on AH without basing those opinions on clearly argumented technical discussion, or to discuss the applicability of AH for any other purpose but IP layer signalling security. From n.harris@ee.wits.ac.za Tue Jul 22 05:22:19 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h6M9MJql022690 for ; Tue, 22 Jul 2003 05:22:19 -0400 (EDT) Received: from Shannon.ee.wits.ac.za (shannon.ee.wits.ac.za [146.141.16.134]) h6M9MHcc018140 for ; Tue, 22 Jul 2003 05:22:18 -0400 (EDT) Received: from harris (ngharris.ee.wits.ac.za [146.141.16.201]) h6M9MDf12618 for ; Tue, 22 Jul 2003 11:22:15 +0200 Message-ID: <006a01c3502e$7f0668b0$c9108d92@harris> From: "Neill Harris" To: Date: Tue, 22 Jul 2003 10:51:50 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01C3503F.415C0FE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Subject: [saag] Please remove from SAAG mailing list X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 22 Jul 2003 09:22:20 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0067_01C3503F.415C0FE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0067_01C3503F.415C0FE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0067_01C3503F.415C0FE0-- From sriraman_ramji@sancharnet.in Sun Aug 17 11:40:06 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h7HFe6ql008659 for ; Sun, 17 Aug 2003 11:40:06 -0400 (EDT) Received: from ndl1mr1-a-fixed.sancharnet.in (ndl1mr1-a-fixed.sancharnet.in [61.0.0.45])h7HFeCIq000670 for ; Sun, 17 Aug 2003 11:40:13 -0400 (EDT) Received: from conversion-daemon.ndl1mr1-a-fixed.sancharnet.in by ndl1mr1-a-fixed.sancharnet.in (iPlanet Messaging Server 5.2 HotFix 0.9 (built Jul 29 2002)) id <0HJR00101S8GSZ@ndl1mr1-a-fixed.sancharnet.in> for saag@mit.edu; Sun, 17 Aug 2003 21:10:11 +0530 (IST) Received: from ndl1pp2-a-fixed ([61.0.0.70]) by ndl1mr1-a-fixed.sancharnet.in (iPlanet Messaging Server 5.2 HotFix 0.9 (built Jul 29 2002)) saag@mit.edu; Sun, 17 Aug 2003 21:10:11 +0530 (IST) Date: Sun, 17 Aug 2003 21:10:11 +0530 (GMT+05:30) From: sriraman_ramji@sancharnet.in X-Originating-IP: 61.1.212.140 To: saag@mit.edu Message-id: <27525234.1061134811722.JavaMail.nobody@ndl1pp2-a-fixed> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_0oV22aRtVGGlNYwYlbQZgw)" Subject: [saag] Security Lab X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 17 Aug 2003 15:40:07 -0000 --Boundary_(ID_0oV22aRtVGGlNYwYlbQZgw) Content-type: text/plain Content-transfer-encoding: 7BIT Content-disposition: inline Dear Researchers, I am Post graduate Student in rural india. I am now involved in my final year project. For that I am in the need of setting up a security lab to carryout my project in Denial of service attachs. Could any one help to find sources or suggestion regarding the following aspect: 'How can I set up an Attack/Defense Lab' Thanking you, Yours, Sriraman Vadabadhran --Boundary_(ID_0oV22aRtVGGlNYwYlbQZgw)-- From yordanka@emiratescenter.ac.ae Sun Aug 17 12:21:08 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h7HGL7ql009094 for ; Sun, 17 Aug 2003 12:21:08 -0400 (EDT) Received: from domail2.emirates.net.ae (domail2.emirates.net.ae [213.42.1.91]) h7HGLEIq008305 for ; Sun, 17 Aug 2003 12:21:15 -0400 (EDT) Received: from dpmail1.emirates.net.ae ([213.42.1.68]) by domail2.emirates.net.ae (I&ES Mail Server 4.2) with ESMTP id <0HJR00FALURDEL@domail2.emirates.net.ae> for saag@mit.edu; Sun, 17 Aug 2003 20:21:13 +0400 (GST) Received: from stankova (de2404.emirates.net.ae [217.165.82.150]) by dpmail1.emirates.net.ae (I&ES Mail Server 4.2) with SMTP id <0HJR00BSKURDTK@dpmail1.emirates.net.ae> for saag@mit.edu; Sun, 17 Aug 2003 20:21:13 +0400 (GST) Date: Sun, 17 Aug 2003 20:20:56 +0400 From: Mrs Yordanka Stankova To: saag@mit.edu Message-id: <001701c364db$89ebc010$4101640a@orbit.ecmit.ac> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200308171600.h7HG02ql008889@jis.mit.edu> Subject: [saag] Re: security lab X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 17 Aug 2003 16:21:08 -0000 Hi, regarding the lab requirements, i think that the first thing that you need to make clear is, what OS you are going to use.. Since there're some differences. Are you going to use Win2003 Server, Red Hat 9 Server, Slack, or some other type of Linux/UNIX? Can you pls. specify that? After then, are you planning to have a routers, or you 're planning to configure machine to act as one? Pls. specify the above. Regards, Mrs. Yordanka ----- Original Message ----- From: To: Sent: Sunday, August 17, 2003 8:00 PM Subject: saag Digest, Vol 8, Issue 1 > Send saag mailing list submissions to > saag@mit.edu > > To subscribe or unsubscribe via the World Wide Web, visit > https://jis.mit.edu/mailman/listinfo/saag > or, via email, send a message with subject or body 'help' to > saag-request@mit.edu > > You can reach the person managing the list at > saag-owner@mit.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of saag digest..." > ---------------------------------------------------------------------------- ---- > Today's Topics: > > 1. Security Lab > ---------------------------------------------------------------------------- ---- > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag > From sriraman_ramji@sancharnet.in Tue Aug 19 03:20:36 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h7J7KZql006378 for ; Tue, 19 Aug 2003 03:20:36 -0400 (EDT) Received: from ndl1mr1-a-fixed.sancharnet.in (ndl1mr1-a-fixed.sancharnet.in [61.0.0.45])h7J7Kfhc028567 for ; Tue, 19 Aug 2003 03:20:44 -0400 (EDT) Received: from conversion-daemon.ndl1mr1-a-fixed.sancharnet.in by ndl1mr1-a-fixed.sancharnet.in (iPlanet Messaging Server 5.2 HotFix 0.9 (built Jul 29 2002)) id <0HJU00501URMII@ndl1mr1-a-fixed.sancharnet.in> for saag@mit.edu; Tue, 19 Aug 2003 12:48:40 +0530 (IST) Received: from ndl1pp2-a-fixed ([61.0.0.70]) by ndl1mr1-a-fixed.sancharnet.in (iPlanet Messaging Server 5.2 HotFix 0.9 (built Jul 29 2002)) saag@mit.edu; Tue, 19 Aug 2003 12:48:40 +0530 (IST) Date: Tue, 19 Aug 2003 12:48:40 +0530 (GMT+05:30) From: sriraman_ramji@sancharnet.in X-Originating-IP: 210.212.255.193 To: saag@mit.edu Message-id: <24771767.1061277520396.JavaMail.nobody@ndl1pp2-a-fixed> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_mQVze2JYR2JzCHarBLuasQ)" Subject: [saag] Re saag Digest, Vol 8, Issue 2 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 19 Aug 2003 07:20:36 -0000 --Boundary_(ID_mQVze2JYR2JzCHarBLuasQ) Content-type: text/plain Content-transfer-encoding: 7BIT Content-disposition: inline Dear Mrs. Yordanka and all researchars, Ref: Message posted earlier regarding "Security Lab" Thankyou for your response. I planned to use 1. Debian Version 2. Zebra for router I want to get comment on this selection from all. Looking forward.. yours Sriraman --Boundary_(ID_mQVze2JYR2JzCHarBLuasQ)-- From pekkas@netcore.fi Fri Aug 22 03:51:10 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h7M7pAql019130 for ; Fri, 22 Aug 2003 03:51:10 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1])h7M7pJsO007292 for ; Fri, 22 Aug 2003 03:51:19 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7M7pI432753; Fri, 22 Aug 2003 10:51:18 +0300 Date: Fri, 22 Aug 2003 10:51:17 +0300 (EEST) From: Pekka Savola To: saag@mit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: jonne.soininen@nokia.com cc: andreas.bergstrom@hiof.no cc: bob@thefinks.com Subject: [saag] WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 22 Aug 2003 07:51:11 -0000 FYI; Your oxen are being gutted and you're invited to the bloodfest. In other words.. Feedback & Review is sought. Please take a look at the security IPv4 survey document: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-01.txt It's not too long; please send feedback. In particular, it would be good to identify specifications which have incorrect information, or specifications which are not longer relevant and could be moved to historic (if someone bothered to do that, but that's a different topic), or the like. Thanks, Pekka, Jonne & Bob v6ops co-chairs ---------- Forwarded message ---------- Date: Fri, 22 Aug 2003 10:38:49 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Cc: bob@thefinks.com, jonne.soininen@nokia.com, cesar.olvera@consulintel.es, andreas.bergstrom@hiof.no Subject: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents Hi all, This is a WG Last Call for comments on sending the following the next three "Survey of IPv4 Addresses in Currently Deployed IETF Standards" documents to the IESG for consideration as Informational RFCs: Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-01.txt Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-01.txt Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-trans-01.txt Please review these documents carefully, and send your feedback to the list (editorial modifications may also be sent to the editors, Cesar for the first, Andreas for the other two). Please also indicate whether or not you believe that this document is ready to go to the IESG. Silence does NOT indicate consent. Unless sufficient support is demonstrated on the list, the documents will not be send to the IESG. The last call will end in 3 weeks, on 12th September. Pekka, Jonne & Bob From jari.arkko@piuha.net Fri Aug 22 05:58:50 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h7M9woql020643 for ; Fri, 22 Aug 2003 05:58:50 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) h7M9wxsO019731 for ; Fri, 22 Aug 2003 05:58:59 -0400 (EDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A545E6A902; Fri, 22 Aug 2003 12:58:57 +0300 (EEST) Message-ID: <3F45E8C0.2070006@piuha.net> Date: Fri, 22 Aug 2003 12:56:16 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Subject: Re: [saag] WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: bob@thefinks.com cc: jonne.soininen@nokia.com cc: andreas.bergstrom@hiof.no cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 22 Aug 2003 09:58:51 -0000 A couple of comments: > in its turn starting with RFC 1 and ending with RFC 3247. The comments Why stop at 3247? There are more RFCs... > 4.3 RFC 2865 Remote Authentication Dial In User Service (RADIUS) > > There are also several example authentication sequences that use the > attributes discussed above and hence have IPv4 addresses. > > Although the definitions in this RFC are limited to IPv4 addresses, > the protocol is easily extensible for new attribute types. It is > therefore relatively simple to create new IPv6 specific attributes. RFC 3162 has the extension for this. > 4.2 RFC 2617 HTTP Authentication: Basic and Digest Access > Authentication The IP address dependencies are only in a locally calculated nonce formula; while the nonce is communicated to the client, it does not have to figure out how it was created. The server will re-calculate and check the nonce when it gets it back from the client again. I don't see an issue here, not related to IPv4/IPv6, as long as the implementation is able to use an address it got from the socket as the client's address. Though as noted in the RFC, including the IP in the nonce could break proxy farms etc. > 5.039 RFC 2409 The Internet Key Exchange (IKE) (IKE) > > There are no IPv4 dependencies in this protocol. There does not appear to be IPv4 dependencies, but in a way there are, at least in terms of how you can set up your policies. If you were to configure a policy from one unicast address to another unicast address, and expect all traffic to be protected, this might fail if Neighbor Discovery intervenes, uses the same addresses, and you happen to need to run IKE at the same time. Chicken-and-egg problem; can't protect ND before ND has run and UDP works. Most vendors have added some hardcoded or default policy rules to avoid ND getting protected. IPv4 does not have this problem, as ARP & co run at a lower layer... More in draft-arkko-icmpv6-ike-effects-02.txt. > 7.3.3 Mobile IPv4 Challenge Response Extension (RFC 3012) > > The problems are not being addressed and must be addressed in a new > protocol. Why must they be addressed? Mobile IPv4 is, er, for IPv4. This particular RFC addresses an interface which isn't even present in Mobile IPv6. Suggest changing the text to "... are not being addressed and need not be addressed, as Mobile IPv4 works for IPv4 only, and Mobile IPv6 uses a different mechanism which does not require this particular extension." --Jari From pekkas@netcore.fi Fri Aug 22 06:40:49 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h7MAenql021125 for ; Fri, 22 Aug 2003 06:40:49 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1])h7MAevsO004735 for ; Fri, 22 Aug 2003 06:40:58 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7MAeqE02173; Fri, 22 Aug 2003 13:40:52 +0300 Date: Fri, 22 Aug 2003 13:40:52 +0300 (EEST) From: Pekka Savola To: Jari Arkko Subject: Re: [saag] WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) In-Reply-To: <3F45E8C0.2070006@piuha.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: bob@thefinks.com cc: jonne.soininen@nokia.com cc: andreas.bergstrom@hiof.no cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 22 Aug 2003 10:40:50 -0000 Thanks for the quick review! On Fri, 22 Aug 2003, Jari Arkko wrote: > A couple of comments: > > > in its turn starting with RFC 1 and ending with RFC 3247. The comments > > Why stop at 3247? There are more RFCs... Phil Nesser was paid to do the job (even though at very low rates, I hear), and he stopped at 3247. If we had volunteers, we could extend beyond that, but the docs are a bit outdated now. > > 5.039 RFC 2409 The Internet Key Exchange (IKE) (IKE) > > > > There are no IPv4 dependencies in this protocol. > > There does not appear to be IPv4 dependencies, but > in a way there are, at least in terms of how you can > set up your policies. If you were to configure a > policy from one unicast address to another unicast > address, and expect all traffic to be protected, > this might fail if Neighbor Discovery intervenes, > uses the same addresses, and you happen to need to > run IKE at the same time. Chicken-and-egg problem; > can't protect ND before ND has run and UDP works. > Most vendors have added some hardcoded or default > policy rules to avoid ND getting protected. IPv4 > does not have this problem, as ARP & co run at a lower > layer... > > More in draft-arkko-icmpv6-ike-effects-02.txt. I agree that there may be some difficulties here. If others agree, could you try to submit a short piece of text summarizing the problem and possibly giving a pointer. > > 7.3.3 Mobile IPv4 Challenge Response Extension (RFC 3012) > > > > The problems are not being addressed and must be addressed in a new > > protocol. > > Why must they be addressed? They don't.. that's why we're asking the subject matter experts to state whether the suggestd actions are valid or not. > Mobile IPv4 is, er, for IPv4. This particular RFC addresses > an interface which isn't even present in Mobile IPv6. Suggest > changing the text to "... are not being addressed and need not be > addressed, as Mobile IPv4 works for IPv4 only, and Mobile IPv6 > uses a different mechanism which does not require this particular > extension." Agre. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From mouse@Sparkle.Rodents.Montreal.QC.CA Fri Aug 22 21:11:55 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h7N1Bsql004261 for ; Fri, 22 Aug 2003 21:11:54 -0400 (EDT) Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7])h7N1C32a020681 for ; Fri, 22 Aug 2003 21:12:03 -0400 (EDT) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id VAA02479; Fri, 22 Aug 2003 21:12:00 -0400 (EDT) From: der Mouse Message-Id: <200308230112.VAA02479@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Fri, 22 Aug 2003 15:09:16 -0400 (EDT) To: Pekka Savola , jonne.soininen@nokia.com, andreas.bergstrom@hiof.no, bob@thefinks.com, saag@mit.edu Subject: Re: [saag] WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) In-Reply-To: References: X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 23 Aug 2003 01:11:55 -0000 > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-01.txt Okay, here goes: > The comments for each RFC is "raw" in nature. Number clash: comments are, or comment is. In section 3.0, Full Standards, you seem to have missed 0959 (STD0009), which has IP version issues relating to encoding IP addresses in text strings. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From pekkas@netcore.fi Sat Aug 23 00:40:06 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h7N4e6ql006348 for ; Sat, 23 Aug 2003 00:40:06 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1])h7N4eF5a018807 for ; Sat, 23 Aug 2003 00:40:15 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7N4civ12516; Sat, 23 Aug 2003 07:38:44 +0300 Date: Sat, 23 Aug 2003 07:38:44 +0300 (EEST) From: Pekka Savola To: der Mouse Subject: Re: [saag] WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) In-Reply-To: <200308230112.VAA02479@Sparkle.Rodents.Montreal.QC.CA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: jonne.soininen@nokia.com cc: bob@thefinks.com cc: andreas.bergstrom@hiof.no cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 23 Aug 2003 04:40:07 -0000 On Fri, 22 Aug 2003, der Mouse wrote: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-01.txt > > Okay, here goes: > > > The comments for each RFC is "raw" in nature. > > Number clash: comments are, or comment is. Thanks. > In section 3.0, Full Standards, you seem to have missed 0959 (STD0009), > which has IP version issues relating to encoding IP addresses in text > strings. 959 seems the be the FTP protocol -- which _is_ included in Apps area survey? Maybe you mistyped the number or didn't see the other survey documents? Thanks, -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From mouse@Sparkle.Rodents.Montreal.QC.CA Sat Aug 23 00:52:38 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p1/8.12.8) with ESMTP id h7N4qbql006550 for ; Sat, 23 Aug 2003 00:52:37 -0400 (EDT) Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7])h7N4qj5a024893 for ; Sat, 23 Aug 2003 00:52:45 -0400 (EDT) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA11638; Sat, 23 Aug 2003 00:52:41 -0400 (EDT) From: der Mouse Message-Id: <200308230452.AAA11638@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Sat, 23 Aug 2003 00:48:23 -0400 (EDT) To: Pekka Savola , jonne.soininen@nokia.com, bob@thefinks.com, andreas.bergstrom@hiof.no, saag@mit.edu Subject: Re: [saag] WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) In-Reply-To: References: X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 23 Aug 2003 04:52:38 -0000 >>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-01.txt >> Okay, here goes: [...] >> In section 3.0, Full Standards, you seem to have missed 0959 > 959 seems the be the FTP protocol -- Yes. > which _is_ included in Apps area survey? Maybe you mistyped the > number or didn't see the other survey documents? I read only the one whose URL I saw, the one quoted above. I didn't notice any indication that any others existed, though upon checking again with this in mind I see that I did miss the remark that the overall task was broken up across multiple drafts. My apologies for the noise. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From pekkas@netcore.fi Fri Oct 3 03:59:47 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id h937xltf020165 for ; Fri, 3 Oct 2003 03:59:47 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1])h93809TN006971 for ; Fri, 3 Oct 2003 04:00:09 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h93808r25736; Fri, 3 Oct 2003 11:00:08 +0300 Date: Fri, 3 Oct 2003 11:00:07 +0300 (EEST) From: Pekka Savola To: saag@mit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: =?ISO-8859-1?Q?Andreas_Bergstr=F8m?= Subject: [saag] I-D ACTION:draft-ietf-v6ops-ipv4survey-sec-02.txt (fwd) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 03 Oct 2003 07:59:48 -0000 Hi, Remember us asking for feedback on the "IPv4 address usage survey" a couple of weeks ago? Well, the document has been revised a bit, and I believe it should address the comments received: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-02.txt Please check it out and see that it's factually correct, the recommendations in section 7 seem reasonable, etc. In particular, could someone provide text about the recently-added (found an RFC that had been missed previously) RFC 2817 ? ==== 5.069 RFC 2817 Upgrading to TLS Within HTTP/1.1 FIXME: requires to be analyzed by subject matter experts. ==== Thanks, Pekka writing as v6ops co-chair ---------- Forwarded message ---------- Date: Thu, 02 Oct 2003 07:35:31 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-sec-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Author(s) : P. Nesser II, A. Bergstrom Filename : draft-ietf-v6ops-ipv4survey-sec-02.txt Pages : 0 Date : 2003-10-1 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Sandards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-sec-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-sec-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From pekkas@netcore.fi Mon Oct 13 12:19:17 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id h9DGJGtf006951 for ; Mon, 13 Oct 2003 12:19:16 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1])h9DGJf7R021733 for ; Mon, 13 Oct 2003 12:19:41 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9DGJb117824; Mon, 13 Oct 2003 19:19:38 +0300 Date: Mon, 13 Oct 2003 19:19:36 +0300 (EEST) From: Pekka Savola To: saag@mit.edu Subject: [saag] I-D ACTION:draft-ietf-v6ops-ipv4survey-sec-02.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT cc: =?ISO-8859-1?Q?Andreas_Bergstr=F8m?= X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 13 Oct 2003 16:19:17 -0000 Hi, Trying to ping as a reminder. Anyone reviewed the document to see if it's correct? Anyone knowledgeable of HTTP and TLS, and able to send text on RFC2817 ? Thanks. ---------- Forwarded message ---------- Date: Fri, 3 Oct 2003 11:00:07 +0300 (EEST) From: Pekka Savola To: saag@mit.edu Cc: Andreas Bergstrřm Subject: [saag] I-D ACTION:draft-ietf-v6ops-ipv4survey-sec-02.txt (fwd) Hi, Remember us asking for feedback on the "IPv4 address usage survey" a couple of weeks ago? Well, the document has been revised a bit, and I believe it should address the comments received: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-02.txt Please check it out and see that it's factually correct, the recommendations in section 7 seem reasonable, etc. In particular, could someone provide text about the recently-added (found an RFC that had been missed previously) RFC 2817 ? ==== 5.069 RFC 2817 Upgrading to TLS Within HTTP/1.1 FIXME: requires to be analyzed by subject matter experts. ==== Thanks, Pekka writing as v6ops co-chair ---------- Forwarded message ---------- Date: Thu, 02 Oct 2003 07:35:31 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-sec-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Author(s) : P. Nesser II, A. Bergstrom Filename : draft-ietf-v6ops-ipv4survey-sec-02.txt Pages : 0 Date : 2003-10-1 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Sandards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-sec-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-sec-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ saag mailing list saag@mit.edu https://jis.mit.edu/mailman/listinfo/saag From pekka.nikander@nomadiclab.com Mon Oct 13 13:16:31 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id h9DHGUtf007958 for ; Mon, 13 Oct 2003 13:16:30 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) h9DHGt7R018997 for ; Mon, 13 Oct 2003 13:16:56 -0400 (EDT) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 6C2651C for ; Mon, 13 Oct 2003 20:30:10 +0300 (EEST) Message-ID: <3F8ADE0F.7020908@nomadiclab.com> Date: Mon, 13 Oct 2003 20:17:03 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Proposing a small addition to ESP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 13 Oct 2003 17:16:31 -0000 In the draft whose announcement I've copied below, I am proposing a small addition to ESP. I believe that the addition might be quite useful for various mobility and perhaps multi-homing mechanisms, including MIPv4, MIPv6, HIP, and perhaps others. So far this has induced no discussion at the ipsec WG list, and since the IPsec WG is being closed down, it might be more appropriate to discuss this here. I have also tentatively listed the issue as an item on the proposed HIP WG charter. While the draft is somewhat long, the actual addition is small. Most of the pages in the draft gives background material and discussed the potential changes for the proposed new mode. --Pekka Nikander A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Bound End-to-End Tunnel (BEET) mode for ESP Author(s) : P. Nikander Filename : draft-nikander-esp-beet-mode-00.txt Pages : 28 Date : 2003-10-9 This document specifies a new mode, called Bound End-to-End Tunnel (BEET) mode, for IPsec ESP. The new mode augments the existing ESP tunnel and transport modes. For end-to-end tunnels, the new mode provides limited tunnel mode semantics without the regular tunnel mode overhead. The mode is intended to support new uses of ESP, including mobility and multi-address multi-homing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-00.txt From pekkas@netcore.fi Mon Oct 13 13:47:52 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id h9DHlqtf008495 for ; Mon, 13 Oct 2003 13:47:52 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1])h9DHmGnm014798 for ; Mon, 13 Oct 2003 13:48:17 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9DHmGx19347 for ; Mon, 13 Oct 2003 20:48:16 +0300 Date: Mon, 13 Oct 2003 20:48:15 +0300 (EEST) From: Pekka Savola To: saag@mit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Subject: [saag] I-D ACTION:draft-savola-v6ops-firewalling-02.txt (fwd) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 13 Oct 2003 17:47:52 -0000 FYI, It would be very useful to get feedback and review from security specialists as well as IPv6 folks. The draft (modulo changes, if any) will be presented in the next IETF at v6ops WG for consideration as WG item for Informational RFC submission. Thanks. ---------- Forwarded message ---------- Date: Fri, 10 Oct 2003 15:38:11 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-savola-v6ops-firewalling-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Firewalling Considerations for IPv6 Author(s) : P. Savola Filename : draft-savola-v6ops-firewalling-02.txt Pages : 15 Date : 2003-10-10 There are quite a few potential problems regarding firewalling or packet filtering in IPv6 environment. These include slight ambiguity in the IPv6 specification, problems parsing packets beyond unknown Extension Headers and Destination Options, and introduction of end- to-end encrypted traffic and peer-to-peer applications. There may also be need to extend packet matching to include some Extension Header or Destination Option fields. This draft discusses these issues to raise awareness and proposes some tentative solutions or workarounds. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-v6ops-firewalling-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-savola-v6ops-firewalling-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-savola-v6ops-firewalling-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From yordanka@emiratescenter.ac.ae Tue Oct 14 15:03:12 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id h9EJ37tf029583 for ; Tue, 14 Oct 2003 15:03:12 -0400 (EDT) Received: from domail1.emirates.net.ae (domail1.emirates.net.ae [213.42.1.90]) h9EJ3VsI003804 for ; Tue, 14 Oct 2003 15:03:32 -0400 (EDT) Received: from dpmail1.emirates.net.ae ([213.42.1.68]) by domail1.emirates.net.ae (I&ES Mail Server 4.2) with ESMTP id <0HMR00EX6GXTKY@domail1.emirates.net.ae> for saag@mit.edu; Tue, 14 Oct 2003 23:03:29 +0400 (GST) Received: from emirates.net.ae (dxbmcl2.emirates.net.ae [194.170.0.71]) by dpmail1.emirates.net.ae (I&ES Mail Server 4.2) with ESMTP id <0HMR00JDUGXTSP@dpmail1.emirates.net.ae> for saag@mit.edu; Tue, 14 Oct 2003 23:03:29 +0400 (GST) Received: from [213.42.1.149] by dxbbsmail1.emirates.net.ae (mshttpd); Tue, 14 Oct 2003 23:03:28 +0400 Date: Tue, 14 Oct 2003 23:03:28 +0400 From: yordanka@emiratescenter.ac.ae To: saag@mit.edu Message-id: <5b6c458b4f.58b4f5b6c4@emirates.net.ae> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 0.2 (built Apr 26 2002) Content-type: multipart/mixed; boundary="Boundary_(ID_w5XdUgijxf3CfA3Ar6d4Qw)" Content-language: en X-Accept-Language: en Priority: normal Subject: [saag] Re: RFC 2817 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 14 Oct 2003 19:03:13 -0000 This is a multi-part message in MIME format. --Boundary_(ID_w5XdUgijxf3CfA3Ar6d4Qw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Hi, i whould like to send some text on that. What's the time, which i have? Regards Yordanka Stankova ----- Original Message ----- From: saag-request@mit.edu Date: Tuesday, October 14, 2003 8:00 pm Subject: saag Digest, Vol 9, Issue 2 > Send saag mailing list submissions to > saag@mit.edu > > To subscribe or unsubscribe via the World Wide Web, visit > https://jis.mit.edu/mailman/listinfo/saag > or, via email, send a message with subject or body 'help' to > saag-request@mit.edu > > You can reach the person managing the list at > saag-owner@mit.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of saag digest..." > --Boundary_(ID_w5XdUgijxf3CfA3Ar6d4Qw) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 8BIT Content-description: Today's Topics (3 messages) Today's Topics: 1. I-D ACTION:draft-ietf-v6ops-ipv4survey-sec-02.txt (fwd) (Pekka Savola) 2. Proposing a small addition to ESP (Pekka Nikander) 3. I-D ACTION:draft-savola-v6ops-firewalling-02.txt (fwd) (Pekka Savola) MIME-version: 1.0 Content-type: multipart/digest; boundary="Boundary_(ID_ATmQgSkGr3Q5Z4fqGP/Byw)" --Boundary_(ID_ATmQgSkGr3Q5Z4fqGP/Byw) MIME-version: 1.0 Content-type: message/rfc822 Date: Mon, 13 Oct 2003 19:19:36 +0300 (EEST) From: Pekka Savola Subject: [saag] I-D ACTION:draft-ietf-v6ops-ipv4survey-sec-02.txt (fwd) To: saag@mit.edu Cc: =?ISO-8859-1?Q?Andreas_Bergstr=F8m?= Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1 Content-transfer-encoding: 8BIT Precedence: list Message: 1 Hi, Trying to ping as a reminder. Anyone reviewed the document to see if it's correct? Anyone knowledgeable of HTTP and TLS, and able to send text on RFC2817 ? Thanks. ---------- Forwarded message ---------- Date: Fri, 3 Oct 2003 11:00:07 +0300 (EEST) From: Pekka Savola To: saag@mit.edu Cc: Andreas Bergstrřm Subject: [saag] I-D ACTION:draft-ietf-v6ops-ipv4survey-sec-02.txt (fwd) Hi, Remember us asking for feedback on the "IPv4 address usage survey" a couple of weeks ago? Well, the document has been revised a bit, and I believe it should address the comments received: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-02.txt Please check it out and see that it's factually correct, the recommendations in section 7 seem reasonable, etc. In particular, could someone provide text about the recently-added (found an RFC that had been missed previously) RFC 2817 ? ==== 5.069 RFC 2817 Upgrading to TLS Within HTTP/1.1 FIXME: requires to be analyzed by subject matter experts. ==== Thanks, Pekka writing as v6ops co-chair ---------- Forwarded message ---------- Date: Thu, 02 Oct 2003 07:35:31 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-sec-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Author(s) : P. Nesser II, A. Bergstrom Filename : draft-ietf-v6ops-ipv4survey-sec-02.txt Pages : 0 Date : 2003-10-1 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Sandards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-sec-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-sec-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ saag mailing list saag@mit.edu https://jis.mit.edu/mailman/listinfo/saag --Boundary_(ID_ATmQgSkGr3Q5Z4fqGP/Byw) MIME-version: 1.0 Content-type: message/rfc822 Date: Mon, 13 Oct 2003 20:17:03 +0300 From: Pekka Nikander Subject: [saag] Proposing a small addition to ESP To: saag@mit.edu Message-id: <3F8ADE0F.7020908@nomadiclab.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Precedence: list Message: 2 In the draft whose announcement I've copied below, I am proposing a small addition to ESP. I believe that the addition might be quite useful for various mobility and perhaps multi-homing mechanisms, including MIPv4, MIPv6, HIP, and perhaps others. So far this has induced no discussion at the ipsec WG list, and since the IPsec WG is being closed down, it might be more appropriate to discuss this here. I have also tentatively listed the issue as an item on the proposed HIP WG charter. While the draft is somewhat long, the actual addition is small. Most of the pages in the draft gives background material and discussed the potential changes for the proposed new mode. --Pekka Nikander A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Bound End-to-End Tunnel (BEET) mode for ESP Author(s) : P. Nikander Filename : draft-nikander-esp-beet-mode-00.txt Pages : 28 Date : 2003-10-9 This document specifies a new mode, called Bound End-to-End Tunnel (BEET) mode, for IPsec ESP. The new mode augments the existing ESP tunnel and transport modes. For end-to-end tunnels, the new mode provides limited tunnel mode semantics without the regular tunnel mode overhead. The mode is intended to support new uses of ESP, including mobility and multi-address multi-homing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-00.txt --Boundary_(ID_ATmQgSkGr3Q5Z4fqGP/Byw) MIME-version: 1.0 Content-type: message/rfc822 Date: Mon, 13 Oct 2003 20:48:15 +0300 (EEST) From: Pekka Savola Subject: [saag] I-D ACTION:draft-savola-v6ops-firewalling-02.txt (fwd) To: saag@mit.edu Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Precedence: list Message: 3 FYI, It would be very useful to get feedback and review from security specialists as well as IPv6 folks. The draft (modulo changes, if any) will be presented in the next IETF at v6ops WG for consideration as WG item for Informational RFC submission. Thanks. ---------- Forwarded message ---------- Date: Fri, 10 Oct 2003 15:38:11 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-savola-v6ops-firewalling-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Firewalling Considerations for IPv6 Author(s) : P. Savola Filename : draft-savola-v6ops-firewalling-02.txt Pages : 15 Date : 2003-10-10 There are quite a few potential problems regarding firewalling or packet filtering in IPv6 environment. These include slight ambiguity in the IPv6 specification, problems parsing packets beyond unknown Extension Headers and Destination Options, and introduction of end- to-end encrypted traffic and peer-to-peer applications. There may also be need to extend packet matching to include some Extension Header or Destination Option fields. This draft discusses these issues to raise awareness and proposes some tentative solutions or workarounds. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-v6ops-firewalling-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-savola-v6ops-firewalling-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-savola-v6ops-firewalling-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_ATmQgSkGr3Q5Z4fqGP/Byw)-- --Boundary_(ID_w5XdUgijxf3CfA3Ar6d4Qw) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-description: Digest Footer _______________________________________________ saag mailing list saag@mit.edu https://jis.mit.edu/mailman/listinfo/saag --Boundary_(ID_w5XdUgijxf3CfA3Ar6d4Qw)-- From Gregory@netscreen.com Sat Oct 25 19:06:00 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id h9PN5stf021450 for ; Sat, 25 Oct 2003 19:05:59 -0400 (EDT) Received: from mail2.netscreen.com (mail2.netscreen.com [63.126.135.18]) h9PN6NNx024788 for ; Sat, 25 Oct 2003 19:06:23 -0400 (EDT) Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) h9PN6EOh002098; Sat, 25 Oct 2003 16:06:15 -0700 (PDT) Received: by NS-CA.netscreen.com with Internet Mail Service (5.5.2653.19) id <461S13F6>; Sat, 25 Oct 2003 16:06:14 -0700 Message-ID: <541402FFDC56DA499E7E13329ABFEA87E67378@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'saag@mit.edu'" , "'ipsec@lists.tislabs.com'" , "'ietf-pkix@imc.org'" Date: Sat, 25 Oct 2003 16:06:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [saag] BOF: pki4ipsec X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 25 Oct 2003 23:06:00 -0000 Folks, As IPsec working group is finishing up its chartered work, some of the works-in-progress have been moved to other or new WGs. The effort of profiling the use of PKI for IPsec is one such effort. We will start with a BOF in MN. Details below. Profiling Use of PKI in IPSEC BOF (pki4ipsec) Thursday, November 13 at 0900-1130 ================================== Full charter and mail list info at: http://www.icsalabs.com/pki4ipsec We are looking forward to your participation! Gregory Lebovitz (Co-chair) From mcr@sandelman.ottawa.on.ca Mon Nov 3 19:29:25 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hA40TOtf014100 for ; Mon, 3 Nov 2003 19:29:24 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166])hA40Tpnh021243 for ; Mon, 3 Nov 2003 19:29:55 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247])hA40Wn319489verified OK); Mon, 3 Nov 2003 19:32:57 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) hA40NgEG005097 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 3 Nov 2003 19:23:43 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) ESMTP id hA40NeTM005091; Mon, 3 Nov 2003 19:23:41 -0500 To: Russ Housley , saag@mit.edu In-reply-to: Your message of "Fri, 31 Oct 2003 15:29:27 EST." <5.2.0.9.2.20031031152519.0449f590@mail.binhost.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 03 Nov 2003 19:23:40 -0500 Message-ID: <5090.1067905420@marajade.sandelman.ottawa.on.ca> From: Michael Richardson cc: iesg@ietf.org cc: ipsec@lists.tislabs.com cc: design@lists.freeswan.org Subject: [saag] IKE and Certicom "IP Rights" X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 04 Nov 2003 00:29:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Russ" == Russ Housley writes: Russ> Dear IPsec Working Group: Russ> I just got this note, which is a follow-up to a query that I sent to Russ> Certicom in July 2003. Thank you for posting this. But, this part makes no sense. Certicom> and other IETF standards using MODP Groups. The applicable Certicom> patents include, but are not limited to, US Patents #5,933,504, Certicom> #6,563,928, #6,078,667, #6,178,507, #6,195,433, US Patent Certicom> Application Publications #2001/0014153, #2002/0090085, and PCT Certicom> Application #WO 00/01109, and corresponding foreign applications. Certicom> limited field of use of MODP public key cryptography Certicom> implemented using the well known Groups 1 and 2 as defined in Certicom> RFC 2409. Certicom will send the IETF terms of the royalty Certicom> free license and will post this our web site shortly. This is a silly offer. Certicom IPR people don't understand their own patents and do not understand IKE, or cryptography at all it seems to me. That he goes on to suggest that we use ECC instead, for which they have even further patents is even more suspect. I didn't look up all the patents, but the first one, 5,933,504, is about how to generate and check the numbers. We discussed this last July in Vienna. This patent ought to apply to all IETF systems that use DH. No IKE implementations use the described mechanisms. IKE doesn't do that. It does DH. To make DH interoperate we have to agree on a common base, "g", which should have certain properties. Once the "g" has been generated and checked, we are done. So, from the IETF's point of view the only person/group that needs to license this patent is the document editor! The only other people that would need to license this would be who didn't trust the document editor and/or the IETF. Certicom "offer"s us MODP groups 1 and 2. Wow. Will they offer to license PI to me next? they are NUMBERS. This is nonsense from them. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP6bxioqHRg3pndX9AQHJRgQAksDiCqLRsPVM4mOMB58+5p1pvUnFbs71 Oxst6jRLoyLApjbydWBHOGLzpiLOKPgTCpn2+rTs+UMBcNIARWhcqIa/wIcBoKNk 6bmpUAyfBMfJ5eFm58cK7X4vUzmZJUvoZqNsFaYhZYOjF6yLlMHKGTHi0DMPtQ/T NK7gFcrPpm4= =ZHqT -----END PGP SIGNATURE----- From nw141292@binky.central.sun.com Wed Nov 19 18:05:02 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hAJN51tf011782 for ; Wed, 19 Nov 2003 18:05:01 -0500 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) hAJN5Zd0017736 for ; Wed, 19 Nov 2003 18:05:36 -0500 (EST) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hAJN5U5u005997; Wed, 19 Nov 2003 16:05:30 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) with ESMTP id hAJN5So4025059; Wed, 19 Nov 2003 16:05:29 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) hAJN1DYY016244; Wed, 19 Nov 2003 17:01:13 -0600 (CST) Received: (from nw141292@localhost)hAJN1CWs016243; Wed, 19 Nov 2003 17:01:12 -0600 (CST) Date: Wed, 19 Nov 2003 17:01:12 -0600 From: Nicolas Williams To: saag@mit.edu Message-ID: <20031119230111.GW888@binky.central.sun.com> Mail-Followup-To: saag@mit.edu, ipsec-policy@vpnc.org, ietf-cat-wg@lists.stanford.edu Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="DBIVS5p969aUjpLe" Content-Disposition: inline User-Agent: Mutt/1.4i cc: ietf-cat-wg@lists.stanford.edu cc: ipsec-policy@vpnc.org Subject: [saag] Channel Bindings presentation from IETF 58 SAAG meeting X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 19 Nov 2003 23:05:02 -0000 --DBIVS5p969aUjpLe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Attached. I've added notes to some of the slides and one slide that should have been there ("Goals"). No slides have been modified. The most consisten feedback I have received since I made the presentation is that it was much too long, for which I apologize. I have also received positive feedback on the concept of IPsec channels, which is encouraging. Cheers, Nico -- --DBIVS5p969aUjpLe Content-Type: application/pdf Content-Disposition: attachment; filename="cbindings.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIKJeLjz9MNCjIgMCBvYmoKPDwKL0xlbmd0aCA4MjAKL0ZpbHRlciAvRmxhdGVE ZWNvZGUKPj4Kc3RyZWFtDQpIiXRUS2/bMAy++1fwKAGzqqft7LR2a4sV2AqsBnboenBjNXWX OEPsPn7+SMpOsgJDEJsmKT4+ftRZnZ1cWDBQP2SmUosCNP6SZF2pKg9FEVRZQL3JNBt3q+zk 8sbAashyrbQOUC+T5KF+zW7FZ5kvxKM0oun7uJZ5EHBGqk6Wope5MaJFY0eGfjXIu/oqM04V VUrNktVaeQihVMFSZg5fUqJbPJybQuxkXormgZ4jKrTISexYjDK3k5Yd2NRLm74GtFrx4jlM LtFpiSJW3PCr79lAhc9R7/Foipxs7fSx4i+M55Of5m+N3iplf2PFmFo0CgHiFlmyvlQWgvcq JHCxQ5c6/C4rymexMGPFlstaNyQPSuaV+Elit153rNsMnxjUAUF97tlZSeO5Ky22G85+XmOC oC0cP39c4kivsKInVFgPr2A0fIPbOw1tZqADnEtQBRSLhXIFOM+F5zaQchezm+ysJtaUdmYN SkYHYo3XVvmKGjMzayaKJLKYxBVq9Rr/9flHgPqRaBKpKRhQSSNwokO2lCKSAlBhaVD4fEm+ uUEtdXhy4RONF2phHSWtvyTeMKqi346yfjpiu3KVL5Lb3ov9F6k0uI9YiuGZawGbeRaa5m+Y TCizGFusF+lMvBD9ko8BUcDTHiCZUok4JeV0WUJulAmumlO/B+XPjjEYYk+dj1KLZpSExJZ6 ZmVCYsNItAfUmhHGIxADiVWin1bTgpHgsBLcaVdVqprIZwzDhMcRpfdDdVYrQ/54eD6gi33Z dkLs63lNzLsg7sLNKe3W6SU9p3KlCSLGkV5dTxuzksjWD1KLA0DeVwkgbYsZoFTa/fMIaYR+ HmGwoTiadEj702+RKwR/xQTRYpgYMo3eKmvKxWH0HH46z31IZtkL9RJpu5kKjDxCjELL7bSk a1Wq3KnS447kGNvp/072H7pf9xGGNQ+2jfDYDJTmaLpN28b9fOGXRTxY39ERYsVhJcak42Bx 8kpWKk6/x9PuuV6lujbEWLz/nNj9ji3NJwV5TZcqGsdHaNLljQgwpDnebHFHGPFd9TYVLadr km/5Oc5yu97ujgMTw3GR5rvprwADAITwbl8KZW5kc3RyZWFtCmVuZG9iagozIDAgb2JqCjw8 Ci9Qcm9jU2V0IFsvUERGIC9UZXh0IF0KL0ZvbnQgPDwKL0YyIDQgMCBSCi9GNCA1IDAgUgo+ PgovRXh0R1N0YXRlIDw8Ci9HUzEgNiAwIFIKPj4KPj4KZW5kb2JqCjkgMCBvYmoKPDwKL0xl bmd0aCA3NzYKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQpIiaRVS2/aQBC++1eM 1MvuwZt92Gv7VBHyEJHaRIEqhygHB0ygBbvCTtP8+87MYpoabhXCWmbn++b1jTmfRWdXFgzM lpHJVeFB4yecbF4on4P3qco8zLaR5svdS3R2PTXw0kaxVtrg1Tx6FLNGxtaKsXya3UTGBh5k 9olKwDun8oQ4CKJdgIyeWxmbRHQyTsVOGi1K/F2IecckGmKj0PUiIowhDAfE0xuir3Yy9qLZ wj2CrLiSJsPodLRZ4j4wWKY4wAP6YfWO+WoBY5mJFR/Luq42wMdzNK7xJOrFun5hU3uc056K gjrksCF/L5jnXwoq1Ai4qJYyzoQaZhcP2RpiqzlwRyTYHRfoflUcYwGXMi7Eb4lBtz83wQif zCDL/+WzR31U2h6N4lzm4lUmRnRAcR6kTakfBvuRYjxXCBhJ68Qz2ZoPnhOJ47+jybXSaVGh +5zAnwdlsGoshaWoNkSd0vyxmoSqMdz7XLxtyVDW8DAiXaTiq6QwWBodrk81/q+0dBGY0T/H tFCVLVZWSYdZxZgkjFmvKBfDamHjJqQfZK90DkarJO9lmx56lfbchrlR5y1VX8mC2Q2xo3hX nHWJ1hq7Qd+KbzfUwJZKhglZOwLuliXDi73TKZH6PgPr+wwskWObYEoRG4mjnv+Qzouqo5Rw WJwj3k2QOqzETNoMo2hsNsK35Nee7Kbrx+RCuFte71WF64obDhPa8zvagrD81RzGq5Kk6QTu TWg6FjlinwmDgudQFMOVnpCmEWUpM+pIwo31wx1n24ZKPLXsp4syfVH7WNNq/rojlay7dyjr Bdx2XCFxMl4VlijMIVHaxEw0dXgTrBfknYmyW5OJIHGPOSxaUDy+Jzc4bC92dYnPbs0bSzUi z8lFOdLztyDjmIXal90sOd2BpDc8CHx7ee4JzkSiUhd4xKRJ6TUfj9v0KC6a+Stfbqu6C/eX M6wjxTo+Pu+vEXeDfw/f0WATeMONgS/w+KRhERlYQ2Rcqjz4olDOg0uM0gnENiXjroqm0R8B BgAnLIBACmVuZHN0cmVhbQplbmRvYmoKMTAgMCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgL1Rl eHQgXQovRm9udCA8PAovRjIgNCAwIFIKPj4KL0V4dEdTdGF0ZSA8PAovR1MxIDYgMCBSCj4+ Cj4+CmVuZG9iagoxMiAwIG9iago8PAovTGVuZ3RoIDEwNzAKL0ZpbHRlciAvRmxhdGVEZWNv ZGUKPj4Kc3RyZWFtDQpIiZxWT2/bOgy/+1PoKD3AqiRLtnzcsLXYgAcMq29dD67jNh5SJ4jV Bfv2IykpSfse1q0oGlMUSZE//pHed8XFpWGadfeF9rKtmYK/SJmmlTWrayebmnWPhaa9/UNx cXWt2cNSKKkUaA7FDb/aiob3G6ErvvwjbrvPxUWXzDrpDGkSoWsrLaurWhqLRlU2qtAQ/BwK /g3Miu77mWfRAHx046RF/Up60i/BCY1aN7wTWvOtUJyJ0ii+26M3oyh1zRfRJmqG/cDCOq7Y jSgbPm8DmyPjcIsMNmxnsjGMuxCtbe9pI4Z2aZNfVjpErPtAWFQUAhBNdGgATNZglvczmG/4 ht0J3fJJaD6vpvlh+QOgjJIJp7+BBxKY4AV0GlRFnEyTgTIegNJNRgrJvagUHxdhaj7OyAhC O87od43rkQ3CIMBlBShWDYSnAVRg7U7iAFOl/gOTQqcIpjLBEx1CxNChT19iliAHpuIDHITf NSStBwoSBNuAWUwi7Gww0xk9HQ/x0hIK+NVeYfy1srIyL9Ezpn6OnpYqqkZKt+CZB+VKVnXC MJb5qdR6oRXkENHxmGKDSABrEqUFJD1nTxiMNgCFMfzuJ4kQ3RN7t1vOlcleQGW2JvpH0qYF 4Av/KFeC6Q3xfkYBOiuafAIprGv0jITJPnk0kEA8ZILSfg0451vM2NuAc97LxmTgTO6J9oic Tsi1FLxC5DT6WUE0bUYuoRW2bIfcLUn+EIZPK5JnZOiJ2C9tzSAWpoGskBgGze5jOcFyoAM3 U5hIHDKxPaZGY2peB6ix0r8VnybPrrfhE+PazkvA5VNcnqU1nZ5Gk2JE6LaRBs6udT77d/NE YduQ40QZ6CMLyq6VrclD9+S5T55jl1q+wiqDAYufkc30GVe0BSBXHOaopumjIBwkibsfN33I YpMwVMNAh3F/3w/jH0xKZ+tcdn8zKp0lfHJQxz4/3SkKiw8LbrUChz3OSOymBTsv4ORL/c9W E/IwHw3G16Y2nMchsLsxHMaRtmZG4fWPcUl2esj4/9g/kyAAFCu1BN/TfaPzHM3eHqawZp++ LAS6cOSLw4pxdA9h/Ts+01XncIi2aYh+7MCeg4ye/369gvM+A1jfGdX8AaqB/ctubhVbwVtg YoWuHD4Q2hYHZWWpyEvjkLkfi+vifXdK2bMmUg6r0CqUfC1hNEzSowQorXXU1S9fJYiIzTVp jukzGDpcuhHFBOwGpggtpgWy4TBT8YHADyiGIpPAGgT4h5GqGS/AdFGibEwPWCDV0CMJTYgC xCHrkSuoH+J5zhPg0Fc+N5hnFqYJhGYVvLf88VFD2YWJjnC8RMH6CuvghMIZhAwVYG5I7SpP BaOdPd699bFm8t0rav4RIlcAFv5exh68pov33bsrfCI4/kh7cTCPYaJbGOKs+UMuoF8CDABB N0Z5CmVuZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgL1RleHQg XQovRm9udCA8PAovRjIgNCAwIFIKL0Y0IDUgMCBSCi9UMSAxNCAwIFIKL1QyIDE1IDAgUgo+ PgovRXh0R1N0YXRlIDw8Ci9HUzEgNiAwIFIKPj4KPj4KZW5kb2JqCjE3IDAgb2JqCjw8Ci9M ZW5ndGggODQyCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0KSImcVUtv2zAMvvtX 6CgBlaKHLdnH7tFiBQYMi29dD27spCmStHDcZt2vHx92UmzDNhQBZFIiP5KfSOVdnc0uvHCi XmauNFUUFn4s+ZSb4EWMhUlR1NvM0mG/ymaXcydW+0xbY60X9SK7lue3e5XkoLSXfbMY1E19 lc3qnKGj8Tk5k+BibnIRQ25KhgUAWA6Z/GatU/X9q5yCiSXnRJJLhcnR1wMC+kICAf0plYQg 1/K98k7eKR1lo3Qld8p5WEDtVCk34hb1tbK815JG4grFvYpSkN8GTDbKlfIBDw/H/Uc0e8Q9 Ol0vcLMB6GH9cAxFMMOYBBwBliCfXgVJZs+orRGhnXITxJoV2hnnPZDzgeuKXNcS/JzsMQtn 5RMqGCGBb8IqQYVkEgRMlIsedwXYww55YxIJkvCS1OfJXTBSw3foSIfzjkIJDgDnLW5qRfUn hljTwaAgxB6sA7I0gbyqxxZhqscVdOMgOC4MY/t8Cgbl+cQEP9K+hv0CyNbAFdf+woyhXU+H HGl2MfYbNEnlPHTNxOAU0Y4Rm5446ahsAOyYo32zhS9mwnB+ggtlZDTL/qLBWiv4Dli9aHZU +gNpdyR3Cu+KzbrFE+31HScKIU2Zkv/tpv3ETMFxoMOwXTTwfOh6sWleVCKecij8nyNWxGTK /I0zVsDc+2nG/HHGxl48V0A6NtupzRbMpMK7w15kSpe9AgLIaostfupYcUmczBUUM9cI+EXp ID+d4ejcohW3uNhNHtwg7akxSRQDobMLAf+57fDuFzxGpey3EK+hBDaYwPoHX1o7shpGbiw+ gcQNSa60SG/hK2TqF2K9j38ntoIsSnAuTToyW03MusDM7lVAFjV1UD4O71cFrX6hcnjbKunx 0Ug5ruEMGwS7LLL5ApdB4csSgXV85Fw5gjgUDTo4WuP/1eqcqfxbawWoiv486AZKvoEWpg9G eYnrQM2tUVyTSKXzLhnQEVTBGlTqg3zOqSANZEDXeSvvGvrsdjzWmxMovPYjMJ+1o7LigVe6 YDtLugVrw8G/86tJHH2s4a4KmILX69dLIOMKKr4XRNQBeBOfxfWNFW3mxFoAKYWJIlaVCVGE 3BmbC+0L3Oy7bJ79FGAAjK2fKAplbmRzdHJlYW0KZW5kb2JqCjE4IDAgb2JqCjw8Ci9Qcm9j U2V0IFsvUERGIC9UZXh0IF0KL0ZvbnQgPDwKL0YyIDQgMCBSCi9GNCA1IDAgUgovVDMgMTkg MCBSCi9UNCAyMCAwIFIKPj4KL0V4dEdTdGF0ZSA8PAovR1MxIDYgMCBSCj4+Cj4+CmVuZG9i agoyMiAwIG9iago8PAovTGVuZ3RoIDExMjEKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtDQpIiYxWS4+jRhC+8yv62B0NDN08bJTTPrKjXSlStMNtZg4MYJuJDRbGu3F+fer7Gjyz m0MiS1BUV9VX7/b7Mrj95JRV5Saw66jIVSw/T7k0xyvPs2iVq/IQxDwct8Ht3b1V21MQxlEc r1RZe8qp8nvwoD+ZTI8mTPRgQpvogzy1+ipPy6MPpNwqTcxT+SW4LTMPn0WZIwAJm6dRqvIk j1zqsQUlBoB+jGNrypc3jns9edlVFqVQS6K1V4tiWywOusI7+OhcIk4UK31vbKaPJil0axJd G5foztiV3pjECRXOvAqPPQ74uBhb6BtTaPVgrPMiO/Ao1/e0R0n1DDZN9g3YHQ+3J+PW+gnK qu2vmhSmXotPZUIX6zvjrPeTjxCevfsD5GeQikmMVWgjycXHYK5DTWLt461NLgC53u9beY4n I/lX06CMmH+WRKzFQyF7ko2BUfmcdq0wUv8BxZMJCz3B0PO+48fOOCf1xTEke1Gd1ADmxoSZ VpBVhIN+TaEzjsduuii4NfST1/0L7IkRe/TBR1b+4nsruXbZygc1GgtcKwkTKBgp9LeqnwhM O/WukjYUqarm6YSkeUEqdxA9EZ1a/K7FouepR01tYERmpbdiNCF1w75WVUNOg4J5oNZrnjzI aZaj8dmT3kts+DXQjcOr/83bajqUkxHbuZ7WXkN3bNijOGCXz1DcOJm1loYCd4JbFbkTG3Ag G0WmmBrEifVc3b6mIC1dKHc0zFi4TMSiLVz1Z3tBGE4/mquJ2RpRd5RtyT+/6jWeLX4TZ4/x unSE6Lc/93H4tpHtvFnqQZKVaj7OfYdXXcHJFE7mdNIBbM0aSu6lB/qeXBkpQKZSPR88huA4 oo2HCfy25otWh14dPG9XcSpgwx+dpAEOniDCzxW7Fix8U7FK9t7xuO9aeTe+O6XBpx2rLrOf MdXiUC0CA7mHw9nM9eIGKTg/GU1N3cBGir2C7B5WOpPdA4T9DaJSkPTqDSxdYf9Ppivx9poN 5viamRDGffDoP8kRDzZge3HVeAUJTOaFjeJcStjfSkHJBO7t8+uduPNFNviLMGTdf1c2Vr+r h6dYNYFVnQpskkVyExVFlOQqSW0Upyp0GZhjG9wH78vXe2Qt9wauA7xtnOEiSOM8wjL8j2tk Ha3ccv8JZa31yi5KqWyX+++HGi8LqTRYiIi2VcfdWJ1kAObYE8NZYuPjNglTFsZJGjO9GcYD d1lDlgQks5dyYYgp2SUFOhr6Fmsca7IjPRh7teOhyNl4M0y3+Je4OGOtY5f/64JIvest8LG9 6/FynDAZ3cBbusfK5LyjgqrD0QlLfaxwPYjWSDmFFv5GskKcW+id+d3+yknDxHfs0ckbCXPP RPjVnph/VzN2vyBR6LVdbZYuISTLYME4ZvL8/MI9WOMGkuzIFa4xYUJ2fiuLkAx8i3eLxu1x hrRq4Dofc+zZquKr8UMmWffzvqaVgf8V4OmrcjuLgv4cflya/R8BBgC3IR1sCmVuZHN0cmVh bQplbmRvYmoKMjMgMCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgL1RleHQgXQovRm9udCA8PAov RjIgNCAwIFIKL1Q1IDI0IDAgUgo+PgovRXh0R1N0YXRlIDw8Ci9HUzEgNiAwIFIKPj4KPj4K ZW5kb2JqCjI2IDAgb2JqCjw8Ci9MZW5ndGggMjM4NgovRmlsdGVyIC9GbGF0ZURlY29kZQo+ PgpzdHJlYW0NCkiJnFdLc9tGEr7zV8wtwEaEMHgRzGVLL9tKyrJW4pYPsg8QCJLIQgCDh7jc X7/dXw9A0JatiioxNZjp7unn1z3ni8npO09ptVhNdOzMI+XSf7Ly9MyZeyqKQmcWqcXTxMVh vZ6cvr/Xat1Mpq7jujO1SCe0IBm7yYP1ebNXFxt7qn0rsWdWSSv8+FZmTyOrsENLnef2lI6W 2Jb1urG/Ln6fnC5mokzohB6uw0JHgROoyI8cLxBN+E6+0Priutpe/DkyQ/joj56FTsBsvhOD bXpQ84J0O8f9jT23VEJLUq6odsqeeq617Xh7k5dr+a5WrKVqiEyTIQG45CuvSpWCvbZJ3F74 bddqK0X/45PkZjUkFHLTXj5ZygltuJaC+a6aaoc0vBTXajbT2m3ydPMbbFxEYmNM3mAj+a+O XfZK5EbOzPvWOZ4XHTtHO66wykrP6Z6YmIcY99ceXHX2XOXLRi2r7rHIbNa1oVBqz2oasZ22 aju29luyVVutrWOrMtH8sb7h3OOb36ZvOCc3eT/Sl8PYKApZbPG/wp4GVpVA5SVHFCfqqaIQ 6MASk7ZsQZWCaLCOLSlh1NrWFCLP46A2WyGA4bnILUD7vxH7suf4gIB/tr8JshvPOM4P1heL boYSDjKBr3JskmAS45qOb+1pbP06rDjxrJESvy5oHVNO00UgOL3n3wsuuIXtG3ZKyctLKHNr k91fbJh/wlepdtM16rGqmpYdtM0kpny+er0uwwh19nfrMox8x4uPgogCHSo0RoVSJOA7dnTI NRbAdIKRUv6mBCkZ/WvgLxCPaPeIAxfhij8rOpnLiew+dUWbT/m7wxH4WVzN3lPbA33VVnyV SChsPTc3UpwIQYr8P0atm3f3z4FsjuLtDVXt95YydLKlVDGhRZDpEWS2qsOisSMrEw3vLi8p gN7MOmW6O0Tw8iOCc/Z6mfkhg/gby8wPuBGYCHmmzNy5qL07rRSlHHCUvE85RGlDzm5rQrUE 2Li0uRxoMQXUUuHNKQy8RGnkDVJNI9V8i08d8RsdVvWBEICjDeA0YEmx09EFtWkjFJB2/7pD PN1n3Rsc4rmO7/3YIVBWveSV2rRAdhCZzXSldBayAJ9bsbGGi3pHPDcON5Uf2jz1OXvmlOXe C46fwvNzdC/49/VSdmc9sP6tUnaDvvm8VMrnQLjQMgWLQsxbqR614jqrbG0K7oZ2Z9Y79iCV 0W+vxjOgyLw1nEE8N5PBEE6o7YvaHAb4fQe1R3Gkan8W96p0iNp+K+3eM3GqyhYs/6VYtM3J 65bMIkdHbzWFAuH1Mw73VemIJjOTNEUby3qMhOdbKUpuDurpsK4z0CIphQ3bQjGiK8H44bNQ pzVwa8+bW/4ZS2dRCehS84v+RatC6qI26Nen9eGOV70WaU7fN3otcp1wALgBmHUgbrvjpn4J pL2U3htZp3e8/EgGnOFA7fDnlAyQZKCSLlcYDZYZPkvqwC3NCRgT2r2kCD7LpXzkyBTPWtfo d3lrEzDs0Wd4MOG9SijkgpZgEI65WpDiIWXu+PfuPXnhdzL1TwUP7ZR21Uf18NVVy4lWuZpo agqRiuZzx4+UH8AjUy/kzTqb3E/OFweUOHI5jYlULwGNmt+Pbt+BRMyQYJ4TtNLkeTB7TgBm 3T8njoqPBbPvP5Xc/sjkv7jrdWbwluSNyAM2KkxIEt5vEYF2c6BUT1kmhBjjiXDHQ3cySFEP 26SfdDQnqE+pK72Ya/pAaIRg+6vMDuz+KXcDN5R5zou4w7MFQd8XPDGFstG3cXvMohmtCd1U mpT89xcpFkaVGyJ4x9PqPb9JOj5t+JM8wVbS8yMGqltbpE+dtHKS8k/FkiGx5FWWQmZeDTs0 y9AS/PW04x2Rx5L+SToGx+1BnoJUeNQwaYLwI86A8Svwp8Gn0U5izwvtz/h54UfRUdyPn4/G WQhgxGqRxqu8NkMZxZdyM8Gc28gLg8lKu495xLMTM6Wg4bb6ZIu5MbfhChCnGVyk8Ig0b3CK dYtubCT1G9KOPAoKx4TC3jVGoO0K2yec39C0dmHGFdq8w/KWGGTzhBRRojvfPHoEzA+PvQGz Tff5dHMhANNLDEiib5nNZYU+mdlangMU+l9sgC7AuKsZxXm3Lfb0YhHqGjaKm5oOW9v+qFWr qsa0AthhkrIScbk0gVL8tAE9OTspCtMoXlCwQYrD1MU/zOPMFHgo9lXPzJfZfgS92EF9LNYI DlficyZvMKjE/kuZvoJ22M1SJsAEDQY5Ilm92AwSE/ETF1QlSULfYEjACzXwZNvZ3mGwYijg qw9L6ENvMp7BmbIR8Z1kzEBVDt+4hHNSdDC30WoJyY8yvenjt8LMP04LrKJRgcx6aRJuxKwi jyAn0tZEjMSWPy9qdxiA3l7VNDJ639f1t+mcr0wgWFVCIh4SSNkiT2WLe1pzyD1jUlcsQcaF h/1rpDDnmRDDlUKMBE468cmGJ4zSOCJNSDrklJTh5j4OMUTuZNwYrnrM1FqghqhOTFW/XLNR b6QZdB8xKHbc8AfR3Iw8uanBBW1eFKqUkTJbqutb83blyKl0g4OEJwAeHAwdSSiEBoJWBuN8 qxb0MxztT6PtxcPr5c3R9mYz8578OYxfM/oJvGYHVFYlWQyIbUagiyfQtiZA4BMZm2JrhEcG FuqkBMXa7stamsDqkDZJhx1iE9JW0itGeqk2EzU2pTAW1Trv8RyXGLgaulByUHLIXhpvtwW2 xrKbEb4ToajBXSLrOxhf0G/r2DQm6kvLw017wTgqlWS7FQ3pDrlf7hBhYnwrRoxLg35Hfk/x 0jQ29VEChBjOR6NEZxiWZht6zIdWLI1TiZs5WFxmvZ/Fan7ijN3xgzw0OeRHbx8lQp8Ry/OD 1yHn+vZ7jADwS+sbt0gprarsV+zPZSXnjbr941oJHlB4r85uYfuJza4COaG/KXgDzpl6D9y4 v58a6usR+mHs5zi3oy55hPwP1lOWiqiGWj219qkXmyukicMmEVdQh1/lrcoF/mnSuTqTAUTx OwhMWzMt0Ky7OUDwCG+v/7gCjDyD0Bvgam5tKnFXIZlt2J/7OeFFYNR9JEyvv7iCiDubwHiB Jb2XQowKkXV1hz+Lu6t/QQUcnRG2/RufC1L0gzis5ZP9Vl6ODXdSAgnoUaMKdgf+Hl5kmDeP TfX+HnI4Ktf9A+r/AgwA8QCbXwplbmRzdHJlYW0KZW5kb2JqCjI3IDAgb2JqCjw8Ci9Qcm9j U2V0IFsvUERGIC9UZXh0IF0KL0ZvbnQgPDwKL0YyIDQgMCBSCi9UNiAyOCAwIFIKL1Q3IDI5 IDAgUgo+PgovRXh0R1N0YXRlIDw8Ci9HUzEgNiAwIFIKPj4KPj4KZW5kb2JqCjMxIDAgb2Jq Cjw8Ci9MZW5ndGggOTMyCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0KSImcVU2P 2zYQvetXzJEsKi1JSZTY3nY3TRMkl1q3NAetJVtKbGlhCdnuv+98UMamQJK2MECRwxnyvZnH 8W2T3PzmwEJzSGydBQ8GfzKzocpKB96XWeWhOSeGNy/H5Ob1zsJxSVKTGYux+4QmBTRPyQd1 N+i0VK1OrVETjhWNperZcILbESdWbB1vjzw/8nzRqVNwzy69ztVBp+iwRdhtvspnpsBJf2ze JjdNEBYlYSacPLG+yArwuc9cIRQILAFVfxpjdfPpBX+Jw4+tyqygsDyrOYyImitRG4lqr5Cr Ve009QzuBNoZdYvzgoDmaurG6bjoWkF70WmteujatYV1aNdfIuxaLq8RJt1OX1sbguttyIL7 J2rn/NeobWYkVGY2IMQag7mGFLxB52o5wf4GMS2EHfY4OnXB9fPjOmMVnOVVy/bHYdxrrJus Tqdn6PprAFIs1BdZd4CRDutV4xbxn89IU/bgM5/a00HP4sfzv9jM5w/axjumowTdACfIQGoz a+oKmnum4q5UcqGCuUcpHOd1bHWUhsPrJ0B1YDUOOmD2o4IQS8/TRRu1sv8De520DWpcBtmN ZPa0P2BQDJ9k9/TDypUhp1L8v8qVwdEnVs5F0ZmwFS4weFSaU+vA4DkBbFgE6VksmIOHeR2A V0S+Y/cUj3icx2ldYObsUJ1slMJGWB4cekt6/wXnihbfolx8n3JV0XvbHlq1PbQ6PrSWugC9 fx/HmQwrPOAL7BklnNmn491o2jJEFkCxB8U+5yhA1MKBz7mI+/pEggkSJweNrMTDQSLErxcE K9vYd8/2AbG0fMCkN5j9pi2j+H6RdPOT0AyRZnySD8/s0tJI4bWcjuscVb3Kd/+ZdxDLD5te Wdpr3/4PTa8sQrb1jdjoXpECMu7fx4zI/MxzbnabBHmx2/3+xWGqA3d7rxYWK4lqRC2SxxtK +D3lflyi9OBOV9gzKyW9kTv+jAq/0OTFsS/aAfWC9KtmYKJU9kNsxjWl3fPtufqVGhUw0JWs gxSUBV9jq9i3K3lQaSnjvODmRl3kIJWj4AYhv2M+O516BbzFjhOPchv2sloJho7/zs58OBsW cWmPcUm0XxBzW5fz1y7nhdiBGtSMyrqcF23Ljc0gL4Cqcafx4FtOWscduKVSrTyS0jEUmnc7 vu1Vg7eUmL6X4x+vEcVbFMMn4Bf9BNbAe/jw0UCXWBghsXmJ2vAhZLmHvOAnnLqSjJc+2SV/ CzAAw8HWXgplbmRzdHJlYW0KZW5kb2JqCjMyIDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERGIC9U ZXh0IF0KL0ZvbnQgPDwKL0YyIDQgMCBSCi9GNCA1IDAgUgovVDggMzMgMCBSCi9UOSAzNCAw IFIKPj4KL0V4dEdTdGF0ZSA8PAovR1MxIDYgMCBSCj4+Cj4+CmVuZG9iagozNiAwIG9iago8 PAovTGVuZ3RoIDIxOTgKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQpIiZxX23Lb RhJ951dM1T4ssGWAGNyxebJjOpFjpxQJtS92KgUCoIiIBBgAFO18/XafHpCUI0uyi1Xg3Lqn L6cv8yqfzd/4Sqt8NdOpm8XKo5+MfF+7XqjiOHKTWOXbmYfN/mY2/+laq5th5rmeRzvlzKGR jlR+mH2wfrR1ZHW29q12tHVq9bb2rMaOrbva9j2rUgs7sz7ZnlXwdMsHdxvaxq6yHZr/ixe1 /Xv+djbPtRbxIjfyIQAGOg5dki2IXT8U2UgMjyWwPnqetvM/zxQTOvrTSeSGTBa4qZCRBhlI aaBFgV9srUkaHVj9kkSVke2TDon1N0+wUtGWyhcs9LtfmWKRQ4GO1u+OZAqL70jb60kdT4RK SXyWiv916rEasc7czP9SG9+P72sDr0AhjHRGsqdEDKcZnfxJp0x0Osw7VbKUa1Kk4EFrOyRZ W/N4o5ZNWzXtzaA+WiT7cj+qw1zhXEUEFc720MqhtWFwaLwxE9vnj+P75D36jA0uugUN2I/D R/s5zvQw+Zoz46850wvdAGQfrLHetPWoVl2H291l0btlt33a9FGaueDxbHtHaTpBT6BT0v0l Y71r2xowxmy0ndAiqzo6tG5sAMssrrthXH4mQdkZmr3C4UAbQk00KUsTYLaiCbTSlsvRsQQF 7/S049LIM7fjDPgQcchLZH2+/eSER+yQhG4UH33wfGskgTuBT5s4Gij8EwjJ8ZOw0pFAJKe1 jKLCp6hwMusHbDx8PF9QdDm0QeH1tPTRWQB9Q+xE0XnsaBM7Ro1bNvAy+uNG3DL+ATP3MCmc WcHicNcteUV2iGBoxUFbnPJ3OMbMGnZOWz7gZYbE5LUX8KnCHg1WYNt1xvvMqzgJglXhSKnX 2n6P68PI9dPvzD5ROAWhc68oeKYoUH5IyVoBp52YLRZzqicovLwkASPLuYLfF7/RYmC9kL1D AZw0SDMjvmoFzTtm0M+xdMfjGid7ObrioEot9RLMLglLDqjMHZfPsEXguf8oK881hZ9xWjoH E8qjb6rLFcv7ij8Ouf6aDfOSyt8bHizIQvNLHuHUBR34HwkdW3OupLdHBC0jsdAAaA1D07XY U7cC0s9KdHwTGlFDN06CjETNX4s0gQE5pzAWq+1gnFEstx/gFWLms7eEl1GbAt1LkxMrqZ+O qTrMSxUjUCcyFhtMNl9UAOQZNh4GOksYfJFOJts9Vs89xhoMj5FPFSBk4ql+TPaWME5FKgky P0T6iSn70OfayEkwOdhOEBLWyJ4bmEK+atdzRg2BvwA48xBonlkRW6WSbJ8ucpHnm0D5po4l 8jxXHxOsKPSeavCF7SSsT4aZKotWDTTYmQK44iZEvf71WnEbsoE/Oh7K9u1+Z7KMjfpOvGo7 tKpGhuWI9RFkaxvlnMGoyk1Tt2ZTOAnePOVolw3/msQr2m5c1+AEmZgzZnf2xKiHeId1U65F 7ONOQYdvB7RYrNw7biNEiQL7baWgW2cbuQ/c12BUqZeXzpk4R8iL1a4oHSyY52/z4/BSLeXa 8VDX0hgddeRJQded7CkacyL2rGVxUsQU4W4rA+y7T+eakIpW/O01K6SaFYdf6/feX5Dt8vfS wo1jgbxo+jLq04Z9eVqRNg6dWjVA3kVOvAip6vx79RNJ+JbE+FNB7gNFn3qvPvzuqWqmVaNm OohIkzjL3CBWQQhpHT/ixb6eXc9e5WfBcc8S1PlRPx56MWv2VGykbuJPzxQaaTILiH1OAkSs p2cK2yOcDGNy08JGy+RwWSGfsRksdVUPlFRL3ur6TaEONCt4NihZFOhm7OeY4wK4LZbcsHS8 vrc5QfDiuObFWhU7/t/x5oY3mrLAAcrUEisOpy4qjwxRz48ZpSxmcGwkuVenhFPeNnhLAVM3 fD/uIDEoZBKkaKu/q/t/kwi8oHIJFlJBlRR+lMYlG4PNSprzgqnG+r+8ZNgVhHWNVl+btn1V FyM48jqFMq+dx7mOwknq8FjlptSUUmoKCYEsRsEA5P7k9osE+QAGgpDqS3rvtfkdYAhCzyDp UTC8tVOg31qtqFlIrc24ZR9REmVxBQUOP27Yll3fS0Ykg67Zr9BppASk4Nk16dsMoBzE5ZVA gclB0PF8f4RERQRqPTW93MfI+8r6OkAm+WORvybOn3Z9PQybz1KMgO56xX4HzFGyUroKUrII x2P5u2t55OH9wcsEzdc/P8NFFGmmFp256Bu842epeWTc845R6ufuYCwRkU2k5kZW/4J6JCoV R5VaVmnYY76z8UHVLnhvbEhXUeoGYXmBpmqoS/hvJer2VFxSbgRCqi1sHcP90QCdXgdTZ1uh ZRjKDo0XPeRCXOyz2CHFsc8YcUiEZU3VBXXQmY4cI4vqXM/fv7C8xzMxI9wR1OpKDTUHOPQQ uoI2tzWoC6MoRy5amQfj05eswpFOXZ264KPcFw+mdw7k7aiKPeLcI5YQm043ttQJVF5qEDHv UDJa5qZkvMLto6Qt1BOJBLmA3yl39fRc0aI4+ySWYVFVjOJz6e/nRLb0EhmI6muNrITZnc1x hmFrmjK2KxdRucO0N2wfjsdYTMgNEJd7yvSJJMNWCMcOZ/eDZDshvySUINcKepr2xHRcN0bN 6CHboytOp0bUtNr1J8aiPHQp31jyMNwIaNTpeVfjRCkH98AvQ0eWpceW7O3gSSliaGPRHa92 sgXb+PyEIpUag1PaEQ3k4Yn3mZreqNMtZxeCYjTww1OhMc9NJzXsJlbRJCMMkv/nfodirABI dW1Z76TwdKujw7Rgk8yNQ2tu7dq23rBLBk4D66JS1F3CG6Xgb2s6GW7IGZY7wdlnW54xJK77 WGbztZtxs51w6/LdxSdI3ITeMkn4j9wWTAXSN6UnnyLFs/aCnnF9Kr1KEtEnrKCH23Jh2G1q 1Ris8QF+0pSdQLfHWaDxrq6OrxFq5f4vwABUHdgKCmVuZHN0cmVhbQplbmRvYmoKMzcgMCBv YmoKPDwKL1Byb2NTZXQgWy9QREYgL1RleHQgXQovRm9udCA8PAovRjIgNCAwIFIKL0Y0IDUg MCBSCi9GNiAzOCAwIFIKL1QxMCAzOSAwIFIKL1QxMSA0MCAwIFIKPj4KL0V4dEdTdGF0ZSA8 PAovR1MxIDYgMCBSCj4+Cj4+CmVuZG9iago0MiAwIG9iago8PAovTGVuZ3RoIDEzOTUKL0Zp bHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQpIiZxXbU8bORD+nl9h6T6cLXU3tvdd9wmu oaKFisLqvkBVJZsNSSG7KLtAe7/+nhl7Q+i1Ja0QyXjGYz/z7hyWo/GRFUaUi5HJwyIVGn+O staEOhZpmoRZKsr1SLNwcz0av7kw4rob6VBrSKpRAMokonwcXcq/lUlkq4yVTa9MLjfKaLlS qXyoldVyLiaqkF+UllNarmnj3S3ELBUqwPoPYlr1sXw7GpcmcvCSMLEMgAmTxiGwRWloY4cN MDQhkFdaG1V+3jHM6eHLZEkYk1oU5k4NFhSsCsI4A94pY4DGRHIzA1RHKQsbMvkvLZgzh0iU EwJ98p40JiUb0IL/sFUTzDyBtReDOR5UDviEir5NrsmM1BRhYb+1xtr0uTUcFTaIKVMAew5l Dpq3yXibvEmPY6GslUJUFIylMnA+iEYF1simJvpWzFbNfNVcd/v4XfPiR35Pf+R3HYcRq13K vr5t6l4s2hYgtAxn001YteuXvZTkRchn7O2aJM+HLBlccynZE20D4ynjeNWrIJZXEoxYXivO Ac9ctl0/++q8NThvTQKnDZ2c0ES8WmDBVhkZUiLPWIMkG0hCUNrfznv4HCjHxLpSfDu+XvZD FodJuo3B/t7IonDIE+Pzo0OlZgySUj0joxPJKVOCVyCBLRI4KORfLPj+9nKCQgggQCW8jD7Z yfVfSPMk+Uma35CDZ8mnaxeW/hO7ecMu5WDO2eMcrhtExUmg0DUuQGveZe94Gx22ouA01Xei TCkxRO0Vx1SwDMSCj21bH306a/oEhLnuRHRJuf6d0MdJaPPfbBRJPBRh8Kx/a9+/OxXk8FZE 3SElj6XUlZEKB2cAmMjgnOM++QBmJF852eOU8wTuQifs+VMs2PKWDtiMmfVAdM07N27rgooq l+KADztDLgWs5e8428MXkQ7/NwH2dYUtqC35ZLLDHCiGOZDJ88MAvRypn8kDLI+ImCjfJSJZ nrAIprLt8NmqW9Zs2RwlwxW0duuum9KUuPYrhBnzoybWF26AFZFLKE15Q4ONz/swVzuZwIQp MkqBxGSDBT8bgJoizuYzZdGHY1LedvFhDHIiRH6QHyqLsl7TBGPsPfLfwRQDtnjAZlGYOL98 /XMgfgsqNt5el7vrRKNsinRht0VycU9LzF26F66GWyOkjWB2pyhFTeq2tgvaJd7Rw+NcRVoe ch6Bd0G1dkD8I6J4Wo/ptDNanmPbMW37Z4+Rl2jry+aXnhqJ1qHZtltn6SlCf0x5U1JLpZWo po3oQNz5cbggkOL1+wtBkG+5xloinfjm/s73HOJt6KwaWTlfObLqmd+z2pJIyjp4q7pd1Y0X upNcJLUITAjQiM2lnDZtv6z5JMZEJ/PqQQ0HbRje43JVLR3srWSKzTcdv43IuBNKF2fElOXN XLBtrfK4HynlmZqLg7NgBw6hGRoTTezzCTfID2Pa7BdndEmoEh6rCVOvmPIZehQPEY18evJT NR1KPXURmd2zM3ruQngkBZEd8DYsgbOiFHJ3qN1W5M6hT8PIh1mspze1gCtFtZy6h0aGZxb5 YvvUoingoAYFzbVndkfDgb4gq2VdcfO8ofHbsQNEd185Zl3Pvy3LlNvl3jW5tWDogOKUBtMx de2SCub0Keem7GXq9FSehV9X8D8NVrHqSFPMazB6+qie9tNyzkgnJW5DYYndz/M3QPoWoD4L bvCPaFriVFx+1GIOsCsxMlGCF0xaFGGUiijmjh6gAYG5qUcXo8Nyp5afjQw8W/Huj3VK3f+l Us7DzA4/h0AZjA5WttQ7oWyGn0M7iXThhqf7F3f+hQTX1Q+r9r4T3e0KtTFnPm35E87igSv4 B1Pbc5LU1JS6wUX/CTAAhSn19AplbmRzdHJlYW0KZW5kb2JqCjQzIDAgb2JqCjw8Ci9Qcm9j U2V0IFsvUERGIC9UZXh0IF0KL0ZvbnQgPDwKL0YyIDQgMCBSCi9GNCA1IDAgUgovRjYgMzgg MCBSCi9UMTIgNDQgMCBSCi9UMTMgNDUgMCBSCi9UMTQgNDYgMCBSCj4+Ci9FeHRHU3RhdGUg PDwKL0dTMSA2IDAgUgo+Pgo+PgplbmRvYmoKNDggMCBvYmoKPDwKL0xlbmd0aCAxMTU3Ci9G aWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0KSImcVk1v20YQvfNXTE/ZLcz17vJT6CFo 0iZQ0AZGRCAHNweaoiWmDCmItIX++84HKctOkcqGAWo5s8OdefPmrd8UweU7Dw6K28DlZpGC xT9ZeZcZD2mamCyF4ltg2bffBJfvVw42QxBaY20CRRXQIofiEFyrN3ejDhMFn7VL1FaHzqly 1JmCX8l800/u5ZUOUzXUlV6o1/pL8SG4LFwqiSQm8XwWL1wamxjSKDU+ljToQDpM/WWt08XX kxIkDn9clpiYwiKTSxim6CiUsnZOkv2kc3XXdU23wUQXCj6+W93HFzrEZbN6izavVtplaknJ it1orMjQkh/Q39e4L1F77WIFOvRWFTrM1R+agqEZ0Gsnxy3tadCgOgm6oI+J7waBOQMGb80L UMCGCnjhEYYTFD7XcCi7EcYeNGayp/TvuhmMCYsUkcDGLcnJxnqsDLfXaMaCK8Hw/h7rcarm z7CFY64oekC8qfJMVecUa2OTP79Y681DrdFcayS1YhGZ6qmncNiW3HUhJCVa7rlZNSz590q7 SFH/YkzaYcrMEdpYTaFdV7ccfUNfxM76RHW0XOMyQoOjd1puhiPLE0k8xywpc/p1uaUGJTm+ fFex9+njip2xEiort8D6cgzOCLqJ6n4ey4XUvcQmXVHtQ02cq5h4/a7mvu3RWfJqZO8AfQfH CKzYqx2TtJRY2vm39oo3I3yI0i9P9jcD8Bk9xyFOD5Fj03chriLVasRQUhiGM+DJjsP8Angy b/L8yIt85sWEz6pnuh5QsSJLikX5vZqGt+zYSZqFvRVjzSyvoJoieAs/xNPyF14jb356QvXY JCKzvHALVFlML7VTej8kuzXRxHdeeZwQJEySsGA/nW+bSW0dp9JzyzFdUuSOnmInarcw55jN OeLwZXhO8duPE5It4TRhoq4IOp8LHQ9ET4IHPAU3DU9Tt2bH9ELuDRuGM0QhiR/uo2eoQhJH 5oiQO/YcuXlxItDr+pYYjHPLvfTUZlT1JRmx+TH3HrWtku0oAx0rearaAemPcj5/qWRrRwes 2QDjtu7Eh6tJ85tujXePfJTkF2mHs7PVeO43c8ZA+AXVJlg8Zxb8UWdOJHK+wZeatY+vZ7rE KnpAxTBtdUQi4LGyiDtH84uv7QBsbtv+gBoPt/SNnv17BoW9u92AMJT8pZGggZajR3h0Jrnl 0HUvxLQQOuNsnhHZrkWG7lCAEMmJyAQrqUlDaiQ6w7tIbEC0rVuzMg2z4JBnR9LXj2Kq5oAz kMdLJvmOhefCb51w8dFlLOC/1UibLStISZgIvzxJJcLKhJFbZjNwNUiapebbNZfKuF9WRLji d5x4pqN//LGBx7J8MLQ9H3vA5uWkFti5fN7AnaNNJ6mNNBDHFhU//+e987JWsZ8mZv63wk/3 024XYsNaefnn4fYC/PeJt7Vik5clC9wV3cLDSYsp5/nbjWaK0r5jHdfTJfm/FPm9wFKRCnD6 /PQe6fABe/4VmCoH1Gr4E66/WFijXjYQuCjB/qeLhYlSiGKmBvaUjPs6WAX/CjAA4ICN4wpl bmRzdHJlYW0KZW5kb2JqCjQ5IDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERGIC9UZXh0IF0KL0Zv bnQgPDwKL0YyIDQgMCBSCi9UMTUgNTAgMCBSCi9UMTYgNTEgMCBSCi9UMTcgNTIgMCBSCj4+ Ci9FeHRHU3RhdGUgPDwKL0dTMSA2IDAgUgo+Pgo+PgplbmRvYmoKNTQgMCBvYmoKPDwKL0xl bmd0aCA1OTYKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQpIiVxSTW+bQBC98yvm 1l2prHcXWMOxbVorkRpVMVIPaQ7EYJsUTAW0Vv9958OOSIW0zM7Hmzfz9mMZrb54cFDuI5eb IoDFTyzvrUk8hJCZdYCyjywHx0O02mwdHKYotsbaFMqdWBmU5+hRbXWuZh2naqzOfXWC7x8e 7m/vN/qpvItWpSukW2Yyz3hsuJCaFEISjE+lFYJawlM/rHW6fFnwlDr8uXVmUipLTC5lyMJf +WAC87lpdFBzhUfbTTouFAx70LG3qtQuUZ90ob7h1SvYYc6gvTrp2OV4oq9BM1UUmNvhBM8c aTUWS1KN6e3pAPMgkLfaZQynuBW13jEEEIFLDYzk78gzk1WzG3hDFmJncM4b2SlPsxim1Y5h kNpMZsOlI/Xaa+dUtWNHM+k1tmR/8x5dOB2Rbve8gL/Db77Wg0C9Yyzo2p8NzMemX1RUgIPg mjiD8Soc+czD9qRydboqm4s+OSpJAtHf5ZYUDTaYtf9fWO/DW2GdsVIqlitw8ByLXx/gYiG2 kIWMmraMkx8q5On4TqJ0DV+nCUjGgfnuMQZn3MxRi7KOHmqijgww8pycjjvgKF+mWSIVJeHg KHBPVXzHR6Jgmi82NamXHYkNoGYFPger8JWQQ/Kk0bBU3ebrq/AukfGm4+uABExiDacLuQPj 0IPl9h2RkhSase06OMpO/lwKnuUvJzOX+E7zQSah9b+6drpsoGZ6n0tceYa7X54PG6R9h2q9 AIt8BmfhKzw+WagjBy1ELslMgFAUJgmQpCxq7DNyjk20jf4JMADnxQDbCmVuZHN0cmVhbQpl bmRvYmoKNTUgMCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgL1RleHQgXQovRm9udCA8PAovRjIg NCAwIFIKL1QxOCA1NiAwIFIKL1QxOSA1NyAwIFIKPj4KL0V4dEdTdGF0ZSA8PAovR1MxIDYg MCBSCj4+Cj4+CmVuZG9iago2MSAwIG9iago8PAovTGVuZ3RoIDI0NTcKL0ZpbHRlciAvRmxh dGVEZWNvZGUKPj4Kc3RyZWFtDQpIiaRXW2/bxhJ+16/Y80YWJs1dXkQ95uIWbtDAqPUSOEZA U7TFWiIVkrIroD/+zDezK1G2kzgtDJPL1czs7Fy+mXk7n5z+apRW89uJzsNZpiL6k5VJ8jBL VJal4TRT8/Uk4h+7u8npb5da3fWTIAojYi0neMdq/ji58s79qXfhB1p7feUHxnilercs/GDm NX6Q4KEzr8L3ipaR1/vX898np3OjRYs0TA2fwwudJSGpEGehSUQFnIaTvM9RpP35XyP9hY9e epqGCdjiMGc2KBoZ8PIqF1XfNOocipC6GWurc9K25PeSdPeKppHdlU9KK9qKvLJo+FrqRn5S ZSsbPV18wBU7yNyWvK584y2EseiJPvaU46/+thSQ0vj0EIIau20jTEzSQhfFdopUoEO67fsj 2xu5z+DnOFxPvQI3aqx9A6O9Da9bfgoJSdaGj/TUZ4+35r723hF5zA5MvBN16Wd2Z047s/2+ T6qFrKB7Rt5n33kyEn/k5Dk4BG+dR/BgFmXh1Dx1pDHZsSN1GAmrrPSM7pgT8z4QyYf7uJO7 v4WHtnzXAbZUTUuepNsuea/Asrmr5NKkv4GJh6Vs8PcjR2YN5o6vWYFHbVZCwxIoSH4crenM hGn209Ga0i115qLVXotcwj6huLhApDVs7qocahchN3WzqJs7Fy6kfctLhDZnYkJOnnGYZV7p m8Q78Fmm1hqCQnzowFU0PWfwpuVPMSjffP7LyObrdlHRMaTbBwrzM4T9g5FzZYNEfKHIuHwj mYKoGZbFoDYdmNqDyk67xBugLPSR805/Tay52PcRIh/eT2DZK+/yEwXoR0tpDWsOVFOhutKU mtc/js40ixFu/y4608zgZaNzjzUOFgsYQyxucOeZc1M99LLZsZeIKmB335MFK/bCjlaq35b8 IU+m63u4h0h7srEq+Ad3QgmCJTHWq4UQMUsjv17CRW/IKP3JK6xCZUA/C+fXWiWZhsYZJbYp 6/CXbGKg8YDAaBlgOBMLhqlmp1rEpTacjzZLKZZyxIfQMKeS9daPPUvfYFmXvM2HDEDQyuKh FkkS88TeH85c2y3snPOh7+k4slLgEmAfkEaHcZTEh2BLJdjqW187tA4cEUA7yqdMKmRUBcgp uydwkgA4YERe6BkZj2xoDMqxOOBFKInC2KIJr0xEMAQ+bcM5OLL+zFof9SH1FpJvCL66U10V 3PN2teMXWQLxhYJGFGVZ8ZofLW10vEJJm5GgPQNZnnAGMin8QFbxBqiopFC+EyCY9FWlP42m tob/HJhSrcg4G70robRus6YiR3jHIqIwlf3gqLpYqLtmp150CIQW2TtwVSQgrhZcYBjcLj99 VB0oK66nZbVhnAbU9gjbVY2XZaUYbSoWeOpLyQZLKaybgXL7h6mZzPS+Nfvp1Ezo9S0LZfr7 NnqhAF/7ueTNBa7U+VKHtGebHMqqkhNqj/dojCgYEu8Tg//Hf/j15h1alw8KAoRK2FjCyJyq bmoWVRci9lX2mk5D/W/bj2SaORx8CeD/hBMFsB9qBttHSYjNqv/fKwI9ofrxvDX6YaAnWeSa DZfjT7SidoGQvqT/lkPrwefoQ03oduq2a9dKvv7e1J0vzTl9LbgRjpm5I5zVyHqOVfR8U3rQ j/yQLoJCm3GPW12UFsZMFt/wudQKS9dJILAp5HwcN9TwKlvobI4QI9uOn3/+Rsb4nS79l2In PhLKqT/U1XWkFhOtajXRMSW7ymazMM5UnLDTCF+w2VWTy8nb+cj2R2FBKEHgklBXakv390yf wz92PKKVpuhgZgOwJWbtxqMjtHVj0QUKCcdFqWCpconpYuVLEw7gRJPZVfy+se269LQohlgu pDgNoGh9jBIQxwy3rtZpb83Na43d1Y7nlvaWEo1BN+MpRSQsDyzDqGQh/amWccUyGZL9ipkK lNChFn2n9kCRz1WXFOmqlYjjT6stXwc9qhRm7N0xV8drJv0ql6yl1tteZe2acC31HKeeKHe+ cJRLFlU8rSSZcxUvNBXCmVFx5nqRvaO+5+40dMnGKx1PgbUxJWv03N36ibupTeEyScZeb/FC Wzug/hVbXtHW0rblKcwy5V9rFFneKjg1sI+IyBwHvvnKLLtYU//9fn9SIb0zPYRQQVzDYlk+ PbBTrJgaYm7cHmuwcKT8dUdfJ6OpM5oRVrn6mNsuBkneMHAvTvl1gOHvuiKOw+w/uyKOLGIe uSJ3GIjeh33BsU+69WpNy63PTSBMCkPeVMBDgF3ucTShZaFXh1GpIvrGJo/lUpyVt9IRQspS MDPHxJXT4BNh8MkIZulh/EiozkH/AauzL3jaDhzytqyaBd6ccFfk55L+ne86T3YCgY4+mm6C UdDRhVJOawZtqpD4rvEA7MoK0LwS3/N3s2Ci5g6vE1wupTOnAA08sYSwAEa6x2rHzP0WhCW6 v5JJDMMYigTto9CwFP6yoqwix9HxAhob6np/IjZeRmUzS54FhnE5auNijtq4lHmKceX8vYJR NEc0AIwtw2s2DwHc1y1qJAIjiGlaaAYGvkd405oO1PdY9oBbAeeWd5nx+VibmdyMOk87s55/ OONS+QDR+smEG+aUQE86MceMm1FDvnhyUADz5GT2EbB/8zzzCi+lh5r5H9yUvlg8n11oLpiG PlCRpl8IXpF/XFeaO9XZFpE6za8w8pa/a/jX/UTxuWaAqhpQDIr3H1t+dWhjyGkWR9tmtZPf yXNE7MbPb9THo8bLTVfnCIEPCIEziwSoVycIG3WztQWXtRyti9VKajtoHzFRSGtwKzvdvtIy 9dbOs0B6KvGjRqGQtS3zVE8bKdxlgXEFoDNGlDRxt0j2uifQfcpglQKsqDH3MwnpEyDSo+QN Z0t5yCPFG70PWGNibttvfVFWe6tDwzLOiWKz6TGDAp8G/nlz+FUIHzgZFy5baXq85XXbyV3m v4zLL7chW3QNy8oldOTtjcBvmiRs8xNYnYbloSWRdmzDGxuYLCBpq2LHP0rronruqaUDgt6k 1FjEDi1ayWc0DuXJm9XY+ONMzEfWv5BezVmQTWxDFn45hVAxjFoWDyPQEqCyI5ESrxTgfqhk dyS+KlVZdUOvFtVm1e74JLGwwlAk9P22XL4QLlcidbNZ1awcG9Xp1Bzwby1xgJkXMWGVKMXX 0gC7eLZd4tFNepkXhvZwrU3XDm6ejJHIz6xpQ9lOQvuIMCQy8QqURR5PgAIUHyL1D0w456hn c17ahBwGQENR3qsNfpP5qMds2uCbf0UPR2W7KroVPmuq+VXn5pn/CzAAb3KgfwplbmRzdHJl YW0KZW5kb2JqCjYyIDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERGIC9UZXh0IF0KL0ZvbnQgPDwK L0YyIDQgMCBSCi9GNCA1IDAgUgovVDIwIDYzIDAgUgovVDIxIDY0IDAgUgo+PgovRXh0R1N0 YXRlIDw8Ci9HUzEgNiAwIFIKPj4KPj4KZW5kb2JqCjY2IDAgb2JqCjw8Ci9MZW5ndGggMTcz OQovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0NCkiJpFdNc9s2EL3rV+AItBFN8FvH pmkz7kw7nkY9JTnQJCUxkUiGpKTq33ffLijLcRw77mhGxMcC2H37drF4vZxd/R4oq5armc28 RaJ8+kkr8BeeH6kkib00UcvdzOfJfj27evvOqvUwm/ue7wdqWczQiNXyOHuvr28Gk+qqUL/S Z2MinTdNtR2UsYG+bsaqX+VFNZiPyz9mV8sglLNjLw54d27YJPLo4DDxgkgOxhHYXn/wfWuW ny60lnX0sWnsRVgWehkvY/WsU89aUe91tTLzTLdmbnWPVmVCrYqWlKShVBcmCPVo5vRfN+ur vChkvBtrQ5+GZqxeKxP4JIoJrCzGum0G6gb6lVlolXed9NQOi/Y4TAZoZzqOrffV3Hqk1Rux D9o6HQfaozM+gUhrEl2vjA31SdHRvr4281TfmHnEUhXhK0Lqtm5K0likekhh8su+Prd3VTNC C6vVCmOtcYJq3FRykrGZG+JtJlgS7Sx8htf81Auc057nLz/ysrO7wsldoUDxC9nuA7VYQ5EF aUd9+Itd1ABemSiMFbkaf+KOSLOjcjKJVlWqGuDZWOcke7s9Cw8m0Zuq5B1lQcftbiD/0fwe Tht4c1Vs2CsL/RlHKx7cYF60IARjLceJl5c/PXDv5CnxBTTS+bh/Drhxmnk2+RF04/Qcvefz r0EnZoC6hbUt+3rflK8YWyIvD4BfjMa4yZkDrCmPlK3qmCbtoS4rxfxsHfGoqfI9MaoZa6Fm Du4Irm4fYtmZc2eYvhmupIzaAumcg+1UcczyZrv9ZUiNENpwdFbNBKVDJSPoAAu+NvORVeIo 85IHySUIkvtwWmRARpRbdkGqZbQ49ZLMgSoJcH7B2Z4DE65Fq67YzQf5OLOpUfBnYwI2zWpE Gn22iLxg4sggvRXt05IkiAVbN4w1y4tAgSYF6924bI+ktXCueQ4q4YshoazrRxMkUxTTBCOy 24/7HBfAdntS3NhT1hUooBi1iStWoEC4sxUcRNzecGxVkFAst63d0pGoMC1rSjWwTM+8OJhQ u+7ThtuFFyYvtd1ip8fYwN741zgfiedyNJu1YwJ7UIZK6TiyMH3Abvj/xCtVTVcoT655djzN +bKQ2BOWOAE+b5xSk9WlCb7NOny34Ml96j0nH1HuXjyA7emk5AcXKf/rkP+rWrdjLUmjaUfV VFUpd3DJStarcwqQBIAbnNPCAffsRYbIt5zGj/lpMJnYjhzhIsJKEYAp7OAubKy75dmL+76E IGHyNJGiLPOy7IVEirLUWwT3mITGQnAZobiwoHOhT96S2AZBzhXABz3xBlwBVVjG49TcgiVK 8oWkBaz1zHyhfzYw0i3hkQ8GwpRoR3UrRw7dBbngCdqTc8zEsadJE6WRlwY/TJooDbwweJQ1 14h0Ycbk0QecKNuKiQBWHXPKHRNiOQLvXNHxfVMzdbAN5xgfHGDKOFtTJo47C91KdYbrk/k0 cpCYmqqASWnUd5SttnRz8txvS5qjkFCX/3+/JWD+IAA+KebVUVlf/anef/RVObOqVjMbxl6i kgUnrjBiHlFtg8G+mr2bvV5e+OEeU/0YBXLkJ+DcU27I4Cv3KKCWJcLy4sCLeLGdHgWwL/qq 0rm+If5ITi6ocuKXAFg4oH5VeV+pnPu49JD9b4F8C+bt0RpluIZIg1F6PRgqGVZ4VTx8RNwz MrAIpTCLp2p0UvNHjA1TFE9hZt2L4p6x9quHD4UO/FrBNjxyuApAnU6xwzNHoYYbblBobTFe FznPo8ImKhoqW0tJRjxMJlOyXgABGhs6/rSQ6l39Y5EJn8aCoi9O/jcYie9S/nfBuFO4hKZU aEqmJh8e7yBwKXcyQuyRpfxgomdX2zv7UK7yVKmIVtS7wjiFvebeYGK8l76DgtA+jMKpdnsR CsL/MPJd8NxD4Xz5T4XP9Q0pnqAG8C8jgI2j0neXn5QDhgQOdCtXjTpyYd1/lpljTdUevSmk V7RoN3J1G7euQKpHpSc3mszwKRU/XOQshoZ0CwPyEV6efpDw4/Mb3hu5jM+boWv5WO6OXK4D 51cmFa+xVyhUdbFhL+eD+ucNWH7zih9L3R1LmbCHKZ6RTkm9knehOOjbrr+by0GOsTJT9vRZ XxtHk77n+jKcQg9pgbLDCvBwakiRm1OuM4sNAimgm59s4haFHhZ0XDay7M5Vn4E+Kb7pGp5b tX3h7lqQdCPvyPPALfdrNJvyor2+1PsC52h6IBAW7Jsv+7qvdmdX4aphrMSLcHvJ7dzQZTTm 6z7fDVTkOjm+tly9ax0X+L8+ELS5i5vkMRTdbYSgeswD7n76T4ABAFjmI0oKZW5kc3RyZWFt CmVuZG9iago2NyAwIG9iago8PAovUHJvY1NldCBbL1BERiAvVGV4dCBdCi9Gb250IDw8Ci9G MiA0IDAgUgovVDIyIDY4IDAgUgovVDIzIDY5IDAgUgo+PgovRXh0R1N0YXRlIDw8Ci9HUzEg NiAwIFIKPj4KPj4KZW5kb2JqCjcxIDAgb2JqCjw8Ci9MZW5ndGggMTUzMwovRmlsdGVyIC9G bGF0ZURlY29kZQo+PgpzdHJlYW0NCkiJrFfbbuM2EH33V/CpINFIEamLpb4l3Qu8RYtg47fN YqHI8mVjS64lJ83fd84M5ThJgRhBYUAmhzMkZ+bMIXk5HZ1/csqq6Xxk87DIVEQ/abk4CrNE ZVkajjM13YwiHtwtRuefr61adKMgCqMoUdNqhMZYTR9G3/SkUV1b3dV9py6uTK4nalrvNp35 Pv0yOp+6VBZLw9TxdNywWRLSSnEWukRWwpyYT99EkTXTn0fbFDv6s+M0TGAWh7mY0S4sTLEx a2U/v9Me1qu66TsT2EirX5QJXKQ7Q52aRKneGZvoe2oWJHDoB5n22vJXm1R7e3Kt3fY3WnRI cGaCQqsJ+lfXH02Q84o/jNWX8B7yvz7cmMH/RLzIyV+4gX+bR/A7s0VYuJfuO5c9d9+GkZhK yxbka07GnDMfhJc5uTTsG210bqzVrUngJLVqY2OtKnwhbEiY0zeRgQoW8JU0yQMYnBtnKZxd z7M1h7G3vYvS0OXv9S5KwtgN3rlDimNx79pQFrfGcT4tbZs+q7kp9COnWt2umtmqWUgHjsfw z+q/u98ABqdXTc+ChQyuesTLG7cioyBh7raZczdEfH6lJLMpRhYskvm2YtP24QmwTwsb2ld5 fxP2aZ6H4/+IiRtgXwD2JtOM/OIY+JYDBQxQ3O455wT8DJhItSgvvDQD7uF3Rc07Fgr8rdc8 M9ZpmXlyZWgYNTCm5RGTH4aCccnNCeY+rRDScRK+Fynp+IgMbDJEheLPUblAYufAcG+42mO9 U1ULAmgOn7rqTUyoBq4dIF/o0gBWDiVhxWyLSvd65OBJNZBmUWiz93qWFqF7xnLwUNz6amzG OXW63xHrUN6Jme5FMsBfdT3yU4qaCRK97xRtPte37Z4qn1ydnTdtH4iEBc3sJL8ShvM7/UqS MM2e4RiN4uDZ2Jc1eVawZ1Y8s0xcVi+p8EvuN43I1wq4O676jiUzUevLU6oytmH8KldvV6U7 5uH/uyo3exb3hiykWdJU6/Wjwv/R4PJQvg1Fp1+heqHSm8ivovY8JXDx+fo6uLia+EpGaCIV ECep6Qc54uMBbZ5viRJxNj4syx57q/nopB0Tre74kDwzY63KZnYm1IkdraDZQEex0ZLVeYhK CXVo+HSVY7jjPXbKr1TOeVq/mtWyygPqrpT2rPNr1f9Uy7LhGRf1sTcO7jyDWC7eIC7NTN0D IT4DdHhQDh4pdIr5PQO7U70HWyjtWhZVrMvhFrMZ9J+ij3k7AeiQDO6qds5a/RIiBUgIRZ5y R0qI9fNX5PgmLJM884dF8MQaF41qt4w+JgbKkKPzTU69vpXYnX9Khs3EmNRDAixW0RRNSzsH rER3WD6M8yfdpyvZUNQK5yMdJH2NGI51r0qpgqpthIiIgldtI8KHdr+eSfPW32PIBieUw1WG JK2QF5qy64C8fUr6cFXgrDuP4Ru5D4WCFH+mo33GGJ23LNpJNCb89wdn6SOf8PeEcEeaT+gm wPT87UCtNLmjUmfB/BQOTYjeX/PNiRyapJjJk078At8XBqQQMDadXtco85KLhuBIsYe05bJr DF+MgPrNVhQ3NWs2xJk4NZCUpTdmw27PlhVGl2SuWA8vAFa6G2aUDdDVgWbgYHyc0h5TKsbj 79fP5PgX8u6n4qA8KBupP9W375GajaxaqZGN0zBTWcHBihMOQuBSCHf16Hp0OT0qoGdhpvsn XQySKEPA3qofvlr5pxC1LEWbjV2YsLEdnkKe2z2+M38fbfGMqAgid/C95mqnLKgW3a3EAwXH ACYSa6Df0bVbYawpyXKDwZoaM6FlxJcn2smUY5FBdXdYRG33/IDhzpqWeGTjOb68WiVbIRpd MSpIhAbvlw4EKmXFmKOur6SI6j5KuZgil73i0GTgUIDkkXLQ1RuQ3K0cxGiWKKim4isJ8QqY lfTYYg1UBOsV1ObyIFESCno10aY0vSONED+s4AYgJG8YPvH9PTSTwZUvQOpuMbJnJX7f1dgF HZRHJ4JNkwNH5cJnZcVlX634kjQTLsK9XmipZ3HJOusBxv8KMACkjGIRCmVuZHN0cmVhbQpl bmRvYmoKNzIgMCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgL1RleHQgXQovRm9udCA8PAovRjIg NCAwIFIKL0Y0IDUgMCBSCi9UMjQgNzMgMCBSCi9UMjUgNzQgMCBSCj4+Ci9FeHRHU3RhdGUg PDwKL0dTMSA2IDAgUgo+Pgo+PgplbmRvYmoKNzYgMCBvYmoKPDwKL0xlbmd0aCA4MjUKL0Zp bHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQpIiZxV30/jMAx+71/hx0S6pknapu3Tafwe 0gG6lSdA0+gKFME2rR3T/fdnOx0MEGJCaKnjOPZn+3PYK4PoyIKB8i4wuSocaPzzkikKlSTg XKoyB+VzoPlweR9ExyMD9y0qyirQSusYynVwJc47aax4kE7U0oglDC9aWYi6AlLvk34yw2XW GzzRKQwu6HTY/pY35WkQlTbzcFKVWg7IgnGJQiyxUzbxWDCiuNbayPJxKwd/BT8mSxl9HKvc 3/A4qyBEyfSIh9I4cTE63JdGi7GMxUCm4lKGJhWlNIk4YXFM2hFci1UrwxyxZ2IKaz6KpDUC ZGi1GKIfutP7Ck0m9kgcyjARZ+jhAH/XcpOm84hzTIsg09fkmtJzplCF7bOsNqla696napT2 V71kCswrx8vcvD5hu+lQ4fMdrLoHLL3BHljRNYg7ERXtJ7R0Mowxu9BQStaiksRWar+95zQb aQrxwqL3BKvW31lSO+e8rpvuAe6bl96i4nPeLFGMfSR2GgHHf/Pgj2YM6LneoVo6VTb/abV0 omL7VbWOJHa4ITyzKcxX3RsqLlFElXif2wb+/I6q0LL26W4HZqeFUeZTz7+ld5rnKuNr4XYC 5KmntxEXMnRiRMshQ90fDy65fSViPGFpTOI5ElyGhVihCpueYU5WTHFjqVNarCP4wt8ejwIf nrG/A6TMLkxPs0T9tHVptj3Zyetkpz71kcT5W8iEmFUQx2PR3BHCfwg2F7BgfU36pW9n5RW4 LHkYIKo+mDABUPXMVhABF2dCBtVrFD5bdGx4i/Gf2IE33SfGDHgC2h2q47Qy7qflSQv1Q2JH HyeSB3XOnWVeL+ptgx3InXzK4ntmJ7Fy74nNUr7FbIUIrKj955fM+4e4nk1un+jRrX2rJ4sF V5847S06evbnntr0plPbkNzYMSZ3r6mgTxlDkTGxoOg9TFYdRXggdT1juaGlkv7ZzEWvew00 6y9ixblkGkIceSgPgncJbka39SVmMIXfNfNZz93lvKOjCn8dacnfYYmOUnS0vf49xjinWNhH YEqtwWj4A1c3GqaBgQYCE6dYZ4f/62MHccIUCm1KymUdjIL/AgwAVSDB8AplbmRzdHJlYW0K ZW5kb2JqCjc3IDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERGIC9UZXh0IF0KL0ZvbnQgPDwKL0Yy IDQgMCBSCi9UMjYgNzggMCBSCi9UMjcgNzkgMCBSCj4+Ci9FeHRHU3RhdGUgPDwKL0dTMSA2 IDAgUgo+Pgo+PgplbmRvYmoKODEgMCBvYmoKPDwKL0xlbmd0aCA0NzcKL0ZpbHRlciAvRmxh dGVEZWNvZGUKPj4Kc3RyZWFtDQpIiUxSTW/bMAy961fwSA2wIsqWYx/7tS4dBgyNdmp68Gwl dpHaQ+wt6L8fJXVdYEB6JvmoxyddO7H6bIDA7QVVqi5B85eQoRLK0qp1Ce5V6Jg5HcTqfktw mEWmldY1uFYwIAPuLJ5wIyv8LjPSOHuZGcIWbvpGZhWOYwoc4XqQWY1jlzYutniQWY6zfHYP YuVMlfRYZU08NAIqC1VAmZfKFElPODmcijutSbqXi0kSjzdaW1UEWq6qRGOtSaqTRNhLjR5a FlHiJI0Oenhtm8Un1EhT4MLQ4DCNEEqmvczWGOHS+0hN8dRm8cssa4RxOoW61+Z4fIMQ4XkN HkbfwcCNwqwaMlIs5zaZSf/MfFd49cNFK7/E9r/YRlrj23FqupmhwQ81FcJGcuCrJLyLlD8G dhgSM1+I95AIvl3CEEaxGrLwTg1dNgFd0ncy5YJM90l8yMsu9O0lFewa4QmWeLe95MXHG+UZ h2VoIj5KYj+indurtC8TnHtOBld4aWNdD6me78Ny35AdQ8cxQs/BkIgjxCbnhn/nKBh+Tr// E7oo+86xbKv5LVysj/fs+gM/jhcO8Es6A2n4Bk/PGjpBMICg3Cp++HWt8hLygpQuIDM2BE9e bMVfAQYATie4XwplbmRzdHJlYW0KZW5kb2JqCjgyIDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERG IC9UZXh0IF0KL0ZvbnQgPDwKL0YyIDQgMCBSCi9UMjggODMgMCBSCj4+Ci9FeHRHU3RhdGUg PDwKL0dTMSA2IDAgUgo+Pgo+PgplbmRvYmoKODUgMCBvYmoKPDwKL0xlbmd0aCAxODgzCi9G aWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0KSImcV0tz2zYQvutX4FaiE9EA+O6lk0eb up2kTqxpD0kPEkVbbCVSJSmrnumP7367oCw7bqxkNCKXABbY57eLF7PJ2Y9OWTW7mtg8LFJl 6CeUzdIwVmmahFmqZpuJ4bnuenL2+tKq634yNaExTs3KCYhEzfaTD8Gltiaoyl1XD7dqrq0L Gj3Ng6UC+euwqjr1UmdBq2OZ6OmjXlbdfKjB2WKs6fUfs58nZ7PIiGhJmDg+nQmbxhAsSkMX i2AQAccHH42xevbnkVLCRy+bJWEMtijMhS00VmR+vt1O9TQL1trmwVxPbRrcVh1GlHYmeEcj OUlmgoteF4G6wTOkQSPz63bPKyrS6Y5rPb+teKtO2yhQ79qLk7RyJhyVOk0fcpaYgd0ReXfY SFQ7h1EvIFRPwsTkGVWuoGJB5rcZfOAiktyS8tNEJC9bHmz6AUMdK7or+aPGg6Zp1ivjChEs J7EhGd42N5ApNXEYuYceci69r5ENjbAKZQsSPyfmKIxS7yc4qjxy2HtNdoV1HZkZGg5126ih VdtOk6dKjkGe7vu6uVabdulXw8OqbpSLjV2QNi4J+qc1SfICtv46TZI8DzM3asL5Mj3y0Fsy vg2u26GGW2yAPChgY/JEo12g2isapwg655f4knlKXq/ktaKlskHT8Oxa0RaOFhHtd+uHjiJ3 V/pzyGQrnphjTS/rt1jSLnh8DUkqXr1RbCWjpja0ESk3e/WYY/arCran0AoU5TrbnGLKsaww /zSmGOJcwXczqP3cUz2vW+wGZkRu9bIILr2hDe++1LL13m2+IfgYHuRVHCaCY0zYIgsdeYHS 6wS4MIhYdiFTjkI4BrMbI5lUPbjQpKI1DB4Hex2lgWL8e84pv9GURYCNpXZxwGvUxwA2pdCJ 8LnARA3rN8s7EtS1AvOmBb0U1ksdRbIzsccY+qhhT165xzjO2oFjjX2WPNHrNGgPYzfaeEEw N2gOHCPnngJPSVyE9pOUfhKkkjhFRRlBKjkY0BeNN7ueoXJg9BQaHmbwcSQ1oU4lNIepCSTR OX9lVoYHMQOGVbnGbjUetJeDYW2CI1w27sLLV7x8Lmfzc3W040uG9hf6cPIGKxC0Im3JW6+w 9fcnAAlVH/PVQBI5vI4hcerjUaA+D66QHZzHfftMc/LhYxjTErKqftXumGI0XMrgIVtJ4ZT0 pYfwMuc/2voUJk0Dn7LXnmMh7+9OSkNbjOX3K9KQap09hJHNRr25jJEEQ3UNnSnHsuAnFp7J JQZrCSeKhZKQz/cl3kBR8C9y4l89LVj/DPpnSC9+PO1VEe+uap/qUKpxiftfh/7Cpu+4bi8Y AA+fba9+4yxRr/l1ibbpEkpMef75BQbOD9GwYd47D8roAUZV0w7j0BgxdR/CStLnhCdgQ1yY R8r9k9gQ51lYuPsN2duK6yGXKJQ/31KVrOtKc8kCSaVurRZ1s6Qiz63ZDk9puxhqI257yHQV d534v+GBqXg5IxsR8fYVf397cPZn9cweePtpFbOxfLB7x5o5anveSEHm+l5BkI5B54qfc48y gmIEXc8kYZ/Tq0A7QMhz3rPToDLkfxhuLilg4jsxHqnciJUfZj8ibNS+lSj7iyLleynFrcTO Xxw7dFS7ZSkGIAhMTOs4m1quz7uhZmzBHQCQJHDTcF8mASVYeWepOIrD9NhSxzGk2byfd0qS hzk75RR/JOnowXsdmc+7y61m3IMJSo2a/pIdNIMTyOCAPIk5X0Va9GaJTPUAkYq4Stbwhxmd kdAZx8/3r0mzn0mkPxXjx55gTr1RH/4wajmxqlYTGyVhqtKiQA8cxexFqlIY7KrJ5eTF7Mge 9xDJJMDX2KRjqfhcLnJj6m98RFkKF2Z23jx2vPLdu+nFYqbfQ/JsF6IF4UaCKeVQCWO2l7Fn x18gLZML329QjXmGcJlvMbflOW5T6nLOW1L+T7vqb8zuJI97Hq9wA1lK+wuQOr/o6WLDBp8C hKivQJ9qXDr2qfEovPdxqRkJ42AODOkhBQ+NN1bCkgXuR9yFKMxXFV+Y1JwXb7jRuKk5Z3ni mplEGgIhZinVFlMtptbgqKnZKm95nysMdrjI8DRveNxk24SbbG6T8jFXvekHD+QJy0d8lxev iED/0nIGDyvOuEqJTlgjCbt92OU9EjxRHIU+B0f3f3kQRVHh72+HILqnyuiImZdU9IgFFkyY j9U/V5bC3kAqbiDugSiVKcjyiQhphDS/E+FeeTW+b1DzZqmSRw50pvjCA53NPj0wGjX1Fz32 xWK3xmtdDdydbRkMW0RBTVcgqkd0OcWXQgHW3AxnAbPUS15LLqVutRMauXBVdfA6eOY+BRJq tm3yWBRBjm3b9/ViXalt19ILmLzhKqL2ALhHs3rec7beIhNlMacgr+i0kwtEiSHFobltfR7X vD8zq1aup9hDVg3cNlfHUX+Usocy6S8JMAxdkQZsSL1B20lwkxM7LYUzDvotb9xipfR3dHkq /DVC9TV4l/xRcY56iP5PgAEAfSYtoAplbmRzdHJlYW0KZW5kb2JqCjg2IDAgb2JqCjw8Ci9Q cm9jU2V0IFsvUERGIC9UZXh0IF0KL0ZvbnQgPDwKL0YyIDQgMCBSCi9UMjkgODcgMCBSCi9U MzAgODggMCBSCj4+Ci9FeHRHU3RhdGUgPDwKL0dTMSA2IDAgUgo+Pgo+PgplbmRvYmoKOTAg MCBvYmoKPDwKL0xlbmd0aCAxMjg0Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0K SImcVk1v2zgQvftX8EguYpmkPiztZdFu2mILpChq35IeFFmxldiSIcnO5t933oxkO9lFd1EE poZDDjl882Ym75eT2UevnFo+TFwaZImy9CeSj5PApipJ4mCeqOVuYnmxXU9mnxZOrbvJ1AbW km0xudXvtr1xTpdtbWKdG6v76khS2ZlU/2G+Lz9PZstwuCkOYs9nseCSKIhUEg530Gk0PE/0 HZ1tlo8XDooRfdw8DiLYhIGYsScJbFmKcMCtvvnLTF2olzTG+saEWpmptzrvzTTVPOTFE6kS rSrMajMl0bG3yQgGCz5xuCkJU3J1uI8frrsePp5d8wRX5t+6xnth48QzZciPgvya66buW+O8 Jg9CfSxZt+J1kf82LiNAIe6wZb8tVZHX6r5UD3C6wXq1LVf0ECcH37P4ggXFj5nOgzhSUxfQ 9dfww/rBIQowO9TDbkO3pHRtIsccOjPNZNo8GIJQnRQF/Q7G65ZX65zGHYsdk4DOiXQLkyNt qgqeY52X1Z3GkuwK8Ia18V6kKwx8+wz7ezGdnb1rsJX96Hm8AnbySssv9OMTB2Jef1ksPmDT n2Tv9Z1BkK/Yj/tD//tITSccQ3wRSXxdagMfqTjzQfqWm94nr7npAiuWIrnMInnizAUpM+YV 6NkIOkVow5ws2SG8DaF2er/vVAGdTOu66VVrMgYNShq22xciAdt1h5aZLrN+w+s92EITUdZy 0G4w4I8YDSEa4uaQC+RWRyl8CatN5wB2OrgPZDveXhYHxIHO8ojxf8MpCfKLeFKtyJIRz1NW CZwLQ1T5CgJdAzxEm4CwumZcRbExAqnX9brkrxCoa07gewZ/IyIlJJ2g6gbRsMQ+ZFZds1ZO 7KuGkrGqV1W9FsCWv5Ez6wPf3VL5G+7r5b7/A1GY4c2/CBHVKJu+goirlReQQKSjeALfqEhw VfR6zW+q+YGluI7U41ds3xTwKIilOLLgsnng6WIfj1z/WRG3QTgUS5a8peoP43BkhVRJ8doP 5WlFac/0Dol1MeKBec+xIY9Diuu4voVyT75r9QWh/UhZs6DfETsi9QzdDHu+XUPk4Su/78OS Lo8pSy/Hb5/oJZ/J3UfFsXkmv9WNuv1u1WriVKUmLowDag1ZhoIfRhyLqY+hbMvJYvJ+eYHc q2hbBiyyyRiwn+GWBnM/dmeSnHNi7AEfGbuxO19mho0Fv3cU9k3ZAh+Vbxk34gDV6DrniTSf gZ/oGmhIlN9zEftGHZBcrOENG97bsJIKjUuIOcwWOnR3Ov58Qt6pfLVqy64ru6EnIfzkHxcX n5yKS3Tq4gNjHwyqPvofCKv44k4UxVPJnQA53ynOEKip6PGXm7oUMi4G5ADry04OYeNOFlEn aaZWF5YFNA09t2ZlLfU308XpUhRgyM9D+eX2GKHinCuno9b7tusO/6BwcqGPcpXm7EPhrlCM i1y+VF2aB8awzndDlaYsuAK+hCk66YrNWgQAT6M2SyDn9XnpH+bUANqjXFOeitbAl2JkEDzc UogZ/lQ/QTpA2kPq+NDHA4XfwZMOtNhBPlCGFhuVS7biNuw8dFUNu7V0eMa/MD6RI8l5MMty oyK7Xak6htvK0hGb0KVCPDF73ZqEPf/G+1UDtjINr8ycOz7XjKoWVqrn/EUYTvU+G1rmSHwf DynB2dFVsLxnxRaKU6JQduR7PHx/XqyGBoGUyLhHdGON+SHAABDCjyMKZW5kc3RyZWFtCmVu ZG9iago5MSAwIG9iago8PAovUHJvY1NldCBbL1BERiAvVGV4dCBdCi9Gb250IDw8Ci9GMiA0 IDAgUgovVDMxIDkyIDAgUgovVDMyIDkzIDAgUgo+PgovRXh0R1N0YXRlIDw8Ci9HUzEgNiAw IFIKPj4KPj4KZW5kb2JqCjk1IDAgb2JqCjw8Ci9MZW5ndGggMTEwOAovRmlsdGVyIC9GbGF0 ZURlY29kZQo+PgpzdHJlYW0NCkiJnFbbbttGEH3nV+xbdwtztReSIp8Kp3YSJ21gWCxQwMmD LdMSDYU0LEpC/r5nZihbDlpALoKIs7NzOXNdv6uTyfugvKrvE1/aqlAO/4QKbmrLTBVFbqeF qr8nji+fFsnkw8yrxTpJnXUOV3Ohoqp3ybX+y0z12qSVbkwphDKpD7q/V7+DcHppnL7pumZl 0mK8e9cS3d3JZ7E23+pPyaSOmUDLbR7YORO+yCxwxcKGTHABgSPn+qtz3tQPB0GJHj5+mtuM 1CJFBTXC7AXyl/ez7a9qByilnhj8AFVwun8y6VQf8nvmqyuEeMbcs8tjoAZn90iPA4kKhGeQ hBIBAu0ItzV+qmcmzTUlNBPywiCPJzh7IJ4oM+Iv6dTz8YqFz46D7DJbvj25Ltj/hn3a/RiW bbdQA+FfIpVe3wxqY3xFfQL4jXzejDYvuWPfCjcvCwmS4QZSvdYfkUivL6kRf9u7jmKghCuy QF9fOipRPg22fEmU/hpC8dqpt060hPIVfJXQ87YKrHeYKUkUIJSEgPowBD3npKzaxmB4ukHd 3RDRMPe7STPdd2rXbzifK+rSOyZZt38UuU6xkrrtN93BtZjuMYxMzElmaGFv6KlK5Vgl9qw4 G06l3npXTlV9loxTz9gRlIAH9guSv2QP672BoJ+IuzWRoTs5UjApRyPBEBgwKnQyqq+GJV90 UFIiuAF5wB3aObNviDGQvhhn3yTHh2dMNc4FMPnR/vYASkva90T9IHcH0UbUDdHywhiX3Jya ZGkCOfZAQmsBSQS9ot0R9G2LbYZNJqdRKnBpAGizbmRSBaLXIvZkKi3n9WY1tDQY3UI0ZrSK TrF3RBL1ueULoI5YnAeG/rVKY3E4TY+PK2TNE6p0rPcvcLwe00SNUJtcp0wNvEi4JCnl5rWM Yjs98iVV67i6XhpLTP80vpnN5ZFhwldTGzANIRwzv87GcYSZCthRGSnzYI2j9NyOY6FqRLak RwhrJqdujNQO2UuLMnRKe87/70hMdfTbE394LbJ4uTAhR/Yli6UcGyZZY3YKJ+sTph/E96BW ZGJLByKwnX2EeihhdrSvGNdn6J4DOIuGozLoqn0S/kcG8dL7/TLyYf+gh0pSuDOAOaEO7qne mTzgJk6RFkddnVHgFe0e9N9ta2KGjiR2K23vEB9Oa1NQ7mHsgrbWpYmRuznq5Q2ZXZtQjYyB vZGSnG8bHlcWI3vCnVGuTk0sxjMGEKAWrMcW2D8rvRz7PeaDSXFVfB7wsN/F48g8wnRGtULd B65Yzxzp8H7FLEV7X20WfLM84sXKymCLt//1kuHVyX56skbQhFV6hpZgx1uCH9Ka9wJd/cHU FyTgnCm5OcFEq2bbdLRjCs0/HyGzDScvr/Hf3o+nZqDizS20LHMsh3teA0gORIe/Vx8Q2SdE 8KD4tdyh79Sf6vqbU3eJV61KfMxtoYqqsrFQMeNJTkNOzKcmmSX/CDAAdgJL8wplbmRzdHJl YW0KZW5kb2JqCjk2IDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERGIC9UZXh0IF0KL0ZvbnQgPDwK L0YyIDQgMCBSCi9UMzMgOTcgMCBSCi9UMzQgOTggMCBSCj4+Ci9FeHRHU3RhdGUgPDwKL0dT MSA2IDAgUgo+Pgo+PgplbmRvYmoKMTAwIDAgb2JqCjw8Ci9MZW5ndGggMTUzMQovRmlsdGVy IC9GbGF0ZURlY29kZQo+PgpzdHJlYW0NCkiJnFdNj9NIEL3nV/SNboQ97vZnjstkGYEWNAqR 9gAcHMdJjBLbazsz8O+3XpWdZBYJhhUiLnd1levj1eue16vZzRunrFptZzbz54kK6J9ILgn9 2Kkkif00UavjLGBlt5vd3H20atfPvMAPgkititknvTBz3Rini9OxrAfjRbo3X1bvZjerMBH/ MbzBAws2ifxIJWHiu0ickxv6eZzpz0FgzerrVWRiRw+bxn4Es9DPxIwicBLBpjM21rnxbKS3 EAevKk2ih62Ht5oUmSh64831Q+QVpN1TzDk9a3rKFtgc2GTN75VxwajaGOfo3eMFEne82htr tRcEvrFOD9+G5+TtAv+S9nMypp64pxlDyFCwX6YuEbeImFNvvarloEu2QBk848VcB9qlqw7G /5B0lZX6rOGrYJNDM9pTqb4r3n6A9SAeN5/Nc4oQRH72+70PnJQO6LOX/EPOP0H+IeVvvFRX 5bDF08NSzUVgLRWBgicAQFkUR36SW2MDTdClMn1Dz0VE3qRuToNq2JtiR5t8KF+Rn0Crx+rA Ow+GwCDadSnPU4t9HNcGLhWXJVCe9Sn0xdUEsZRIOvmWhom+nqBBZNVxvOo9PWJ9j378RWKo Pxov05dSx1KxjMqDkuFpswCwial07odSO5c8LbX1AzEVyc4ppoyMIz90E/TsCL2x8osSRdty 1yvkjzIDGLTaq1vkcGsoe4rdhdSITL/G2lsSPnBZFgI+Mn9prH6F5NQdJ8Y/sPiDN1LeEdlh pwKS2x51dfq0acT+yB8teHFPvnKWapKq/tizjcTZ0FJnsifNCLIU/XgyXPMRXCWgnuPnUNU7 avewVwVe99wd1tR1yU068HfWrKB6zEfYbTBV9U6iyHlnvVGjza4ZKnYyVE0NkM21GvaiYx8d d5ttT+yuNwGV+NcTFkeZn/w+vcZR4kfZNGNBOLU8lIIsF4t7CgOTQLG85SHwUPtFL+1hZFnS y3tZKjGhlb/vGB9s2eY7RkX5DACHzo+T/wvg0PrJiF874nYJLltQeKlGZFRxasZc4/+Gh1la NeyrXq2xWnAPcpJOoqdf3q4W4uYezHIDGl0i04WJGfQRwTfWqkI9en5nx7uS/dXy6EzKqAjB ISn9kJfvAs/VywsovasmXIGrZ4B2whmhFuAAcYgc8vBI/kXkrWJ2xpgaujE51lFubTPyDrlU Z7hy3jCCDb+Iqm0PVSEz4k0ovhhdJfFf7kDlaQyPp36QkW4YHFc8MjClVvXQKBb3F3ahT1gc avT9CVLkoZMJH5oCWvEnvLwRPhjYTHjmcX/53sgbl2DWQi+XBM4dsOcOpBymm0pJM1pQybh9 5RkvHdO22vIDnW6OUr0zcAh+L4gGe1lufdSyYZnFB/8Zox5lFqMrE/KsKY/S+XgoXJ2kS4rv DW5vtyQ4opmUkRCFSg7NsuD28qLlA9OyzGIyHoj5SHrqyhuq4VL67EhgmLWIq54IYkKfja3l ZP9cEVBigv317/KOkntHSXxVzAqPygbqvfr0JVCbmVWVmtkwplFP5nOfahVGzAKei7HYlbOP s9erqzI+4Zkgxo0yChIwxk+qmPmpmy7JJFliGrZzI2Pa6ZJ8PtnH8R2Zk86deyN0Q+gqN9R0 oBLk0TAPdTgugR69LS9yDR2qpdmOjXryhX6cbWuQVizyFqbAJW9tD3lVA68DTg66zHGRqe+h C2I5AF2CA/ATWMBNI00Tfu2eOX0DMcd3hok1KJ58DSVve4BUqopzupwFUyg5fENV/NR3fq4Q V+XqqLZxNB3V9nxzSqXAdTMQ6RFhKB7eFneGA0gxrwDQWigAIoqw5dduDILEIxMLi0uYLsBP cnK96Pn8ouGk4W58AvYDi6oRp0wB89H4EXb8xY7fSxDKK97+A6mPOEH0a7pjIueKLwM4YNS+ PLT8JwtyGvYQSyqTZYKhm2y1E6LFCl0d1J4WSNzzqoccWpnbDvK26Y5MQ1RjvhGTpigZNEue vg9I8i223vJ7/+SOJBDxxruRUHk8kSGwsDXU8Upwoap+muR/BRgAtYUyxQplbmRzdHJlYW0K ZW5kb2JqCjEwMSAwIG9iago8PAovUHJvY1NldCBbL1BERiAvVGV4dCBdCi9Gb250IDw8Ci9G MiA0IDAgUgovVDM1IDEwMiAwIFIKL1QzNiAxMDMgMCBSCj4+Ci9FeHRHU3RhdGUgPDwKL0dT MSA2IDAgUgo+Pgo+PgplbmRvYmoKMTA0IDAgb2JqCjw8Ci9UeXBlIC9IYWxmdG9uZQovSGFs ZnRvbmVUeXBlIDEKL0hhbGZ0b25lTmFtZSAoRGVmYXVsdCkKL0ZyZXF1ZW5jeSA2MAovQW5n bGUgNDUKL1Nwb3RGdW5jdGlvbiAvUm91bmQKPj4KZW5kb2JqCjYgMCBvYmoKPDwKL1R5cGUg L0V4dEdTdGF0ZQovU0EgZmFsc2UKL09QIGZhbHNlCi9IVCAvRGVmYXVsdAo+PgplbmRvYmoK MTA1IDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERGIF0KPj4KZW5kb2JqCjE0IDAgb2JqCjw8Ci9O YW1lIC9UMQovVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTMKL1Jlc291cmNlcyAxMDUgMCBS Ci9Gb250QkJveCBbLTEgMjI0IDU1NCAyOTVdCi9Gb250TWF0cml4IFswLjAwMSAwIDAgMC4w MDEgMCAwXQovRmlyc3RDaGFyIDE1MAovTGFzdENoYXIgMTUwCi9FbmNvZGluZyAxMDYgMCBS Ci9DaGFyUHJvY3MgMTA3IDAgUgovV2lkdGhzIFs1NTYgXQo+PgplbmRvYmoKMTA2IDAgb2Jq Cjw8Ci9UeXBlIC9FbmNvZGluZwovRGlmZmVyZW5jZXMgWzE1MC9nbHlwaDEgXQo+PgplbmRv YmoKMTA3IDAgb2JqCjw8Ci9nbHlwaDEgMTA4IDAgUgo+PgplbmRvYmoKMTA4IDAgb2JqCjw8 Ci9MZW5ndGggNTYKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQpIiTI1NVMwUNA1 VDAyMlEwNTVRMLI0VUgx5DJUyFTgAgkDuaampgq65oYKRalcaVwAAQYA4P4JSwplbmRzdHJl YW0KZW5kb2JqCjEwOSAwIG9iago8PAovUHJvY1NldCBbL1BERiBdCj4+CmVuZG9iagoxNSAw IG9iago8PAovTmFtZSAvVDIKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUzCi9SZXNvdXJj ZXMgMTA5IDAgUgovRm9udEJCb3ggWzgzIDcxIDY2MyA2NDldCi9Gb250TWF0cml4IFswLjAw MSAwIDAgMC4wMDEgMCAwXQovRmlyc3RDaGFyIDEKL0xhc3RDaGFyIDEKL0VuY29kaW5nIDEx MCAwIFIKL0NoYXJQcm9jcyAxMTEgMCBSCi9XaWR0aHMgWzc0OCBdCj4+CmVuZG9iagoxMTAg MCBvYmoKPDwKL1R5cGUgL0VuY29kaW5nCi9EaWZmZXJlbmNlcyBbMS9nbHlwaDEgXQo+Pgpl bmRvYmoKMTExIDAgb2JqCjw8Ci9nbHlwaDEgMTEyIDAgUgo+PgplbmRvYmoKMTEyIDAgb2Jq Cjw8Ci9MZW5ndGggMTQwCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0KSIk0T7sR QzEI6z2FRjCY7zwvl7sU2b8N4EslGWRJuAQ24sAJZgcmiRctwgerpsc2vk1EDEQbSgoyhVri WUwJ4wOOmJ/HZfBZojlM+Sq0PNR3bexYufikiVzsmNoUY1e0gnepgkHKtWmXTLRp9eyUgoqP eXeLjKl15UQ13N5nsRviH/BePwEGAPi+LLMKZW5kc3RyZWFtCmVuZG9iagoxMTMgMCBvYmoK PDwKL1Byb2NTZXQgWy9QREYgXQo+PgplbmRvYmoKMTkgMCBvYmoKPDwKL05hbWUgL1QzCi9U eXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMwovUmVzb3VyY2VzIDExMyAwIFIKL0ZvbnRCQm94 IFstMSAyMjQgNTU0IDI5NV0KL0ZvbnRNYXRyaXggWzAuMDAxIDAgMCAwLjAwMSAwIDBdCi9G aXJzdENoYXIgMTUwCi9MYXN0Q2hhciAxNTAKL0VuY29kaW5nIDExNCAwIFIKL0NoYXJQcm9j cyAxMTUgMCBSCi9XaWR0aHMgWzU1NiBdCj4+CmVuZG9iagoxMTQgMCBvYmoKPDwKL1R5cGUg L0VuY29kaW5nCi9EaWZmZXJlbmNlcyBbMTUwL2dseXBoMSBdCj4+CmVuZG9iagoxMTUgMCBv YmoKPDwKL2dseXBoMSAxMTYgMCBSCj4+CmVuZG9iagoxMTYgMCBvYmoKPDwKL0xlbmd0aCA1 NgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0NCkiJMjU1UzBQ0DVUMDIyUTA1NVEw sjRVSDHkMlTIVOACCQO5pqamCrrmhgpFqVxpXAABBgDg/glLCmVuZHN0cmVhbQplbmRvYmoK MTE3IDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERGIF0KPj4KZW5kb2JqCjIwIDAgb2JqCjw8Ci9O YW1lIC9UNAovVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTMKL1Jlc291cmNlcyAxMTcgMCBS Ci9Gb250QkJveCBbODMgNzEgNjYzIDY0OV0KL0ZvbnRNYXRyaXggWzAuMDAxIDAgMCAwLjAw MSAwIDBdCi9GaXJzdENoYXIgMQovTGFzdENoYXIgMQovRW5jb2RpbmcgMTE4IDAgUgovQ2hh clByb2NzIDExOSAwIFIKL1dpZHRocyBbNzQ4IF0KPj4KZW5kb2JqCjExOCAwIG9iago8PAov VHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsxL2dseXBoMSBdCj4+CmVuZG9iagoxMTkg MCBvYmoKPDwKL2dseXBoMSAxMjAgMCBSCj4+CmVuZG9iagoxMjAgMCBvYmoKPDwKL0xlbmd0 aCAxNDAKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQpIiTRPuxFDMQjrPYVGMJjv PC+XuxTZvw3gSyUZZEm4BDbiwAlmByaJFy3CB6umxza+TUQMRBtKCjKFWuJZTAnjA46Yn8dl 8FmiOUz5KrQ81Hdt7Fi5+KSJXOyY2hRjV7SCd6mCQcq1aZdMtGn17JSCio95d4uMqXXlRDXc 3mexG+If8F4/AQYA+L4sswplbmRzdHJlYW0KZW5kb2JqCjEyMSAwIG9iago8PAovUHJvY1Nl dCBbL1BERiBdCj4+CmVuZG9iagoyNCAwIG9iago8PAovTmFtZSAvVDUKL1R5cGUgL0ZvbnQK L1N1YnR5cGUgL1R5cGUzCi9SZXNvdXJjZXMgMTIxIDAgUgovRm9udEJCb3ggWzgzIDcxIDY2 MyA2NDldCi9Gb250TWF0cml4IFswLjAwMSAwIDAgMC4wMDEgMCAwXQovRmlyc3RDaGFyIDEK L0xhc3RDaGFyIDEKL0VuY29kaW5nIDEyMiAwIFIKL0NoYXJQcm9jcyAxMjMgMCBSCi9XaWR0 aHMgWzc0OCBdCj4+CmVuZG9iagoxMjIgMCBvYmoKPDwKL1R5cGUgL0VuY29kaW5nCi9EaWZm ZXJlbmNlcyBbMS9nbHlwaDEgXQo+PgplbmRvYmoKMTIzIDAgb2JqCjw8Ci9nbHlwaDEgMTI0 IDAgUgo+PgplbmRvYmoKMTI0IDAgb2JqCjw8Ci9MZW5ndGggMTQwCi9GaWx0ZXIgL0ZsYXRl RGVjb2RlCj4+CnN0cmVhbQ0KSIk0T7sRQzEI6z2FRjCY7zwvl7sU2b8N4EslGWRJuAQ24sAJ ZgcmiRctwgerpsc2vk1EDEQbSgoyhVriWUwJ4wOOmJ/HZfBZojlM+Sq0PNR3bexYufikiVzs mNoUY1e0gnepgkHKtWmXTLRp9eyUgoqPeXeLjKl15UQ13N5nsRviH/BePwEGAPi+LLMKZW5k c3RyZWFtCmVuZG9iagoxMjUgMCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgXQo+PgplbmRvYmoK MjggMCBvYmoKPDwKL05hbWUgL1Q2Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMwovUmVz b3VyY2VzIDEyNSAwIFIKL0ZvbnRCQm94IFstMSAyMjQgNTU0IDI5NV0KL0ZvbnRNYXRyaXgg WzAuMDAxIDAgMCAwLjAwMSAwIDBdCi9GaXJzdENoYXIgMTUwCi9MYXN0Q2hhciAxNTAKL0Vu Y29kaW5nIDEyNiAwIFIKL0NoYXJQcm9jcyAxMjcgMCBSCi9XaWR0aHMgWzU1NiBdCj4+CmVu ZG9iagoxMjYgMCBvYmoKPDwKL1R5cGUgL0VuY29kaW5nCi9EaWZmZXJlbmNlcyBbMTUwL2ds eXBoMSBdCj4+CmVuZG9iagoxMjcgMCBvYmoKPDwKL2dseXBoMSAxMjggMCBSCj4+CmVuZG9i agoxMjggMCBvYmoKPDwKL0xlbmd0aCA1NgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJl YW0NCkiJMjU1UzBQ0DVUMDIyUTA1NVEwsjRVSDHkMlTIVOACCQO5pqamCrrmhgpFqVxpXAAB BgDg/glLCmVuZHN0cmVhbQplbmRvYmoKMTI5IDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERGIF0K Pj4KZW5kb2JqCjI5IDAgb2JqCjw8Ci9OYW1lIC9UNwovVHlwZSAvRm9udAovU3VidHlwZSAv VHlwZTMKL1Jlc291cmNlcyAxMjkgMCBSCi9Gb250QkJveCBbODMgNzEgNjYzIDY0OV0KL0Zv bnRNYXRyaXggWzAuMDAxIDAgMCAwLjAwMSAwIDBdCi9GaXJzdENoYXIgMQovTGFzdENoYXIg MQovRW5jb2RpbmcgMTMwIDAgUgovQ2hhclByb2NzIDEzMSAwIFIKL1dpZHRocyBbNzQ4IF0K Pj4KZW5kb2JqCjEzMCAwIG9iago8PAovVHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsx L2dseXBoMSBdCj4+CmVuZG9iagoxMzEgMCBvYmoKPDwKL2dseXBoMSAxMzIgMCBSCj4+CmVu ZG9iagoxMzIgMCBvYmoKPDwKL0xlbmd0aCAxNDAKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4K c3RyZWFtDQpIiTRPuxFDMQjrPYVGMJjvPC+XuxTZvw3gSyUZZEm4BDbiwAlmByaJFy3CB6um xza+TUQMRBtKCjKFWuJZTAnjA46Yn8dl8FmiOUz5KrQ81Hdt7Fi5+KSJXOyY2hRjV7SCd6mC Qcq1aZdMtGn17JSCio95d4uMqXXlRDXc3mexG+If8F4/AQYA+L4sswplbmRzdHJlYW0KZW5k b2JqCjEzMyAwIG9iago8PAovUHJvY1NldCBbL1BERiBdCj4+CmVuZG9iagozMyAwIG9iago8 PAovTmFtZSAvVDgKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUzCi9SZXNvdXJjZXMgMTMz IDAgUgovRm9udEJCb3ggWy0xIDIyNCA1NTQgMjk1XQovRm9udE1hdHJpeCBbMC4wMDEgMCAw IDAuMDAxIDAgMF0KL0ZpcnN0Q2hhciAxNTAKL0xhc3RDaGFyIDE1MAovRW5jb2RpbmcgMTM0 IDAgUgovQ2hhclByb2NzIDEzNSAwIFIKL1dpZHRocyBbNTU2IF0KPj4KZW5kb2JqCjEzNCAw IG9iago8PAovVHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsxNTAvZ2x5cGgxIF0KPj4K ZW5kb2JqCjEzNSAwIG9iago8PAovZ2x5cGgxIDEzNiAwIFIKPj4KZW5kb2JqCjEzNiAwIG9i ago8PAovTGVuZ3RoIDU2Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0KSIkyNTVT MFDQNVQwMjJRMDU1UTCyNFVIMeQyVMhU4AIJA7mmpqYKuuaGCkWpXGlcAAEGAOD+CUsKZW5k c3RyZWFtCmVuZG9iagoxMzcgMCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgXQo+PgplbmRvYmoK MzQgMCBvYmoKPDwKL05hbWUgL1Q5Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMwovUmVz b3VyY2VzIDEzNyAwIFIKL0ZvbnRCQm94IFs4MyA3MSA2NjMgNjQ5XQovRm9udE1hdHJpeCBb MC4wMDEgMCAwIDAuMDAxIDAgMF0KL0ZpcnN0Q2hhciAxCi9MYXN0Q2hhciAxCi9FbmNvZGlu ZyAxMzggMCBSCi9DaGFyUHJvY3MgMTM5IDAgUgovV2lkdGhzIFs3NDggXQo+PgplbmRvYmoK MTM4IDAgb2JqCjw8Ci9UeXBlIC9FbmNvZGluZwovRGlmZmVyZW5jZXMgWzEvZ2x5cGgxIF0K Pj4KZW5kb2JqCjEzOSAwIG9iago8PAovZ2x5cGgxIDE0MCAwIFIKPj4KZW5kb2JqCjE0MCAw IG9iago8PAovTGVuZ3RoIDE0MAovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0NCkiJ NE+7EUMxCOs9hUYwmO88L5e7FNm/DeBLJRlkSbgENuLACWYHJokXLcIHq6bHNr5NRAxEG0oK MoVa4llMCeMDjpifx2XwWaI5TPkqtDzUd23sWLn4pIlc7JjaFGNXtIJ3qYJByrVpl0y0afXs lIKKj3l3i4ypdeVENdzeZ7Eb4h/wXj8BBgD4viyzCmVuZHN0cmVhbQplbmRvYmoKMTQxIDAg b2JqCjw8Ci9Qcm9jU2V0IFsvUERGIF0KPj4KZW5kb2JqCjM5IDAgb2JqCjw8Ci9OYW1lIC9U MTAKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUzCi9SZXNvdXJjZXMgMTQxIDAgUgovRm9u dEJCb3ggWy0xIDIyNCA1NTQgMjk1XQovRm9udE1hdHJpeCBbMC4wMDEgMCAwIDAuMDAxIDAg MF0KL0ZpcnN0Q2hhciAxNTAKL0xhc3RDaGFyIDE1MAovRW5jb2RpbmcgMTQyIDAgUgovQ2hh clByb2NzIDE0MyAwIFIKL1dpZHRocyBbNTU2IF0KPj4KZW5kb2JqCjE0MiAwIG9iago8PAov VHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsxNTAvZ2x5cGgxIF0KPj4KZW5kb2JqCjE0 MyAwIG9iago8PAovZ2x5cGgxIDE0NCAwIFIKPj4KZW5kb2JqCjE0NCAwIG9iago8PAovTGVu Z3RoIDU2Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0KSIkyNTVTMFDQNVQwMjJR MDU1UTCyNFVIMeQyVMhU4AIJA7mmpqYKuuaGCkWpXGlcAAEGAOD+CUsKZW5kc3RyZWFtCmVu ZG9iagoxNDUgMCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgXQo+PgplbmRvYmoKNDAgMCBvYmoK PDwKL05hbWUgL1QxMQovVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTMKL1Jlc291cmNlcyAx NDUgMCBSCi9Gb250QkJveCBbODMgNzEgNjYzIDY0OV0KL0ZvbnRNYXRyaXggWzAuMDAxIDAg MCAwLjAwMSAwIDBdCi9GaXJzdENoYXIgMQovTGFzdENoYXIgMQovRW5jb2RpbmcgMTQ2IDAg UgovQ2hhclByb2NzIDE0NyAwIFIKL1dpZHRocyBbNzQ4IF0KPj4KZW5kb2JqCjE0NiAwIG9i ago8PAovVHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsxL2dseXBoMSBdCj4+CmVuZG9i agoxNDcgMCBvYmoKPDwKL2dseXBoMSAxNDggMCBSCj4+CmVuZG9iagoxNDggMCBvYmoKPDwK L0xlbmd0aCAxNDAKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQpIiTRPuxFDMQjr PYVGMJjvPC+XuxTZvw3gSyUZZEm4BDbiwAlmByaJFy3CB6umxza+TUQMRBtKCjKFWuJZTAnj A46Yn8dl8FmiOUz5KrQ81Hdt7Fi5+KSJXOyY2hRjV7SCd6mCQcq1aZdMtGn17JSCio95d4uM qXXlRDXc3mexG+If8F4/AQYA+L4sswplbmRzdHJlYW0KZW5kb2JqCjE0OSAwIG9iago8PAov UHJvY1NldCBbL1BERiBdCj4+CmVuZG9iago0NCAwIG9iago8PAovTmFtZSAvVDEyCi9UeXBl IC9Gb250Ci9TdWJ0eXBlIC9UeXBlMwovUmVzb3VyY2VzIDE0OSAwIFIKL0ZvbnRCQm94IFst MSAyMjQgNTU0IDI5NV0KL0ZvbnRNYXRyaXggWzAuMDAxIDAgMCAwLjAwMSAwIDBdCi9GaXJz dENoYXIgMTUwCi9MYXN0Q2hhciAxNTAKL0VuY29kaW5nIDE1MCAwIFIKL0NoYXJQcm9jcyAx NTEgMCBSCi9XaWR0aHMgWzU1NiBdCj4+CmVuZG9iagoxNTAgMCBvYmoKPDwKL1R5cGUgL0Vu Y29kaW5nCi9EaWZmZXJlbmNlcyBbMTUwL2dseXBoMSBdCj4+CmVuZG9iagoxNTEgMCBvYmoK PDwKL2dseXBoMSAxNTIgMCBSCj4+CmVuZG9iagoxNTIgMCBvYmoKPDwKL0xlbmd0aCA1Ngov RmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0NCkiJMjU1UzBQ0DVUMDIyUTA1NVEwsjRV SDHkMlTIVOACCQO5pqamCrrmhgpFqVxpXAABBgDg/glLCmVuZHN0cmVhbQplbmRvYmoKMTUz IDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERGIF0KPj4KZW5kb2JqCjQ1IDAgb2JqCjw8Ci9OYW1l IC9UMTMKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUzCi9SZXNvdXJjZXMgMTUzIDAgUgov Rm9udEJCb3ggWzgzIDcxIDY2MyA2NDldCi9Gb250TWF0cml4IFswLjAwMSAwIDAgMC4wMDEg MCAwXQovRmlyc3RDaGFyIDEKL0xhc3RDaGFyIDEKL0VuY29kaW5nIDE1NCAwIFIKL0NoYXJQ cm9jcyAxNTUgMCBSCi9XaWR0aHMgWzc0OCBdCj4+CmVuZG9iagoxNTQgMCBvYmoKPDwKL1R5 cGUgL0VuY29kaW5nCi9EaWZmZXJlbmNlcyBbMS9nbHlwaDEgXQo+PgplbmRvYmoKMTU1IDAg b2JqCjw8Ci9nbHlwaDEgMTU2IDAgUgo+PgplbmRvYmoKMTU2IDAgb2JqCjw8Ci9MZW5ndGgg MTQwCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0KSIk0T7sRQzEI6z2FRjCY7zwv l7sU2b8N4EslGWRJuAQ24sAJZgcmiRctwgerpsc2vk1EDEQbSgoyhVriWUwJ4wOOmJ/HZfBZ ojlM+Sq0PNR3bexYufikiVzsmNoUY1e0gnepgkHKtWmXTLRp9eyUgoqPeXeLjKl15UQ13N5n sRviH/BePwEGAPi+LLMKZW5kc3RyZWFtCmVuZG9iagoxNTcgMCBvYmoKPDwKL1Byb2NTZXQg Wy9QREYgXQo+PgplbmRvYmoKNDYgMCBvYmoKPDwKL05hbWUgL1QxNAovVHlwZSAvRm9udAov U3VidHlwZSAvVHlwZTMKL1Jlc291cmNlcyAxNTcgMCBSCi9Gb250QkJveCBbMTgzIDEwMCA4 MTUgNDEyXQovRm9udE1hdHJpeCBbMC4wMDEgMCAwIDAuMDAxIDAgMF0KL0ZpcnN0Q2hhciAx Ci9MYXN0Q2hhciAxCi9FbmNvZGluZyAxNTggMCBSCi9DaGFyUHJvY3MgMTU5IDAgUgovV2lk dGhzIFsxMDAwIF0KPj4KZW5kb2JqCjE1OCAwIG9iago8PAovVHlwZSAvRW5jb2RpbmcKL0Rp ZmZlcmVuY2VzIFsxL2dseXBoMSBdCj4+CmVuZG9iagoxNTkgMCBvYmoKPDwKL2dseXBoMSAx NjAgMCBSCj4+CmVuZG9iagoxNjAgMCBvYmoKPDwKL0xlbmd0aCAxMjgKL0ZpbHRlciAvRmxh dGVEZWNvZGUKPj4Kc3RyZWFtDQpIiTSOwQ0DMQgE/1SxJbCAsV3PRZEiOf1/A3fKb2yGZamq UHA5WLQ4EDS8KMQH0m+LwFemFzGQk2Am0sa9ccnYetOR1ASjZl5p9Zu5Yc5yOr/pPDR32z19 qHw3ovc9BzqxW1zSV5rKqbte2dMDtufd1HKV8+945C0/AQYAqaIm4QplbmRzdHJlYW0KZW5k b2JqCjE2MSAwIG9iago8PAovUHJvY1NldCBbL1BERiBdCj4+CmVuZG9iago1MCAwIG9iago8 PAovTmFtZSAvVDE1Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMwovUmVzb3VyY2VzIDE2 MSAwIFIKL0ZvbnRCQm94IFstMSAyMjQgNTU0IDI5NV0KL0ZvbnRNYXRyaXggWzAuMDAxIDAg MCAwLjAwMSAwIDBdCi9GaXJzdENoYXIgMTUwCi9MYXN0Q2hhciAxNTAKL0VuY29kaW5nIDE2 MiAwIFIKL0NoYXJQcm9jcyAxNjMgMCBSCi9XaWR0aHMgWzU1NiBdCj4+CmVuZG9iagoxNjIg MCBvYmoKPDwKL1R5cGUgL0VuY29kaW5nCi9EaWZmZXJlbmNlcyBbMTUwL2dseXBoMSBdCj4+ CmVuZG9iagoxNjMgMCBvYmoKPDwKL2dseXBoMSAxNjQgMCBSCj4+CmVuZG9iagoxNjQgMCBv YmoKPDwKL0xlbmd0aCA1NgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0NCkiJMjU1 UzBQ0DVUMDIyUTA1NVEwsjRVSDHkMlTIVOACCQO5pqamCrrmhgpFqVxpXAABBgDg/glLCmVu ZHN0cmVhbQplbmRvYmoKMTY1IDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERGIF0KPj4KZW5kb2Jq CjUxIDAgb2JqCjw8Ci9OYW1lIC9UMTYKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUzCi9S ZXNvdXJjZXMgMTY1IDAgUgovRm9udEJCb3ggWzgzIDcxIDY2MyA2NDldCi9Gb250TWF0cml4 IFswLjAwMSAwIDAgMC4wMDEgMCAwXQovRmlyc3RDaGFyIDEKL0xhc3RDaGFyIDEKL0VuY29k aW5nIDE2NiAwIFIKL0NoYXJQcm9jcyAxNjcgMCBSCi9XaWR0aHMgWzc0OCBdCj4+CmVuZG9i agoxNjYgMCBvYmoKPDwKL1R5cGUgL0VuY29kaW5nCi9EaWZmZXJlbmNlcyBbMS9nbHlwaDEg XQo+PgplbmRvYmoKMTY3IDAgb2JqCjw8Ci9nbHlwaDEgMTY4IDAgUgo+PgplbmRvYmoKMTY4 IDAgb2JqCjw8Ci9MZW5ndGggMTQwCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0K SIk0T7sRQzEI6z2FRjCY7zwvl7sU2b8N4EslGWRJuAQ24sAJZgcmiRctwgerpsc2vk1EDEQb SgoyhVriWUwJ4wOOmJ/HZfBZojlM+Sq0PNR3bexYufikiVzsmNoUY1e0gnepgkHKtWmXTLRp 9eyUgoqPeXeLjKl15UQ13N5nsRviH/BePwEGAPi+LLMKZW5kc3RyZWFtCmVuZG9iagoxNjkg MCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgXQo+PgplbmRvYmoKNTIgMCBvYmoKPDwKL05hbWUg L1QxNwovVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTMKL1Jlc291cmNlcyAxNjkgMCBSCi9G b250QkJveCBbMTgzIDEwMCA4MTUgNDEyXQovRm9udE1hdHJpeCBbMC4wMDEgMCAwIDAuMDAx IDAgMF0KL0ZpcnN0Q2hhciAxCi9MYXN0Q2hhciAxCi9FbmNvZGluZyAxNzAgMCBSCi9DaGFy UHJvY3MgMTcxIDAgUgovV2lkdGhzIFsxMDAwIF0KPj4KZW5kb2JqCjE3MCAwIG9iago8PAov VHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsxL2dseXBoMSBdCj4+CmVuZG9iagoxNzEg MCBvYmoKPDwKL2dseXBoMSAxNzIgMCBSCj4+CmVuZG9iagoxNzIgMCBvYmoKPDwKL0xlbmd0 aCAxMjgKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQpIiTSOwQ0DMQgE/1SxJbCA sV3PRZEiOf1/A3fKb2yGZamqUHA5WLQ4EDS8KMQH0m+LwFemFzGQk2Am0sa9ccnYetOR1ASj Zl5p9Zu5Yc5yOr/pPDR32z19qHw3ovc9BzqxW1zSV5rKqbte2dMDtufd1HKV8+945C0/AQYA qaIm4QplbmRzdHJlYW0KZW5kb2JqCjE3MyAwIG9iago8PAovUHJvY1NldCBbL1BERiBdCj4+ CmVuZG9iago1NiAwIG9iago8PAovTmFtZSAvVDE4Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9U eXBlMwovUmVzb3VyY2VzIDE3MyAwIFIKL0ZvbnRCQm94IFstMSAyMjQgNTU0IDI5NV0KL0Zv bnRNYXRyaXggWzAuMDAxIDAgMCAwLjAwMSAwIDBdCi9GaXJzdENoYXIgMTUwCi9MYXN0Q2hh ciAxNTAKL0VuY29kaW5nIDE3NCAwIFIKL0NoYXJQcm9jcyAxNzUgMCBSCi9XaWR0aHMgWzU1 NiBdCj4+CmVuZG9iagoxNzQgMCBvYmoKPDwKL1R5cGUgL0VuY29kaW5nCi9EaWZmZXJlbmNl cyBbMTUwL2dseXBoMSBdCj4+CmVuZG9iagoxNzUgMCBvYmoKPDwKL2dseXBoMSAxNzYgMCBS Cj4+CmVuZG9iagoxNzYgMCBvYmoKPDwKL0xlbmd0aCA1NgovRmlsdGVyIC9GbGF0ZURlY29k ZQo+PgpzdHJlYW0NCkiJMjU1UzBQ0DVUMDIyUTA1NVEwsjRVSDHkMlTIVOACCQO5pqamCrrm hgpFqVxpXAABBgDg/glLCmVuZHN0cmVhbQplbmRvYmoKMTc3IDAgb2JqCjw8Ci9Qcm9jU2V0 IFsvUERGIF0KPj4KZW5kb2JqCjU3IDAgb2JqCjw8Ci9OYW1lIC9UMTkKL1R5cGUgL0ZvbnQK L1N1YnR5cGUgL1R5cGUzCi9SZXNvdXJjZXMgMTc3IDAgUgovRm9udEJCb3ggWzgzIDcxIDY2 MyA2NDldCi9Gb250TWF0cml4IFswLjAwMSAwIDAgMC4wMDEgMCAwXQovRmlyc3RDaGFyIDEK L0xhc3RDaGFyIDEKL0VuY29kaW5nIDE3OCAwIFIKL0NoYXJQcm9jcyAxNzkgMCBSCi9XaWR0 aHMgWzc0OCBdCj4+CmVuZG9iagoxNzggMCBvYmoKPDwKL1R5cGUgL0VuY29kaW5nCi9EaWZm ZXJlbmNlcyBbMS9nbHlwaDEgXQo+PgplbmRvYmoKMTc5IDAgb2JqCjw8Ci9nbHlwaDEgMTgw IDAgUgo+PgplbmRvYmoKMTgwIDAgb2JqCjw8Ci9MZW5ndGggMTQwCi9GaWx0ZXIgL0ZsYXRl RGVjb2RlCj4+CnN0cmVhbQ0KSIk0T7sRQzEI6z2FRjCY7zwvl7sU2b8N4EslGWRJuAQ24sAJ ZgcmiRctwgerpsc2vk1EDEQbSgoyhVriWUwJ4wOOmJ/HZfBZojlM+Sq0PNR3bexYufikiVzs mNoUY1e0gnepgkHKtWmXTLRp9eyUgoqPeXeLjKl15UQ13N5nsRviH/BePwEGAPi+LLMKZW5k c3RyZWFtCmVuZG9iagoxODEgMCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgXQo+PgplbmRvYmoK NjMgMCBvYmoKPDwKL05hbWUgL1QyMAovVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTMKL1Jl c291cmNlcyAxODEgMCBSCi9Gb250QkJveCBbLTEgMjI0IDU1NCAyOTVdCi9Gb250TWF0cml4 IFswLjAwMSAwIDAgMC4wMDEgMCAwXQovRmlyc3RDaGFyIDE1MAovTGFzdENoYXIgMTUwCi9F bmNvZGluZyAxODIgMCBSCi9DaGFyUHJvY3MgMTgzIDAgUgovV2lkdGhzIFs1NTYgXQo+Pgpl bmRvYmoKMTgyIDAgb2JqCjw8Ci9UeXBlIC9FbmNvZGluZwovRGlmZmVyZW5jZXMgWzE1MC9n bHlwaDEgXQo+PgplbmRvYmoKMTgzIDAgb2JqCjw8Ci9nbHlwaDEgMTg0IDAgUgo+PgplbmRv YmoKMTg0IDAgb2JqCjw8Ci9MZW5ndGggNTYKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtDQpIiTI1NVMwUNA1VDAyMlEwNTVRMLI0VUgx5DJUyFTgAgkDuaampgq65oYKRalcaVwA AQYA4P4JSwplbmRzdHJlYW0KZW5kb2JqCjE4NSAwIG9iago8PAovUHJvY1NldCBbL1BERiBd Cj4+CmVuZG9iago2NCAwIG9iago8PAovTmFtZSAvVDIxCi9UeXBlIC9Gb250Ci9TdWJ0eXBl IC9UeXBlMwovUmVzb3VyY2VzIDE4NSAwIFIKL0ZvbnRCQm94IFs4MyA3MSA2NjMgNjQ5XQov Rm9udE1hdHJpeCBbMC4wMDEgMCAwIDAuMDAxIDAgMF0KL0ZpcnN0Q2hhciAxCi9MYXN0Q2hh ciAxCi9FbmNvZGluZyAxODYgMCBSCi9DaGFyUHJvY3MgMTg3IDAgUgovV2lkdGhzIFs3NDgg XQo+PgplbmRvYmoKMTg2IDAgb2JqCjw8Ci9UeXBlIC9FbmNvZGluZwovRGlmZmVyZW5jZXMg WzEvZ2x5cGgxIF0KPj4KZW5kb2JqCjE4NyAwIG9iago8PAovZ2x5cGgxIDE4OCAwIFIKPj4K ZW5kb2JqCjE4OCAwIG9iago8PAovTGVuZ3RoIDE0MAovRmlsdGVyIC9GbGF0ZURlY29kZQo+ PgpzdHJlYW0NCkiJNE+7EUMxCOs9hUYwmO88L5e7FNm/DeBLJRlkSbgENuLACWYHJokXLcIH q6bHNr5NRAxEG0oKMoVa4llMCeMDjpifx2XwWaI5TPkqtDzUd23sWLn4pIlc7JjaFGNXtIJ3 qYJByrVpl0y0afXslIKKj3l3i4ypdeVENdzeZ7Eb4h/wXj8BBgD4viyzCmVuZHN0cmVhbQpl bmRvYmoKMTg5IDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERGIF0KPj4KZW5kb2JqCjY4IDAgb2Jq Cjw8Ci9OYW1lIC9UMjIKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUzCi9SZXNvdXJjZXMg MTg5IDAgUgovRm9udEJCb3ggWy0xIDIyNCA1NTQgMjk1XQovRm9udE1hdHJpeCBbMC4wMDEg MCAwIDAuMDAxIDAgMF0KL0ZpcnN0Q2hhciAxNTAKL0xhc3RDaGFyIDE1MAovRW5jb2Rpbmcg MTkwIDAgUgovQ2hhclByb2NzIDE5MSAwIFIKL1dpZHRocyBbNTU2IF0KPj4KZW5kb2JqCjE5 MCAwIG9iago8PAovVHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsxNTAvZ2x5cGgxIF0K Pj4KZW5kb2JqCjE5MSAwIG9iago8PAovZ2x5cGgxIDE5MiAwIFIKPj4KZW5kb2JqCjE5MiAw IG9iago8PAovTGVuZ3RoIDU2Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0KSIky NTVTMFDQNVQwMjJRMDU1UTCyNFVIMeQyVMhU4AIJA7mmpqYKuuaGCkWpXGlcAAEGAOD+CUsK ZW5kc3RyZWFtCmVuZG9iagoxOTMgMCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgXQo+PgplbmRv YmoKNjkgMCBvYmoKPDwKL05hbWUgL1QyMwovVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTMK L1Jlc291cmNlcyAxOTMgMCBSCi9Gb250QkJveCBbODMgNzEgNjYzIDY0OV0KL0ZvbnRNYXRy aXggWzAuMDAxIDAgMCAwLjAwMSAwIDBdCi9GaXJzdENoYXIgMQovTGFzdENoYXIgMQovRW5j b2RpbmcgMTk0IDAgUgovQ2hhclByb2NzIDE5NSAwIFIKL1dpZHRocyBbNzQ4IF0KPj4KZW5k b2JqCjE5NCAwIG9iago8PAovVHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsxL2dseXBo MSBdCj4+CmVuZG9iagoxOTUgMCBvYmoKPDwKL2dseXBoMSAxOTYgMCBSCj4+CmVuZG9iagox OTYgMCBvYmoKPDwKL0xlbmd0aCAxNDAKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFt DQpIiTRPuxFDMQjrPYVGMJjvPC+XuxTZvw3gSyUZZEm4BDbiwAlmByaJFy3CB6umxza+TUQM RBtKCjKFWuJZTAnjA46Yn8dl8FmiOUz5KrQ81Hdt7Fi5+KSJXOyY2hRjV7SCd6mCQcq1aZdM tGn17JSCio95d4uMqXXlRDXc3mexG+If8F4/AQYA+L4sswplbmRzdHJlYW0KZW5kb2JqCjE5 NyAwIG9iago8PAovUHJvY1NldCBbL1BERiBdCj4+CmVuZG9iago3MyAwIG9iago8PAovTmFt ZSAvVDI0Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMwovUmVzb3VyY2VzIDE5NyAwIFIK L0ZvbnRCQm94IFstMSAyMjQgNTU0IDI5NV0KL0ZvbnRNYXRyaXggWzAuMDAxIDAgMCAwLjAw MSAwIDBdCi9GaXJzdENoYXIgMTUwCi9MYXN0Q2hhciAxNTAKL0VuY29kaW5nIDE5OCAwIFIK L0NoYXJQcm9jcyAxOTkgMCBSCi9XaWR0aHMgWzU1NiBdCj4+CmVuZG9iagoxOTggMCBvYmoK PDwKL1R5cGUgL0VuY29kaW5nCi9EaWZmZXJlbmNlcyBbMTUwL2dseXBoMSBdCj4+CmVuZG9i agoxOTkgMCBvYmoKPDwKL2dseXBoMSAyMDAgMCBSCj4+CmVuZG9iagoyMDAgMCBvYmoKPDwK L0xlbmd0aCA1NgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0NCkiJMjU1UzBQ0DVU MDIyUTA1NVEwsjRVSDHkMlTIVOACCQO5pqamCrrmhgpFqVxpXAABBgDg/glLCmVuZHN0cmVh bQplbmRvYmoKMjAxIDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERGIF0KPj4KZW5kb2JqCjc0IDAg b2JqCjw8Ci9OYW1lIC9UMjUKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUzCi9SZXNvdXJj ZXMgMjAxIDAgUgovRm9udEJCb3ggWzgzIDcxIDY2MyA2NDldCi9Gb250TWF0cml4IFswLjAw MSAwIDAgMC4wMDEgMCAwXQovRmlyc3RDaGFyIDEKL0xhc3RDaGFyIDEKL0VuY29kaW5nIDIw MiAwIFIKL0NoYXJQcm9jcyAyMDMgMCBSCi9XaWR0aHMgWzc0OCBdCj4+CmVuZG9iagoyMDIg MCBvYmoKPDwKL1R5cGUgL0VuY29kaW5nCi9EaWZmZXJlbmNlcyBbMS9nbHlwaDEgXQo+Pgpl bmRvYmoKMjAzIDAgb2JqCjw8Ci9nbHlwaDEgMjA0IDAgUgo+PgplbmRvYmoKMjA0IDAgb2Jq Cjw8Ci9MZW5ndGggMTQwCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0KSIk0T7sR QzEI6z2FRjCY7zwvl7sU2b8N4EslGWRJuAQ24sAJZgcmiRctwgerpsc2vk1EDEQbSgoyhVri WUwJ4wOOmJ/HZfBZojlM+Sq0PNR3bexYufikiVzsmNoUY1e0gnepgkHKtWmXTLRp9eyUgoqP eXeLjKl15UQ13N5nsRviH/BePwEGAPi+LLMKZW5kc3RyZWFtCmVuZG9iagoyMDUgMCBvYmoK PDwKL1Byb2NTZXQgWy9QREYgXQo+PgplbmRvYmoKNzggMCBvYmoKPDwKL05hbWUgL1QyNgov VHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTMKL1Jlc291cmNlcyAyMDUgMCBSCi9Gb250QkJv eCBbLTEgMjI0IDU1NCAyOTVdCi9Gb250TWF0cml4IFswLjAwMSAwIDAgMC4wMDEgMCAwXQov Rmlyc3RDaGFyIDE1MAovTGFzdENoYXIgMTUwCi9FbmNvZGluZyAyMDYgMCBSCi9DaGFyUHJv Y3MgMjA3IDAgUgovV2lkdGhzIFs1NTYgXQo+PgplbmRvYmoKMjA2IDAgb2JqCjw8Ci9UeXBl IC9FbmNvZGluZwovRGlmZmVyZW5jZXMgWzE1MC9nbHlwaDEgXQo+PgplbmRvYmoKMjA3IDAg b2JqCjw8Ci9nbHlwaDEgMjA4IDAgUgo+PgplbmRvYmoKMjA4IDAgb2JqCjw8Ci9MZW5ndGgg NTYKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQpIiTI1NVMwUNA1VDAyMlEwNTVR MLI0VUgx5DJUyFTgAgkDuaampgq65oYKRalcaVwAAQYA4P4JSwplbmRzdHJlYW0KZW5kb2Jq CjIwOSAwIG9iago8PAovUHJvY1NldCBbL1BERiBdCj4+CmVuZG9iago3OSAwIG9iago8PAov TmFtZSAvVDI3Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMwovUmVzb3VyY2VzIDIwOSAw IFIKL0ZvbnRCQm94IFs4MyA3MSA2NjMgNjQ5XQovRm9udE1hdHJpeCBbMC4wMDEgMCAwIDAu MDAxIDAgMF0KL0ZpcnN0Q2hhciAxCi9MYXN0Q2hhciAxCi9FbmNvZGluZyAyMTAgMCBSCi9D aGFyUHJvY3MgMjExIDAgUgovV2lkdGhzIFs3NDggXQo+PgplbmRvYmoKMjEwIDAgb2JqCjw8 Ci9UeXBlIC9FbmNvZGluZwovRGlmZmVyZW5jZXMgWzEvZ2x5cGgxIF0KPj4KZW5kb2JqCjIx MSAwIG9iago8PAovZ2x5cGgxIDIxMiAwIFIKPj4KZW5kb2JqCjIxMiAwIG9iago8PAovTGVu Z3RoIDE0MAovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0NCkiJNE+7EUMxCOs9hUYw mO88L5e7FNm/DeBLJRlkSbgENuLACWYHJokXLcIHq6bHNr5NRAxEG0oKMoVa4llMCeMDjpif x2XwWaI5TPkqtDzUd23sWLn4pIlc7JjaFGNXtIJ3qYJByrVpl0y0afXslIKKj3l3i4ypdeVE NdzeZ7Eb4h/wXj8BBgD4viyzCmVuZHN0cmVhbQplbmRvYmoKMjEzIDAgb2JqCjw8Ci9Qcm9j U2V0IFsvUERGIF0KPj4KZW5kb2JqCjgzIDAgb2JqCjw8Ci9OYW1lIC9UMjgKL1R5cGUgL0Zv bnQKL1N1YnR5cGUgL1R5cGUzCi9SZXNvdXJjZXMgMjEzIDAgUgovRm9udEJCb3ggWzgzIDcx IDY2MyA2NDldCi9Gb250TWF0cml4IFswLjAwMSAwIDAgMC4wMDEgMCAwXQovRmlyc3RDaGFy IDEKL0xhc3RDaGFyIDEKL0VuY29kaW5nIDIxNCAwIFIKL0NoYXJQcm9jcyAyMTUgMCBSCi9X aWR0aHMgWzc0OCBdCj4+CmVuZG9iagoyMTQgMCBvYmoKPDwKL1R5cGUgL0VuY29kaW5nCi9E aWZmZXJlbmNlcyBbMS9nbHlwaDEgXQo+PgplbmRvYmoKMjE1IDAgb2JqCjw8Ci9nbHlwaDEg MjE2IDAgUgo+PgplbmRvYmoKMjE2IDAgb2JqCjw8Ci9MZW5ndGggMTQwCi9GaWx0ZXIgL0Zs YXRlRGVjb2RlCj4+CnN0cmVhbQ0KSIk0T7sRQzEI6z2FRjCY7zwvl7sU2b8N4EslGWRJuAQ2 4sAJZgcmiRctwgerpsc2vk1EDEQbSgoyhVriWUwJ4wOOmJ/HZfBZojlM+Sq0PNR3bexYufik iVzsmNoUY1e0gnepgkHKtWmXTLRp9eyUgoqPeXeLjKl15UQ13N5nsRviH/BePwEGAPi+LLMK ZW5kc3RyZWFtCmVuZG9iagoyMTcgMCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgXQo+PgplbmRv YmoKODcgMCBvYmoKPDwKL05hbWUgL1QyOQovVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTMK L1Jlc291cmNlcyAyMTcgMCBSCi9Gb250QkJveCBbLTEgMjI0IDU1NCAyOTVdCi9Gb250TWF0 cml4IFswLjAwMSAwIDAgMC4wMDEgMCAwXQovRmlyc3RDaGFyIDE1MAovTGFzdENoYXIgMTUw Ci9FbmNvZGluZyAyMTggMCBSCi9DaGFyUHJvY3MgMjE5IDAgUgovV2lkdGhzIFs1NTYgXQo+ PgplbmRvYmoKMjE4IDAgb2JqCjw8Ci9UeXBlIC9FbmNvZGluZwovRGlmZmVyZW5jZXMgWzE1 MC9nbHlwaDEgXQo+PgplbmRvYmoKMjE5IDAgb2JqCjw8Ci9nbHlwaDEgMjIwIDAgUgo+Pgpl bmRvYmoKMjIwIDAgb2JqCjw8Ci9MZW5ndGggNTYKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4K c3RyZWFtDQpIiTI1NVMwUNA1VDAyMlEwNTVRMLI0VUgx5DJUyFTgAgkDuaampgq65oYKRalc aVwAAQYA4P4JSwplbmRzdHJlYW0KZW5kb2JqCjIyMSAwIG9iago8PAovUHJvY1NldCBbL1BE RiBdCj4+CmVuZG9iago4OCAwIG9iago8PAovTmFtZSAvVDMwCi9UeXBlIC9Gb250Ci9TdWJ0 eXBlIC9UeXBlMwovUmVzb3VyY2VzIDIyMSAwIFIKL0ZvbnRCQm94IFs4MyA3MSA2NjMgNjQ5 XQovRm9udE1hdHJpeCBbMC4wMDEgMCAwIDAuMDAxIDAgMF0KL0ZpcnN0Q2hhciAxCi9MYXN0 Q2hhciAxCi9FbmNvZGluZyAyMjIgMCBSCi9DaGFyUHJvY3MgMjIzIDAgUgovV2lkdGhzIFs3 NDggXQo+PgplbmRvYmoKMjIyIDAgb2JqCjw8Ci9UeXBlIC9FbmNvZGluZwovRGlmZmVyZW5j ZXMgWzEvZ2x5cGgxIF0KPj4KZW5kb2JqCjIyMyAwIG9iago8PAovZ2x5cGgxIDIyNCAwIFIK Pj4KZW5kb2JqCjIyNCAwIG9iago8PAovTGVuZ3RoIDE0MAovRmlsdGVyIC9GbGF0ZURlY29k ZQo+PgpzdHJlYW0NCkiJNE+7EUMxCOs9hUYwmO88L5e7FNm/DeBLJRlkSbgENuLACWYHJokX LcIHq6bHNr5NRAxEG0oKMoVa4llMCeMDjpifx2XwWaI5TPkqtDzUd23sWLn4pIlc7JjaFGNX tIJ3qYJByrVpl0y0afXslIKKj3l3i4ypdeVENdzeZ7Eb4h/wXj8BBgD4viyzCmVuZHN0cmVh bQplbmRvYmoKMjI1IDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERGIF0KPj4KZW5kb2JqCjkyIDAg b2JqCjw8Ci9OYW1lIC9UMzEKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUzCi9SZXNvdXJj ZXMgMjI1IDAgUgovRm9udEJCb3ggWy0xIDIyNCA1NTQgMjk1XQovRm9udE1hdHJpeCBbMC4w MDEgMCAwIDAuMDAxIDAgMF0KL0ZpcnN0Q2hhciAxNTAKL0xhc3RDaGFyIDE1MAovRW5jb2Rp bmcgMjI2IDAgUgovQ2hhclByb2NzIDIyNyAwIFIKL1dpZHRocyBbNTU2IF0KPj4KZW5kb2Jq CjIyNiAwIG9iago8PAovVHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsxNTAvZ2x5cGgx IF0KPj4KZW5kb2JqCjIyNyAwIG9iago8PAovZ2x5cGgxIDIyOCAwIFIKPj4KZW5kb2JqCjIy OCAwIG9iago8PAovTGVuZ3RoIDU2Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0K SIkyNTVTMFDQNVQwMjJRMDU1UTCyNFVIMeQyVMhU4AIJA7mmpqYKuuaGCkWpXGlcAAEGAOD+ CUsKZW5kc3RyZWFtCmVuZG9iagoyMjkgMCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgXQo+Pgpl bmRvYmoKOTMgMCBvYmoKPDwKL05hbWUgL1QzMgovVHlwZSAvRm9udAovU3VidHlwZSAvVHlw ZTMKL1Jlc291cmNlcyAyMjkgMCBSCi9Gb250QkJveCBbODMgNzEgNjYzIDY0OV0KL0ZvbnRN YXRyaXggWzAuMDAxIDAgMCAwLjAwMSAwIDBdCi9GaXJzdENoYXIgMQovTGFzdENoYXIgMQov RW5jb2RpbmcgMjMwIDAgUgovQ2hhclByb2NzIDIzMSAwIFIKL1dpZHRocyBbNzQ4IF0KPj4K ZW5kb2JqCjIzMCAwIG9iago8PAovVHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsxL2ds eXBoMSBdCj4+CmVuZG9iagoyMzEgMCBvYmoKPDwKL2dseXBoMSAyMzIgMCBSCj4+CmVuZG9i agoyMzIgMCBvYmoKPDwKL0xlbmd0aCAxNDAKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtDQpIiTRPuxFDMQjrPYVGMJjvPC+XuxTZvw3gSyUZZEm4BDbiwAlmByaJFy3CB6umxza+ TUQMRBtKCjKFWuJZTAnjA46Yn8dl8FmiOUz5KrQ81Hdt7Fi5+KSJXOyY2hRjV7SCd6mCQcq1 aZdMtGn17JSCio95d4uMqXXlRDXc3mexG+If8F4/AQYA+L4sswplbmRzdHJlYW0KZW5kb2Jq CjIzMyAwIG9iago8PAovUHJvY1NldCBbL1BERiBdCj4+CmVuZG9iago5NyAwIG9iago8PAov TmFtZSAvVDMzCi9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMwovUmVzb3VyY2VzIDIzMyAw IFIKL0ZvbnRCQm94IFstMSAyMjQgNTU0IDI5NV0KL0ZvbnRNYXRyaXggWzAuMDAxIDAgMCAw LjAwMSAwIDBdCi9GaXJzdENoYXIgMTUwCi9MYXN0Q2hhciAxNTAKL0VuY29kaW5nIDIzNCAw IFIKL0NoYXJQcm9jcyAyMzUgMCBSCi9XaWR0aHMgWzU1NiBdCj4+CmVuZG9iagoyMzQgMCBv YmoKPDwKL1R5cGUgL0VuY29kaW5nCi9EaWZmZXJlbmNlcyBbMTUwL2dseXBoMSBdCj4+CmVu ZG9iagoyMzUgMCBvYmoKPDwKL2dseXBoMSAyMzYgMCBSCj4+CmVuZG9iagoyMzYgMCBvYmoK PDwKL0xlbmd0aCA1NgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0NCkiJMjU1UzBQ 0DVUMDIyUTA1NVEwsjRVSDHkMlTIVOACCQO5pqamCrrmhgpFqVxpXAABBgDg/glLCmVuZHN0 cmVhbQplbmRvYmoKMjM3IDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERGIF0KPj4KZW5kb2JqCjk4 IDAgb2JqCjw8Ci9OYW1lIC9UMzQKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUzCi9SZXNv dXJjZXMgMjM3IDAgUgovRm9udEJCb3ggWzgzIDcxIDY2MyA2NDldCi9Gb250TWF0cml4IFsw LjAwMSAwIDAgMC4wMDEgMCAwXQovRmlyc3RDaGFyIDEKL0xhc3RDaGFyIDEKL0VuY29kaW5n IDIzOCAwIFIKL0NoYXJQcm9jcyAyMzkgMCBSCi9XaWR0aHMgWzc0OCBdCj4+CmVuZG9iagoy MzggMCBvYmoKPDwKL1R5cGUgL0VuY29kaW5nCi9EaWZmZXJlbmNlcyBbMS9nbHlwaDEgXQo+ PgplbmRvYmoKMjM5IDAgb2JqCjw8Ci9nbHlwaDEgMjQwIDAgUgo+PgplbmRvYmoKMjQwIDAg b2JqCjw8Ci9MZW5ndGggMTQwCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0KSIk0 T7sRQzEI6z2FRjCY7zwvl7sU2b8N4EslGWRJuAQ24sAJZgcmiRctwgerpsc2vk1EDEQbSgoy hVriWUwJ4wOOmJ/HZfBZojlM+Sq0PNR3bexYufikiVzsmNoUY1e0gnepgkHKtWmXTLRp9eyU goqPeXeLjKl15UQ13N5nsRviH/BePwEGAPi+LLMKZW5kc3RyZWFtCmVuZG9iagoyNDEgMCBv YmoKPDwKL1Byb2NTZXQgWy9QREYgXQo+PgplbmRvYmoKMTAyIDAgb2JqCjw8Ci9OYW1lIC9U MzUKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUzCi9SZXNvdXJjZXMgMjQxIDAgUgovRm9u dEJCb3ggWy0xIDIyNCA1NTQgMjk1XQovRm9udE1hdHJpeCBbMC4wMDEgMCAwIDAuMDAxIDAg MF0KL0ZpcnN0Q2hhciAxNTAKL0xhc3RDaGFyIDE1MAovRW5jb2RpbmcgMjQyIDAgUgovQ2hh clByb2NzIDI0MyAwIFIKL1dpZHRocyBbNTU2IF0KPj4KZW5kb2JqCjI0MiAwIG9iago8PAov VHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsxNTAvZ2x5cGgxIF0KPj4KZW5kb2JqCjI0 MyAwIG9iago8PAovZ2x5cGgxIDI0NCAwIFIKPj4KZW5kb2JqCjI0NCAwIG9iago8PAovTGVu Z3RoIDU2Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0KSIkyNTVTMFDQNVQwMjJR MDU1UTCyNFVIMeQyVMhU4AIJA7mmpqYKuuaGCkWpXGlcAAEGAOD+CUsKZW5kc3RyZWFtCmVu ZG9iagoyNDUgMCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgXQo+PgplbmRvYmoKMTAzIDAgb2Jq Cjw8Ci9OYW1lIC9UMzYKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUzCi9SZXNvdXJjZXMg MjQ1IDAgUgovRm9udEJCb3ggWzgzIDcxIDY2MyA2NDldCi9Gb250TWF0cml4IFswLjAwMSAw IDAgMC4wMDEgMCAwXQovRmlyc3RDaGFyIDEKL0xhc3RDaGFyIDEKL0VuY29kaW5nIDI0NiAw IFIKL0NoYXJQcm9jcyAyNDcgMCBSCi9XaWR0aHMgWzc0OCBdCj4+CmVuZG9iagoyNDYgMCBv YmoKPDwKL1R5cGUgL0VuY29kaW5nCi9EaWZmZXJlbmNlcyBbMS9nbHlwaDEgXQo+PgplbmRv YmoKMjQ3IDAgb2JqCjw8Ci9nbHlwaDEgMjQ4IDAgUgo+PgplbmRvYmoKMjQ4IDAgb2JqCjw8 Ci9MZW5ndGggMTQwCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0KSIk0T7sRQzEI 6z2FRjCY7zwvl7sU2b8N4EslGWRJuAQ24sAJZgcmiRctwgerpsc2vk1EDEQbSgoyhVriWUwJ 4wOOmJ/HZfBZojlM+Sq0PNR3bexYufikiVzsmNoUY1e0gnepgkHKtWmXTLRp9eyUgoqPeXeL jKl15UQ13N5nsRviH/BePwEGAPi+LLMKZW5kc3RyZWFtCmVuZG9iago0IDAgb2JqCjw8Ci9U eXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovTmFtZSAvRjIKL0VuY29kaW5nIDI0OSAwIFIK L0Jhc2VGb250IC9UaW1lcy1Sb21hbgo+PgplbmRvYmoKNSAwIG9iago8PAovVHlwZSAvRm9u dAovU3VidHlwZSAvVHlwZTEKL05hbWUgL0Y0Ci9FbmNvZGluZyAyNDkgMCBSCi9CYXNlRm9u dCAvVGltZXMtQm9sZAo+PgplbmRvYmoKMzggMCBvYmoKPDwKL1R5cGUgL0ZvbnQKL1N1YnR5 cGUgL1R5cGUxCi9OYW1lIC9GNgovRW5jb2RpbmcgMjUwIDAgUgovQmFzZUZvbnQgL0NvdXJp ZXIKPj4KZW5kb2JqCjI0OSAwIG9iago8PAovVHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2Vz IFsgMzkvcXVvdGVzaW5nbGUgOTYvZ3JhdmUgMTI3L3VudXNlZC9FdXJvL3VudXNlZC9xdW90 ZXNpbmdsYmFzZS9mbG9yaW4vcXVvdGVkYmxiYXNlCi9lbGxpcHNpcy9kYWdnZXIvZGFnZ2Vy ZGJsL2NpcmN1bWZsZXgvcGVydGhvdXNhbmQvU2Nhcm9uL2d1aWxzaW5nbGxlZnQvT0UKL3Vu dXNlZC9aY2Fyb24vdW51c2VkL3VudXNlZC9xdW90ZWxlZnQvcXVvdGVyaWdodC9xdW90ZWRi bGxlZnQvcXVvdGVkYmxyaWdodAovYnVsbGV0L2VuZGFzaC9lbWRhc2gvdGlsZGUvdHJhZGVt YXJrL3NjYXJvbi9ndWlsc2luZ2xyaWdodC9vZQovdW51c2VkL3pjYXJvbi9ZZGllcmVzaXMv c3BhY2UgMTY0L2N1cnJlbmN5IDE2Ni9icm9rZW5iYXIgMTY4L2RpZXJlc2lzL2NvcHlyaWdo dAovb3JkZmVtaW5pbmUgMTcyL2xvZ2ljYWxub3QvaHlwaGVuL3JlZ2lzdGVyZWQvbWFjcm9u L2RlZ3JlZS9wbHVzbWludXMvdHdvc3VwZXJpb3IKL3RocmVlc3VwZXJpb3IvYWN1dGUvbXUg MTgzL3BlcmlvZGNlbnRlcmVkL2NlZGlsbGEvb25lc3VwZXJpb3Ivb3JkbWFzY3VsaW5lIDE4 OC9vbmVxdWFydGVyCi9vbmVoYWxmL3RocmVlcXVhcnRlcnMgMTkyL0FncmF2ZS9BYWN1dGUv QWNpcmN1bWZsZXgvQXRpbGRlL0FkaWVyZXNpcy9BcmluZwovQUUvQ2NlZGlsbGEvRWdyYXZl L0VhY3V0ZS9FY2lyY3VtZmxleC9FZGllcmVzaXMvSWdyYXZlL0lhY3V0ZQovSWNpcmN1bWZs ZXgvSWRpZXJlc2lzL0V0aC9OdGlsZGUvT2dyYXZlL09hY3V0ZS9PY2lyY3VtZmxleC9PdGls ZGUKL09kaWVyZXNpcy9tdWx0aXBseS9Pc2xhc2gvVWdyYXZlL1VhY3V0ZS9VY2lyY3VtZmxl eC9VZGllcmVzaXMvWWFjdXRlCi9UaG9ybi9nZXJtYW5kYmxzL2FncmF2ZS9hYWN1dGUvYWNp cmN1bWZsZXgvYXRpbGRlL2FkaWVyZXNpcy9hcmluZwovYWUvY2NlZGlsbGEvZWdyYXZlL2Vh Y3V0ZS9lY2lyY3VtZmxleC9lZGllcmVzaXMvaWdyYXZlL2lhY3V0ZQovaWNpcmN1bWZsZXgv aWRpZXJlc2lzL2V0aC9udGlsZGUvb2dyYXZlL29hY3V0ZS9vY2lyY3VtZmxleC9vdGlsZGUK L29kaWVyZXNpcy9kaXZpZGUvb3NsYXNoL3VncmF2ZS91YWN1dGUvdWNpcmN1bWZsZXgvdWRp ZXJlc2lzL3lhY3V0ZQovdGhvcm4veWRpZXJlc2lzCl0KPj4KZW5kb2JqCjI1MCAwIG9iago8 PAovVHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsgMzkvcXVvdGVzaW5nbGUgOTYvZ3Jh dmUgMTI3L3VudXNlZC9FdXJvL3VudXNlZC9xdW90ZXNpbmdsYmFzZS9mbG9yaW4vcXVvdGVk YmxiYXNlCi9lbGxpcHNpcy9kYWdnZXIvZGFnZ2VyZGJsL2NpcmN1bWZsZXgvcGVydGhvdXNh bmQvU2Nhcm9uL2d1aWxzaW5nbGxlZnQvT0UKL3VudXNlZC9aY2Fyb24vdW51c2VkL3VudXNl ZC9xdW90ZWxlZnQvcXVvdGVyaWdodC9xdW90ZWRibGxlZnQvcXVvdGVkYmxyaWdodAovYnVs bGV0L2VuZGFzaC9lbWRhc2gvdGlsZGUvdHJhZGVtYXJrL3NjYXJvbi9ndWlsc2luZ2xyaWdo dC9vZQovdW51c2VkL3pjYXJvbi9ZZGllcmVzaXMvc3BhY2UgMTY0L2N1cnJlbmN5IDE2Ni9i cm9rZW5iYXIgMTY4L2RpZXJlc2lzL2NvcHlyaWdodAovb3JkZmVtaW5pbmUgMTcyL2xvZ2lj YWxub3QvaHlwaGVuL3JlZ2lzdGVyZWQvbWFjcm9uL2RlZ3JlZS9wbHVzbWludXMvdHdvc3Vw ZXJpb3IKL3RocmVlc3VwZXJpb3IvYWN1dGUvbXUgMTgzL3BlcmlvZGNlbnRlcmVkL2NlZGls bGEvb25lc3VwZXJpb3Ivb3JkbWFzY3VsaW5lIDE4OC9vbmVxdWFydGVyCi9vbmVoYWxmL3Ro cmVlcXVhcnRlcnMgMTkyL0FncmF2ZS9BYWN1dGUvQWNpcmN1bWZsZXgvQXRpbGRlL0FkaWVy ZXNpcy9BcmluZwovQUUvQ2NlZGlsbGEvRWdyYXZlL0VhY3V0ZS9FY2lyY3VtZmxleC9FZGll cmVzaXMvSWdyYXZlL0lhY3V0ZQovSWNpcmN1bWZsZXgvSWRpZXJlc2lzL0V0aC9OdGlsZGUv T2dyYXZlL09hY3V0ZS9PY2lyY3VtZmxleC9PdGlsZGUKL09kaWVyZXNpcy9tdWx0aXBseS9P c2xhc2gvVWdyYXZlL1VhY3V0ZS9VY2lyY3VtZmxleC9VZGllcmVzaXMvWWFjdXRlCi9UaG9y bi9nZXJtYW5kYmxzL2FncmF2ZS9hYWN1dGUvYWNpcmN1bWZsZXgvYXRpbGRlL2FkaWVyZXNp cy9hcmluZwovYWUvY2NlZGlsbGEvZWdyYXZlL2VhY3V0ZS9lY2lyY3VtZmxleC9lZGllcmVz aXMvaWdyYXZlL2lhY3V0ZQovaWNpcmN1bWZsZXgvaWRpZXJlc2lzL2V0aC9udGlsZGUvb2dy YXZlL29hY3V0ZS9vY2lyY3VtZmxleC9vdGlsZGUKL29kaWVyZXNpcy9kaXZpZGUvb3NsYXNo L3VncmF2ZS91YWN1dGUvdWNpcmN1bWZsZXgvdWRpZXJlc2lzL3lhY3V0ZQovdGhvcm4veWRp ZXJlc2lzCl0KPj4KZW5kb2JqCjEgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCA3IDAg UgovUmVzb3VyY2VzIDMgMCBSCi9Db250ZW50cyAyIDAgUgo+PgplbmRvYmoKOCAwIG9iago8 PAovVHlwZSAvUGFnZQovUGFyZW50IDcgMCBSCi9SZXNvdXJjZXMgMTAgMCBSCi9Db250ZW50 cyA5IDAgUgo+PgplbmRvYmoKMTEgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCA3IDAg UgovUmVzb3VyY2VzIDEzIDAgUgovQ29udGVudHMgMTIgMCBSCj4+CmVuZG9iagoxNiAwIG9i ago8PAovVHlwZSAvUGFnZQovUGFyZW50IDcgMCBSCi9SZXNvdXJjZXMgMTggMCBSCi9Db250 ZW50cyAxNyAwIFIKPj4KZW5kb2JqCjIxIDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQg NyAwIFIKL1Jlc291cmNlcyAyMyAwIFIKL0NvbnRlbnRzIDIyIDAgUgo+PgplbmRvYmoKMjUg MCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCA3IDAgUgovUmVzb3VyY2VzIDI3IDAgUgov Q29udGVudHMgMjYgMCBSCj4+CmVuZG9iagozMCAwIG9iago8PAovVHlwZSAvUGFnZQovUGFy ZW50IDcgMCBSCi9SZXNvdXJjZXMgMzIgMCBSCi9Db250ZW50cyAzMSAwIFIKPj4KZW5kb2Jq CjM1IDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgNyAwIFIKL1Jlc291cmNlcyAzNyAw IFIKL0NvbnRlbnRzIDM2IDAgUgo+PgplbmRvYmoKNDEgMCBvYmoKPDwKL1R5cGUgL1BhZ2UK L1BhcmVudCA3IDAgUgovUmVzb3VyY2VzIDQzIDAgUgovQ29udGVudHMgNDIgMCBSCj4+CmVu ZG9iago0NyAwIG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50IDcgMCBSCi9SZXNvdXJjZXMg NDkgMCBSCi9Db250ZW50cyA0OCAwIFIKPj4KZW5kb2JqCjUzIDAgb2JqCjw8Ci9UeXBlIC9Q YWdlCi9QYXJlbnQgNTkgMCBSCi9SZXNvdXJjZXMgNTUgMCBSCi9Db250ZW50cyA1NCAwIFIK Pj4KZW5kb2JqCjYwIDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgNTkgMCBSCi9SZXNv dXJjZXMgNjIgMCBSCi9Db250ZW50cyA2MSAwIFIKPj4KZW5kb2JqCjY1IDAgb2JqCjw8Ci9U eXBlIC9QYWdlCi9QYXJlbnQgNTkgMCBSCi9SZXNvdXJjZXMgNjcgMCBSCi9Db250ZW50cyA2 NiAwIFIKPj4KZW5kb2JqCjcwIDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgNTkgMCBS Ci9SZXNvdXJjZXMgNzIgMCBSCi9Db250ZW50cyA3MSAwIFIKPj4KZW5kb2JqCjc1IDAgb2Jq Cjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgNTkgMCBSCi9SZXNvdXJjZXMgNzcgMCBSCi9Db250 ZW50cyA3NiAwIFIKPj4KZW5kb2JqCjgwIDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQg NTkgMCBSCi9SZXNvdXJjZXMgODIgMCBSCi9Db250ZW50cyA4MSAwIFIKPj4KZW5kb2JqCjg0 IDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgNTkgMCBSCi9SZXNvdXJjZXMgODYgMCBS Ci9Db250ZW50cyA4NSAwIFIKPj4KZW5kb2JqCjg5IDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9Q YXJlbnQgNTkgMCBSCi9SZXNvdXJjZXMgOTEgMCBSCi9Db250ZW50cyA5MCAwIFIKPj4KZW5k b2JqCjk0IDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgNTkgMCBSCi9SZXNvdXJjZXMg OTYgMCBSCi9Db250ZW50cyA5NSAwIFIKPj4KZW5kb2JqCjk5IDAgb2JqCjw8Ci9UeXBlIC9Q YWdlCi9QYXJlbnQgNTkgMCBSCi9SZXNvdXJjZXMgMTAxIDAgUgovQ29udGVudHMgMTAwIDAg Ugo+PgplbmRvYmoKNyAwIG9iago8PAovVHlwZSAvUGFnZXMKL0tpZHMgWzEgMCBSIDggMCBS IDExIDAgUiAxNiAwIFIgMjEgMCBSIDI1IDAgUiAzMCAwIFIgMzUgMCBSIDQxIDAgUiA0NyAw IFJdCi9Db3VudCAxMAovUGFyZW50IDU4IDAgUgo+PgplbmRvYmoKNTkgMCBvYmoKPDwKL1R5 cGUgL1BhZ2VzCi9LaWRzIFs1MyAwIFIgNjAgMCBSIDY1IDAgUiA3MCAwIFIgNzUgMCBSIDgw IDAgUiA4NCAwIFIgODkgMCBSIDk0IDAgUiA5OSAwIFJdCi9Db3VudCAxMAovUGFyZW50IDU4 IDAgUgo+PgplbmRvYmoKNTggMCBvYmoKPDwKL1R5cGUgL1BhZ2VzCi9LaWRzIFs3IDAgUiA1 OSAwIFIgXQovQ291bnQgMjAKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KPj4KZW5kb2JqCjI1 MSAwIG9iago8PAovVHlwZSAvQ2F0YWxvZwovUGFnZXMgNTggMCBSCj4+CmVuZG9iagoyNTIg MCBvYmoKPDwKL0NyZWF0aW9uRGF0ZSAoRDoxOTEwMzExMTkxNjUwMDEpCi9Qcm9kdWNlciAo QWNyb2JhdCBEaXN0aWxsZXIgQ29tbWFuZCAzLjAxIGZvciBTb2xhcmlzIDIuMyBhbmQgbGF0 ZXIgXChTUEFSQ1wpKQovQXV0aG9yIChudzE0MTI5MikKL0NyZWF0b3IgKFN0YXJPZmZpY2Ug Ni4wICkKL1RpdGxlIChjaGFubmVsLWJpbmRpbmdzLXBsdXMtbm90ZXMuc3hpKQo+PgplbmRv YmoKeHJlZgowIDI1MwowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwNTIyOTEgMDAwMDAgbiAK MDAwMDAwMDAxNiAwMDAwMCBuIAowMDAwMDAwOTA4IDAwMDAwIG4gCjAwMDAwNDk2NjcgMDAw MDAgbiAKMDAwMDA0OTc2NyAwMDAwMCBuIAowMDAwMDMwMTY5IDAwMDAwIG4gCjAwMDAwNTM5 NTggMDAwMDAgbiAKMDAwMDA1MjM3MSAwMDAwMCBuIAowMDAwMDAxMDEyIDAwMDAwIG4gCjAw MDAwMDE4NjAgMDAwMDAgbiAKMDAwMDA1MjQ1MiAwMDAwMCBuIAowMDAwMDAxOTU1IDAwMDAw IG4gCjAwMDAwMDMwOTkgMDAwMDAgbiAKMDAwMDAzMDI4MCAwMDAwMCBuIAowMDAwMDMwNzc2 IDAwMDAwIG4gCjAwMDAwNTI1MzUgMDAwMDAgbiAKMDAwMDAwMzIyNiAwMDAwMCBuIAowMDAw MDA0MTQxIDAwMDAwIG4gCjAwMDAwMzEzNTAgMDAwMDAgbiAKMDAwMDAzMTg0NiAwMDAwMCBu IAowMDAwMDUyNjE4IDAwMDAwIG4gCjAwMDAwMDQyNjggMDAwMDAgbiAKMDAwMDAwNTQ2MyAw MDAwMCBuIAowMDAwMDMyNDIwIDAwMDAwIG4gCjAwMDAwNTI3MDEgMDAwMDAgbiAKMDAwMDAw NTU2OSAwMDAwMCBuIAowMDAwMDA4MDI5IDAwMDAwIG4gCjAwMDAwMzI5OTQgMDAwMDAgbiAK MDAwMDAzMzQ5MCAwMDAwMCBuIAowMDAwMDUyNzg0IDAwMDAwIG4gCjAwMDAwMDgxNDYgMDAw MDAgbiAKMDAwMDAwOTE1MSAwMDAwMCBuIAowMDAwMDM0MDY0IDAwMDAwIG4gCjAwMDAwMzQ1 NjAgMDAwMDAgbiAKMDAwMDA1Mjg2NyAwMDAwMCBuIAowMDAwMDA5Mjc4IDAwMDAwIG4gCjAw MDAwMTE1NTAgMDAwMDAgbiAKMDAwMDA0OTg2NiAwMDAwMCBuIAowMDAwMDM1MTM0IDAwMDAw IG4gCjAwMDAwMzU2MzEgMDAwMDAgbiAKMDAwMDA1Mjk1MCAwMDAwMCBuIAowMDAwMDExNjkw IDAwMDAwIG4gCjAwMDAwMTMxNTkgMDAwMDAgbiAKMDAwMDAzNjIwNiAwMDAwMCBuIAowMDAw MDM2NzAzIDAwMDAwIG4gCjAwMDAwMzcyNzggMDAwMDAgbiAKMDAwMDA1MzAzMyAwMDAwMCBu IAowMDAwMDEzMzExIDAwMDAwIG4gCjAwMDAwMTQ1NDIgMDAwMDAgbiAKMDAwMDAzNzg0NCAw MDAwMCBuIAowMDAwMDM4MzQxIDAwMDAwIG4gCjAwMDAwMzg5MTYgMDAwMDAgbiAKMDAwMDA1 MzExNiAwMDAwMCBuIAowMDAwMDE0NjczIDAwMDAwIG4gCjAwMDAwMTUzNDIgMDAwMDAgbiAK MDAwMDAzOTQ4MiAwMDAwMCBuIAowMDAwMDM5OTc5IDAwMDAwIG4gCjAwMDAwNTQyMzEgMDAw MDAgbiAKMDAwMDA1NDA5MyAwMDAwMCBuIAowMDAwMDUzMjAwIDAwMDAwIG4gCjAwMDAwMTU0 NjEgMDAwMDAgbiAKMDAwMDAxNzk5MiAwMDAwMCBuIAowMDAwMDQwNTU0IDAwMDAwIG4gCjAw MDAwNDEwNTEgMDAwMDAgbiAKMDAwMDA1MzI4NCAwMDAwMCBuIAowMDAwMDE4MTIxIDAwMDAw IG4gCjAwMDAwMTk5MzQgMDAwMDAgbiAKMDAwMDA0MTYyNiAwMDAwMCBuIAowMDAwMDQyMTIz IDAwMDAwIG4gCjAwMDAwNTMzNjggMDAwMDAgbiAKMDAwMDAyMDA1MyAwMDAwMCBuIAowMDAw MDIxNjYwIDAwMDAwIG4gCjAwMDAwNDI2OTggMDAwMDAgbiAKMDAwMDA0MzE5NSAwMDAwMCBu IAowMDAwMDUzNDUyIDAwMDAwIG4gCjAwMDAwMjE3ODkgMDAwMDAgbiAKMDAwMDAyMjY4NyAw MDAwMCBuIAowMDAwMDQzNzcwIDAwMDAwIG4gCjAwMDAwNDQyNjcgMDAwMDAgbiAKMDAwMDA1 MzUzNiAwMDAwMCBuIAowMDAwMDIyODA2IDAwMDAwIG4gCjAwMDAwMjMzNTYgMDAwMDAgbiAK MDAwMDA0NDg0MiAwMDAwMCBuIAowMDAwMDUzNjIwIDAwMDAwIG4gCjAwMDAwMjM0NjMgMDAw MDAgbiAKMDAwMDAyNTQyMCAwMDAwMCBuIAowMDAwMDQ1NDE3IDAwMDAwIG4gCjAwMDAwNDU5 MTQgMDAwMDAgbiAKMDAwMDA1MzcwNCAwMDAwMCBuIAowMDAwMDI1NTM5IDAwMDAwIG4gCjAw MDAwMjY4OTcgMDAwMDAgbiAKMDAwMDA0NjQ4OSAwMDAwMCBuIAowMDAwMDQ2OTg2IDAwMDAw IG4gCjAwMDAwNTM3ODggMDAwMDAgbiAKMDAwMDAyNzAxNiAwMDAwMCBuIAowMDAwMDI4MTk4 IDAwMDAwIG4gCjAwMDAwNDc1NjEgMDAwMDAgbiAKMDAwMDA0ODA1OCAwMDAwMCBuIAowMDAw MDUzODcyIDAwMDAwIG4gCjAwMDAwMjgzMTcgMDAwMDAgbiAKMDAwMDAyOTkyMyAwMDAwMCBu IAowMDAwMDQ4NjMzIDAwMDAwIG4gCjAwMDAwNDkxMzEgMDAwMDAgbiAKMDAwMDAzMDA0NSAw MDAwMCBuIAowMDAwMDMwMjQwIDAwMDAwIG4gCjAwMDAwMzA1MDEgMDAwMDAgbiAKMDAwMDAz MDU2NyAwMDAwMCBuIAowMDAwMDMwNjA2IDAwMDAwIG4gCjAwMDAwMzA3MzYgMDAwMDAgbiAK MDAwMDAzMDk5MiAwMDAwMCBuIAowMDAwMDMxMDU2IDAwMDAwIG4gCjAwMDAwMzEwOTUgMDAw MDAgbiAKMDAwMDAzMTMxMCAwMDAwMCBuIAowMDAwMDMxNTcxIDAwMDAwIG4gCjAwMDAwMzE2 MzcgMDAwMDAgbiAKMDAwMDAzMTY3NiAwMDAwMCBuIAowMDAwMDMxODA2IDAwMDAwIG4gCjAw MDAwMzIwNjIgMDAwMDAgbiAKMDAwMDAzMjEyNiAwMDAwMCBuIAowMDAwMDMyMTY1IDAwMDAw IG4gCjAwMDAwMzIzODAgMDAwMDAgbiAKMDAwMDAzMjYzNiAwMDAwMCBuIAowMDAwMDMyNzAw IDAwMDAwIG4gCjAwMDAwMzI3MzkgMDAwMDAgbiAKMDAwMDAzMjk1NCAwMDAwMCBuIAowMDAw MDMzMjE1IDAwMDAwIG4gCjAwMDAwMzMyODEgMDAwMDAgbiAKMDAwMDAzMzMyMCAwMDAwMCBu IAowMDAwMDMzNDUwIDAwMDAwIG4gCjAwMDAwMzM3MDYgMDAwMDAgbiAKMDAwMDAzMzc3MCAw MDAwMCBuIAowMDAwMDMzODA5IDAwMDAwIG4gCjAwMDAwMzQwMjQgMDAwMDAgbiAKMDAwMDAz NDI4NSAwMDAwMCBuIAowMDAwMDM0MzUxIDAwMDAwIG4gCjAwMDAwMzQzOTAgMDAwMDAgbiAK MDAwMDAzNDUyMCAwMDAwMCBuIAowMDAwMDM0Nzc2IDAwMDAwIG4gCjAwMDAwMzQ4NDAgMDAw MDAgbiAKMDAwMDAzNDg3OSAwMDAwMCBuIAowMDAwMDM1MDk0IDAwMDAwIG4gCjAwMDAwMzUz NTYgMDAwMDAgbiAKMDAwMDAzNTQyMiAwMDAwMCBuIAowMDAwMDM1NDYxIDAwMDAwIG4gCjAw MDAwMzU1OTEgMDAwMDAgbiAKMDAwMDAzNTg0OCAwMDAwMCBuIAowMDAwMDM1OTEyIDAwMDAw IG4gCjAwMDAwMzU5NTEgMDAwMDAgbiAKMDAwMDAzNjE2NiAwMDAwMCBuIAowMDAwMDM2NDI4 IDAwMDAwIG4gCjAwMDAwMzY0OTQgMDAwMDAgbiAKMDAwMDAzNjUzMyAwMDAwMCBuIAowMDAw MDM2NjYzIDAwMDAwIG4gCjAwMDAwMzY5MjAgMDAwMDAgbiAKMDAwMDAzNjk4NCAwMDAwMCBu IAowMDAwMDM3MDIzIDAwMDAwIG4gCjAwMDAwMzcyMzggMDAwMDAgbiAKMDAwMDAzNzQ5OCAw MDAwMCBuIAowMDAwMDM3NTYyIDAwMDAwIG4gCjAwMDAwMzc2MDEgMDAwMDAgbiAKMDAwMDAz NzgwNCAwMDAwMCBuIAowMDAwMDM4MDY2IDAwMDAwIG4gCjAwMDAwMzgxMzIgMDAwMDAgbiAK MDAwMDAzODE3MSAwMDAwMCBuIAowMDAwMDM4MzAxIDAwMDAwIG4gCjAwMDAwMzg1NTggMDAw MDAgbiAKMDAwMDAzODYyMiAwMDAwMCBuIAowMDAwMDM4NjYxIDAwMDAwIG4gCjAwMDAwMzg4 NzYgMDAwMDAgbiAKMDAwMDAzOTEzNiAwMDAwMCBuIAowMDAwMDM5MjAwIDAwMDAwIG4gCjAw MDAwMzkyMzkgMDAwMDAgbiAKMDAwMDAzOTQ0MiAwMDAwMCBuIAowMDAwMDM5NzA0IDAwMDAw IG4gCjAwMDAwMzk3NzAgMDAwMDAgbiAKMDAwMDAzOTgwOSAwMDAwMCBuIAowMDAwMDM5OTM5 IDAwMDAwIG4gCjAwMDAwNDAxOTYgMDAwMDAgbiAKMDAwMDA0MDI2MCAwMDAwMCBuIAowMDAw MDQwMjk5IDAwMDAwIG4gCjAwMDAwNDA1MTQgMDAwMDAgbiAKMDAwMDA0MDc3NiAwMDAwMCBu IAowMDAwMDQwODQyIDAwMDAwIG4gCjAwMDAwNDA4ODEgMDAwMDAgbiAKMDAwMDA0MTAxMSAw MDAwMCBuIAowMDAwMDQxMjY4IDAwMDAwIG4gCjAwMDAwNDEzMzIgMDAwMDAgbiAKMDAwMDA0 MTM3MSAwMDAwMCBuIAowMDAwMDQxNTg2IDAwMDAwIG4gCjAwMDAwNDE4NDggMDAwMDAgbiAK MDAwMDA0MTkxNCAwMDAwMCBuIAowMDAwMDQxOTUzIDAwMDAwIG4gCjAwMDAwNDIwODMgMDAw MDAgbiAKMDAwMDA0MjM0MCAwMDAwMCBuIAowMDAwMDQyNDA0IDAwMDAwIG4gCjAwMDAwNDI0 NDMgMDAwMDAgbiAKMDAwMDA0MjY1OCAwMDAwMCBuIAowMDAwMDQyOTIwIDAwMDAwIG4gCjAw MDAwNDI5ODYgMDAwMDAgbiAKMDAwMDA0MzAyNSAwMDAwMCBuIAowMDAwMDQzMTU1IDAwMDAw IG4gCjAwMDAwNDM0MTIgMDAwMDAgbiAKMDAwMDA0MzQ3NiAwMDAwMCBuIAowMDAwMDQzNTE1 IDAwMDAwIG4gCjAwMDAwNDM3MzAgMDAwMDAgbiAKMDAwMDA0Mzk5MiAwMDAwMCBuIAowMDAw MDQ0MDU4IDAwMDAwIG4gCjAwMDAwNDQwOTcgMDAwMDAgbiAKMDAwMDA0NDIyNyAwMDAwMCBu IAowMDAwMDQ0NDg0IDAwMDAwIG4gCjAwMDAwNDQ1NDggMDAwMDAgbiAKMDAwMDA0NDU4NyAw MDAwMCBuIAowMDAwMDQ0ODAyIDAwMDAwIG4gCjAwMDAwNDUwNTkgMDAwMDAgbiAKMDAwMDA0 NTEyMyAwMDAwMCBuIAowMDAwMDQ1MTYyIDAwMDAwIG4gCjAwMDAwNDUzNzcgMDAwMDAgbiAK MDAwMDA0NTYzOSAwMDAwMCBuIAowMDAwMDQ1NzA1IDAwMDAwIG4gCjAwMDAwNDU3NDQgMDAw MDAgbiAKMDAwMDA0NTg3NCAwMDAwMCBuIAowMDAwMDQ2MTMxIDAwMDAwIG4gCjAwMDAwNDYx OTUgMDAwMDAgbiAKMDAwMDA0NjIzNCAwMDAwMCBuIAowMDAwMDQ2NDQ5IDAwMDAwIG4gCjAw MDAwNDY3MTEgMDAwMDAgbiAKMDAwMDA0Njc3NyAwMDAwMCBuIAowMDAwMDQ2ODE2IDAwMDAw IG4gCjAwMDAwNDY5NDYgMDAwMDAgbiAKMDAwMDA0NzIwMyAwMDAwMCBuIAowMDAwMDQ3MjY3 IDAwMDAwIG4gCjAwMDAwNDczMDYgMDAwMDAgbiAKMDAwMDA0NzUyMSAwMDAwMCBuIAowMDAw MDQ3NzgzIDAwMDAwIG4gCjAwMDAwNDc4NDkgMDAwMDAgbiAKMDAwMDA0Nzg4OCAwMDAwMCBu IAowMDAwMDQ4MDE4IDAwMDAwIG4gCjAwMDAwNDgyNzUgMDAwMDAgbiAKMDAwMDA0ODMzOSAw MDAwMCBuIAowMDAwMDQ4Mzc4IDAwMDAwIG4gCjAwMDAwNDg1OTMgMDAwMDAgbiAKMDAwMDA0 ODg1NiAwMDAwMCBuIAowMDAwMDQ4OTIyIDAwMDAwIG4gCjAwMDAwNDg5NjEgMDAwMDAgbiAK MDAwMDA0OTA5MSAwMDAwMCBuIAowMDAwMDQ5MzQ5IDAwMDAwIG4gCjAwMDAwNDk0MTMgMDAw MDAgbiAKMDAwMDA0OTQ1MiAwMDAwMCBuIAowMDAwMDQ5OTYzIDAwMDAwIG4gCjAwMDAwNTEx MjcgMDAwMDAgbiAKMDAwMDA1NDMyMiAwMDAwMCBuIAowMDAwMDU0Mzc0IDAwMDAwIG4gCnRy YWlsZXIKPDwKL1NpemUgMjUzCi9Sb290IDI1MSAwIFIKL0luZm8gMjUyIDAgUgovSUQgWzw0 ZTZmNTgzNTA1NDc4MDk4YzhmZmJmNzY4NDBjZWZhZD48NGU2ZjU4MzUwNTQ3ODA5OGM4ZmZi Zjc2ODQwY2VmYWQ+XQo+PgpzdGFydHhyZWYKNTQ1OTcKJSVFT0YK --DBIVS5p969aUjpLe-- From mcr@sandelman.ottawa.on.ca Thu Nov 20 13:34:29 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hAKIYStf027135 for ; Thu, 20 Nov 2003 13:34:29 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166])hAKIYxM2026022 for ; Thu, 20 Nov 2003 13:35:03 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178])hAKIYKt15564 verified NO) for ; Thu, 20 Nov 2003 13:34:58 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247])hAKIbYm20218 for ; Thu, 20 Nov 2003 13:37:34 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) hAKIOZ44001203 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 20 Nov 2003 13:25:08 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) ESMTP id hAJMSlZx002794 for ; Wed, 19 Nov 2003 17:28:47 -0500 To: saag Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 19 Nov 2003 17:28:46 -0500 Message-ID: <2793.1069280926@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Subject: [saag] certicom IPR claims X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 20 Nov 2003 18:34:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Russ, you reposted the offer from Certicom on the MODP claims. Nothing was discussed about this at saag. The offer seemed nonsensical to me, as I previously commented - the only person that needs to run the algorithm (assuming we believe the claim) is the ID editor. The offer to license numbers is clearly not legal. Can anyone shed any light on this? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP7vunYqHRg3pndX9AQEhcgP/WRRuEJEEymbUAQwr/HqXZdQoUZJlzgt9 BGSYsiLXnFRX0m5H/7rvVMXh1jwwjTjae5X1q5jKjLepIVSa6+Ne3/hvagOz7sFb 4FvlL5hUURHjXEnNUw6ncocRKeD61ZQClqlog/QSQXNVThvo2Y4vSUxFfjQoB+uy R+4Wl/WX29g= =cXCB -----END PGP SIGNATURE----- From paul.hoffman@vpnc.org Thu Nov 20 14:02:58 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hAKJ2wtf027673 for ; Thu, 20 Nov 2003 14:02:58 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) hAKJ3XK6009899 for ; Thu, 20 Nov 2003 14:03:33 -0500 (EST) Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKJ3UkU047560 for ; Thu, 20 Nov 2003 11:03:30 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <2793.1069280926@marajade.sandelman.ottawa.on.ca> References: <2793.1069280926@marajade.sandelman.ottawa.on.ca> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 20 Nov 2003 11:04:43 -0800 To: saag From: Paul Hoffman / VPNC Subject: Re: [saag] certicom IPR claims Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 20 Nov 2003 19:02:59 -0000 At 5:28 PM -0500 11/19/03, Michael Richardson wrote: >Can anyone shed any light on this? Do you really believe that armchair lawyering on the SAAG list will shed any light at all? It is unlikely that almost anyone has read the relevant documents. It is even more unlikely that anyone trained in patent law has read them and is willing to give free legal advice to the SAAG list. --Paul Hoffman, Director --VPN Consortium From mcr@sandelman.ottawa.on.ca Fri Nov 21 17:33:59 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hALMXxtf022407 for ; Fri, 21 Nov 2003 17:33:59 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166])hALMYVBA006501 for ; Fri, 21 Nov 2003 17:34:35 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178])hALMYUt21836 for ; Fri, 21 Nov 2003 17:34:30 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247])hALMbji00830 for ; Fri, 21 Nov 2003 17:37:45 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) hALMXu3g011649 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 21 Nov 2003 17:33:56 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) ESMTP id hALMXtJ8011645 for ; Fri, 21 Nov 2003 17:33:56 -0500 To: saag Subject: Re: [saag] certicom IPR claims In-reply-to: Your message of "Thu, 20 Nov 2003 11:04:43 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 21 Nov 2003 17:33:55 -0500 Message-ID: <11644.1069454035@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 21 Nov 2003 22:34:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "VPNC" == VPNC writes: VPNC> At 5:28 PM -0500 11/19/03, Michael Richardson wrote: >> Can anyone shed any light on this? VPNC> Do you really believe that armchair lawyering on the SAAG list will VPNC> shed any light at all? If we go on the assumption that it doesn't matter what the technical people think, only what the US courts decide, then there is almost no value to even talk about IPR. VPNC> It is unlikely that almost anyone has read the relevant documents. Since it is in the lawyers interest to make sure that we don't even know what documents to read, I'm sure you are correct. I have, however, followed this issue as closely as I can. Industry Canada people who care, have suggested that Canada would never honour a claim to a prime number, and that the OncoMouse is prefectly adequate precedent. I naturally can't predict what US courts will do. My opinion is that no document should progress to PS with random unclarified IPR claims against it. Either that means the IPR claims go away, or they get explained. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP76S0YqHRg3pndX9AQGeFAP9ETt4iTGiF16ZUpPp7ogudE71fYOWzd5O BZEJz774Tp5QTftM0Ui0PhjhfBnyVOCDDC4DeW5paCDw5ZxiN2PT37lwx3A4iZjB cPd4hi/9h9gmQExTtHnJTVCb1zF6ak8dz2OSmbA0vYrQqpbHqBMP/N9wMskKe9Ov JdZH+TmVdbQ= =tQ36 -----END PGP SIGNATURE----- From smb@research.att.com Fri Nov 21 23:19:24 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hAM4JNtf027627 for ; Fri, 21 Nov 2003 23:19:23 -0500 (EST) Received: from mailman.research.att.com (H-135-207-24-32.research.att.com [135.207.24.32])hAM4K0SA005477 for ; Fri, 21 Nov 2003 23:20:00 -0500 (EST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101])hAM5A4uQ028691; Sat, 22 Nov 2003 00:10:04 -0500 Received: from berkshire.research.att.com (guard.research.att.com [135.207.1.20])hAM4JwZ19106; Fri, 21 Nov 2003 23:19:58 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 6D51A7B43; Fri, 21 Nov 2003 23:19:57 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Michael Richardson Subject: Re: [saag] certicom IPR claims In-Reply-To: Your message of "Fri, 21 Nov 2003 17:33:55 EST." <11644.1069454035@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Nov 2003 23:19:57 -0500 Message-Id: <20031122041957.6D51A7B43@berkshire.research.att.com> cc: saag X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 22 Nov 2003 04:19:24 -0000 In message <11644.1069454035@marajade.sandelman.ottawa.on.ca>, Michael Richards on writes: > > My opinion is that no document should progress to PS with random >unclarified IPR claims against it. Either that means the IPR claims >go away, or they get explained. Speaking as AD and as chair of the IPR wg... The IETF per se can take no position on the validity of any patents or on the desirability of standardizing a technology that may be encumbered. However, the members of each WG can and should make their own judgments -- aided, if they wish, by the advice of their own counsel -- on the validity of any IPR claims, and they're perfectly entitled to use those judgments, and any philosophical biases they have, in deciding whether or not to standardize such technology. Any choice has its costs. Sometimes, those costs are royalty fees or the difficulty in producing free implementations. Sometimes, the costs are poorer performance or lack of functionality from deciding to avoid encumbered technology. Unclear claims are bad, for all the obvious reasons. We're trying to get them clarified. But the wg may have to choose without more information. Let me suggest that people read or reread draft-ietf-ipr-wg-guidelines-05.txt and draft-ietf-ipr-technology-rights-12.txt, both of which were recently approved by the IESG. --Steve Bellovin, http://www.research.att.com/~smb From mcr@sandelman.ottawa.on.ca Sun Nov 23 13:17:45 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hANIHjtf026751 for ; Sun, 23 Nov 2003 13:17:45 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166])hANIIHJ4004394 for ; Sun, 23 Nov 2003 13:18:21 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178])hANIIGt01838 for ; Sun, 23 Nov 2003 13:18:16 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247])hANILXN25090 for ; Sun, 23 Nov 2003 13:21:33 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) hANI8ApN000945 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 23 Nov 2003 13:08:37 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) ESMTP id hAMHj8vt005812 for ; Sat, 22 Nov 2003 12:45:08 -0500 To: saag@mit.edu Subject: Re: [saag] certicom IPR claims In-reply-to: Your message of "Fri, 21 Nov 2003 23:19:57 EST." <20031122041957.6D51A7B43@berkshire.research.att.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sat, 22 Nov 2003 12:45:08 -0500 Message-ID: <5810.1069523108@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 23 Nov 2003 18:17:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Steven" == Steven M Bellovin writes: Steven> Unclear claims are bad, for all the obvious reasons. We're trying to More importantly, if the claims are unclear to me, then there is little point in consulting a lawyer. However, in this case, it appears to me that the *IETF* can not publish a document that contains a number based upon the claim. There is nothing in the claim that prevents me from using any such number that is published. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP7+goYqHRg3pndX9AQG8fQP/VRqlAeD+Q0uEKce5M1GguguU7lqmGqgA Qx3JatwgExlLn+2Z+e0gts/YB5+lmqW413E90HEZW+781/mRMmOHfrPiaoKZ0Ezr t/Bp2Uj51p/jwUppSKJ2sm75U9RbzbVN7+ouHZrwGkrxZmT8zhDPzbzWSkwBBodl usuvYgoHYt4= =JRU7 -----END PGP SIGNATURE----- From mouse@Sparkle.Rodents.Montreal.QC.CA Sun Nov 23 13:44:32 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hANIiWtf027327 for ; Sun, 23 Nov 2003 13:44:32 -0500 (EST) Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7])hANIj8OL016819 for ; Sun, 23 Nov 2003 13:45:08 -0500 (EST) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id NAA17785; Sun, 23 Nov 2003 13:45:05 -0500 (EST) From: der Mouse Message-Id: <200311231845.NAA17785@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Sun, 23 Nov 2003 13:42:21 -0500 (EST) To: saag@mit.edu Subject: Re: [saag] certicom IPR claims X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 23 Nov 2003 18:44:33 -0000 > It is unlikely that almost anyone has read the relevant documents. I haven't. But I'd like to. Can someone point me at them? As far as my mailbox goes, this began with mcr saying "Russ, you reposted the offer from Certicom on the MODP claims." - I never saw the reposting this refers to (whether I should expect to have or not). /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From sob@harvard.edu Sun Nov 23 13:55:20 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hANItKtf027689 for ; Sun, 23 Nov 2003 13:55:20 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) hANItvOL021463 for ; Sun, 23 Nov 2003 13:55:57 -0500 (EST) Received: by newdev.harvard.edu (Postfix, from userid 501) id 332068598E; Sun, 23 Nov 2003 13:55:57 -0500 (EST) To: mcr@sandelman.ottawa.on.ca, saag@mit.edu Subject: Re: [saag] certicom IPR claims In-Reply-To: <5810.1069523108@marajade.sandelman.ottawa.on.ca> Message-Id: <20031123185557.332068598E@newdev.harvard.edu> Date: Sun, 23 Nov 2003 13:55:57 -0500 (EST) From: sob@harvard.edu (Scott Bradner) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 23 Nov 2003 18:55:21 -0000 > However, in this case, it appears to me that the *IETF* can not publish a > document that contains a number based upon the claim. 1/ why not? patent violations come from implementing and distributing technology not from publishing it 2/ that would seem like a very bad president to set - just because someone makes a claim the IETF avoids the technology entirely - sounds like a a good way to invite DoS attacks on the IETF - someone sees that the IETF is thinking of going along a path that leads the IETF away from their own (secret) IPR so they send in a false claim - or someone wants to stop IETF work so that their own technology can get a chance to establish itself in the marketplace ... Scott From shep@ginger.lcs.mit.edu Sun Nov 23 14:51:52 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hANJpqtf029332 for ; Sun, 23 Nov 2003 14:51:52 -0500 (EST) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) hANJqTPs003948 for ; Sun, 23 Nov 2003 14:52:29 -0500 (EST) Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id hANJqRRu019199; Sun, 23 Nov 2003 14:52:27 -0500 Message-Id: <200311231952.hANJqRRu019199@ginger.lcs.mit.edu> From: Tim Shepard To: sob@harvard.edu (Scott Bradner) Subject: Re: [saag] certicom IPR claims In-reply-to: Your message of Sun, 23 Nov 2003 13:55:57 -0500. <20031123185557.332068598E@newdev.harvard.edu> Date: Sun, 23 Nov 2003 14:52:27 -0500 Sender: shep@ginger.lcs.mit.edu cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 23 Nov 2003 19:51:53 -0000 > 1/ why not? > patent violations come from implementing and distributing > technology not from publishing it But that is the mess we've gotten into since in the 20th century we learned that there is no clear line separating speech (language) from machinery (technology). (I thank Hal Abelson for explaining this so succinctly at a seminar at MIT on the legal issues surrounding DVD descrambling a few years ago.) Publishing software now seems indistinguishable from distributing technology. Many things published in IETF documents might be considered to be software. If Michael Richardson's assertions regarding the nature of the Certicom IPR claims are correct, then perhaps the IETF will need to consult its lawyers before publishing certain kinds of numbers. Has the IETF yet determined if it can publish source code in Internet Drafts and/or RFCs that implmenent patent-protected processes? Could the IETF publish an Internet Draft or RFC with the infamous DeCSS (see http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ ) source code? This issue seems to be closely related to these other issues. IANAL. -Tim Shepard shep@alum.mit.edu From sob@harvard.edu Sun Nov 23 15:09:11 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hANK9Btf029685 for ; Sun, 23 Nov 2003 15:09:11 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) hANK9mPs010400 for ; Sun, 23 Nov 2003 15:09:48 -0500 (EST) Received: by newdev.harvard.edu (Postfix, from userid 501) id 1572685A2E; Sun, 23 Nov 2003 15:09:47 -0500 (EST) To: shep@alum.mit.edu, sob@harvard.edu Subject: Re: [saag] certicom IPR claims In-Reply-To: <200311231938.hANJcjRu019099@ginger.lcs.mit.edu> Message-Id: <20031123200947.1572685A2E@newdev.harvard.edu> Date: Sun, 23 Nov 2003 15:09:47 -0500 (EST) From: sob@harvard.edu (Scott Bradner) cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 23 Nov 2003 20:09:12 -0000 > then perhaps the IETF will need to consult its lawyers. we have consulted our lawyers a number of times in patent issues > Could > source code (see http://www.cs.cmu.edu/~dst/DeCSS/Gallery/)? This > issue seems to be closely related to these other issues. the legal issue with DeCSS is the DMCA not patents Scott From phoffman@imc.org Sun Nov 23 17:54:11 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hANMsBtf002088 for ; Sun, 23 Nov 2003 17:54:11 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) hANMsl6G018040 for ; Sun, 23 Nov 2003 17:54:48 -0500 (EST) Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id hANMsikU037994; Sun, 23 Nov 2003 14:54:44 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <5810.1069523108@marajade.sandelman.ottawa.on.ca> References: <5810.1069523108@marajade.sandelman.ottawa.on.ca> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Sun, 23 Nov 2003 14:56:21 -0800 To: Michael Richardson , saag@mit.edu From: Paul Hoffman / IMC Subject: Re: [saag] certicom IPR claims Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 23 Nov 2003 22:54:12 -0000 At 12:45 PM -0500 11/22/03, Michael Richardson wrote: > However, in this case, it appears to me that the *IETF* can not publish a >document that contains a number based upon the claim. There is nothing in the >claim that prevents me from using any such number that is published. This argument is more confusing than the patent claim in question. First you said that the patent claim is bogus due to copious prior art (an assertion that many people agree with), then you say that the IETF cannot publish the document because it has this patent claim on it. This is begging for the kind of DoS attack on the IETF standards process that Scott talks about. Telling people "if you make a patent claim against a pending proposal, we won't publish the proposal" is not in the best interest of the Internet. BTW, anyone can make a statement of patent applicability; it doesn't have to come from the patent's owner. That is, I can say "As I was researching the pending FooOverIP protocol, I discovered Chinese Patent #1234567 which clearly (in my mind) covers FooOverIP." This lowers the threshold on your proposed DoS attack even further. --Paul Hoffman, Director --Internet Mail Consortium From mcr@sandelman.ottawa.on.ca Mon Nov 24 11:37:49 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hAOGbntf017473 for ; Mon, 24 Nov 2003 11:37:49 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166])hAOGcO2r019109 for ; Mon, 24 Nov 2003 11:38:25 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) hAOGcGt06799; Mon, 24 Nov 2003 11:38:16 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247])hAOGfY714924; Mon, 24 Nov 2003 11:41:34 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) hAOGbMpH032382 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 24 Nov 2003 11:37:22 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) ESMTP id hAOGbKBU032378; Mon, 24 Nov 2003 11:37:21 -0500 To: sob@harvard.edu (Scott Bradner) Subject: Re: [saag] certicom IPR claims In-reply-to: Your message of "Sun, 23 Nov 2003 13:55:57 EST." <20031123185557.332068598E@newdev.harvard.edu> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 24 Nov 2003 11:37:20 -0500 Message-ID: <32377.1069691840@marajade.sandelman.ottawa.on.ca> From: Michael Richardson cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 24 Nov 2003 16:37:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott Bradner writes: Scott> 1/ why not? Scott> patent violations come from implementing and distributing Scott> technology not from publishing it There is nothing to implement - the process which is mentioned does not occur in IKEv1 or IKEv2. The process applies to someone who wishes to generate a large number of a Diffie-Hellman modulus. That would be the IETF and/or the people who wrote the documents. There are other ways of generating large primes. Let me say that again - my reading is that there is no reasonable claim against IKEv1 or IKEv2 implementors. Yet, it is mentioned as IPR against those protocols. The Certicom "offer" of MODP groups 1 and 2 is ridiculous - you can't patent numbers (trademark, copyright, maybe). The only reasonable offer they can make is to the RFC editor and/or the document editor of the algorithm. Scott> 2/ that would seem like a very bad president to set - Scott> just because someone makes a claim the IETF avoids the technology Scott> entirely - sounds like a a good way to invite DoS attacks on Scott> the IETF - someone sees that the IETF is thinking of going Scott> along a path that leads the IETF away from their own Scott> (secret) IPR so they send in a false claim - or someone wants Scott> to stop IETF work so that their own technology can get a Scott> chance to establish itself in the marketplace ... This is precisely what is occuring. Their claim suggests exactly that. But, it doesn't apply to implementors this time, it applies to the RFC editor - who will be distributing the results of the process. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP8IzuYqHRg3pndX9AQFAgwP+M/mOq1SHod5s7nSvZzCezdsFGTbvlEqr 6GRUfSiLcx0OQV7u6cjin6pACNGc4Op0SWAPIzJVhCr0vSQqn3TQWc2bs+KPHlOo se7V0iSc+pUDyeoHz8iz+qcu63oLrXyczs4xRjNdWUf1yF7Zj0A8Cevh9E7hniDh 7S9g95HcdGo= =Wz3s -----END PGP SIGNATURE----- From mcr@sandelman.ottawa.on.ca Mon Nov 24 11:57:44 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hAOGvitf018220 for ; Mon, 24 Nov 2003 11:57:44 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166])hAOGwJM5009948 for ; Mon, 24 Nov 2003 11:58:20 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) hAOGwGt06918; Mon, 24 Nov 2003 11:58:16 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247])hAOH1X716062; Mon, 24 Nov 2003 12:01:33 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) hAOGnRpH032665 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 24 Nov 2003 11:49:28 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) ESMTP id hAOGnRiV032661; Mon, 24 Nov 2003 11:49:27 -0500 To: Paul Hoffman / IMC Subject: Re: [saag] certicom IPR claims In-reply-to: Your message of "Sun, 23 Nov 2003 14:56:21 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 24 Nov 2003 11:49:26 -0500 Message-ID: <32660.1069692566@marajade.sandelman.ottawa.on.ca> From: Michael Richardson cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 24 Nov 2003 16:57:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "IMC" == IMC writes: IMC> This argument is more confusing than the patent claim in question. IMC> First you said that the patent claim is bogus due to copious prior IMC> art (an assertion that many people agree with), then you say that the IMC> IETF cannot publish the document because it has this patent claim on IMC> it. I didn't claim there was prior art. I would be overjoyed to learn that there is. I believe that some people have suggested that there is prior art. I don't have that list. IMC> This is begging for the kind of DoS attack on the IETF standards IMC> process that Scott talks about. Telling people "if you make a patent IMC> claim against a pending proposal, we won't publish the proposal" is IMC> not in the best interest of the Internet. I agree. This is why I would like the claims massively clarified, or rejected. If the claim is reasonable and well documented, then we should acknowledge it. It the claim is spurious and unclear, then I do not believe that we should list the IPR claim. Why? because publishing IPR claim provides protection to the claiming company against people later claiming they acted in bad faith. The "Gateway" vs PCI SIG situation. Submarine patents have been struck down by courts. IMC> BTW, anyone can make a statement of patent applicability; it doesn't IMC> have to come from the patent's owner. That is, I can say "As I was IMC> researching the pending FooOverIP protocol, I discovered Chinese IMC> Patent #1234567 which clearly (in my mind) covers FooOverIP." This IMC> lowers the threshold on your proposed DoS attack even further. No, it doesn't. Because 1) you are being very precise in what you think, Certicom isn't. 2) you are not the owner, so we can't assume the owner agrees. 3) it might well be true, and we should contact the patent owner and find out why they haven't made a claim, and maybe they will license appropriately, and all will be well. Now, the NAT-T IPR claims are better examples of IPR that needs massive amounts of clarification. In the MODP/certicom case, I can say "that's nonsense" and continue. I very much hope the IESG, Security ADs, and/or IPsec WG says "that's nonsense", or finds (and documents) prior art, or checks the other MODP groups in a way that, worst case, gets around it all. In the NAT-T IPR claims, there is nothing - no patent numbers, nor any specifics. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP8I2gIqHRg3pndX9AQGXZwQA2clIBmh106OtJl+XAZGrDA3yauM+uaq9 fkVueNK8MGKko7/gq42bhefDidc/2KjVDYkAZkWm7b+CJ60XBKe5UQkfhe7kVpjs rTQH5quw1yiYMD0sF5nPzx9rRrJy6/U5rO8+IYwhLTQ7ItRsAuof20jQWfrnnvRi vOvxaDEGjx0= =sADI -----END PGP SIGNATURE----- From mcr@sandelman.ottawa.on.ca Mon Nov 24 12:58:00 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hAOHvxtf019867 for ; Mon, 24 Nov 2003 12:57:59 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166])hAOHwa2r026983 for ; Mon, 24 Nov 2003 12:58:36 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) hAOHwIt07150; Mon, 24 Nov 2003 12:58:18 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247])hAOI1ZJ20252; Mon, 24 Nov 2003 13:01:35 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) hAOHpvpH001759 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 24 Nov 2003 12:51:58 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) ESMTP id hAOHpulo001755; Mon, 24 Nov 2003 12:51:57 -0500 To: der Mouse Subject: Re: [saag] certicom IPR claims In-reply-to: Your message of "Sun, 23 Nov 2003 13:42:21 EST." <200311231845.NAA17785@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 24 Nov 2003 12:51:56 -0500 Message-ID: <1754.1069696316@marajade.sandelman.ottawa.on.ca> From: Michael Richardson cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 24 Nov 2003 17:58:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "der" == der Mouse writes: >> It is unlikely that almost anyone has read the relevant documents. der> I haven't. But I'd like to. Can someone point me at them? As far as der> my mailbox goes, this began with mcr saying "Russ, you reposted the der> offer from Certicom on the MODP claims." - I never saw the reposting der> this refers to (whether I should expect to have or not). The claim is not yet on the IETF IPR site. For some reason, it isn't in my archives. I'm not sure why. It arrived on the last day of the month... I wonder if perhaps I roll the month before indexing the last day of the month... Yes. Here is it on VPNC: http://www.vpnc.org/ietf-ipsec/mail-archive/msg05272.html ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP8JFOYqHRg3pndX9AQFfOAQAqdOP8eStCItYCVlSCRw3bfKnd1lC28gl LJihMLVcgZr+RMIv1Am0vb29C0jme/U9HPL/aTud5sRxBc3PrbLuaiUCTbFGSHQ3 D10dormPp+gnO6O4lenB8YdBPxzVVC3MzcFmHkhqJYzARxCkQqnGuxC2yY7PHjXJ o9AEWjHZ4zE= =LK/K -----END PGP SIGNATURE----- From shep@ginger.lcs.mit.edu Mon Nov 24 13:20:10 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hAOIKAtf020304 for ; Mon, 24 Nov 2003 13:20:10 -0500 (EST) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) hAOIKk2r014128 for ; Mon, 24 Nov 2003 13:20:46 -0500 (EST) Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id hAOIKdRu026739; Mon, 24 Nov 2003 13:20:39 -0500 Message-Id: <200311241820.hAOIKdRu026739@ginger.lcs.mit.edu> From: Tim Shepard To: sob@harvard.edu (Scott Bradner) Subject: Re: [saag] certicom IPR claims In-reply-to: Your message of Sun, 23 Nov 2003 15:09:47 -0500. <20031123200947.1572685A2E@newdev.harvard.edu> Date: Mon, 24 Nov 2003 13:20:39 -0500 Sender: shep@ginger.lcs.mit.edu cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 24 Nov 2003 18:20:11 -0000 > the legal issue with DeCSS is the DMCA not patents All I was trying to point out with the DeCSS example that I brought up is that it is case where the lines between publishing (free speech) and distributing technology have been blurred. There are business process patents. If you had a business process patent that included as part of the business process a process step which was to publish some information (say a crypto key or a number, something that might reasonably be argued is not "speech" subject to first amendment protection in the US) then it seems that the act of publishing could infringe on the patent. That sounds like the sort of thing that Michael is trying to explain. Again, IANAL. If we already know that we cannot infringe upon a patent merely by publishing something (like a number) in an ID or RFC, then that is great news. -Tim Shepard shep@alum.mit.edu From jis@MIT.EDU Mon Nov 24 13:32:30 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hAOIWUtf020597; Mon, 24 Nov 2003 13:32:30 -0500 (EST) Received: from jis.tzo.com (JISVPN.MIT.EDU [18.100.101.102]) hAOIX42r023992; Mon, 24 Nov 2003 13:33:04 -0500 (EST) Received: from mit.edu (jis.tzo.com [127.0.0.1]) by jis.tzo.com (8.12.8p2/8.12.8) with ESMTP id hAOIWx4O003044; Mon, 24 Nov 2003 13:32:59 -0500 Message-ID: <3FC24ED4.3020006@mit.edu> Date: Mon, 24 Nov 2003 13:32:52 -0500 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Richardson Subject: Re: [saag] certicom IPR claims References: <32377.1069691840@marajade.sandelman.ottawa.on.ca> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8D0894AB8BD2DD58C42020BE" cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 24 Nov 2003 18:32:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8D0894AB8BD2DD58C42020BE Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Richardson wrote: > > The Certicom "offer" of MODP groups 1 and 2 is ridiculous - you can't > patent numbers (trademark, copyright, maybe). The only reasonable offer they > can make is to the RFC editor and/or the document editor of the algorithm. Is it even known that the RFC Editor ran the process? I doubt it. Perhaps someone, somwhere did at some time.... but who knows. A tempest in a teapot if you ask me. -Jeff --------------enig8D0894AB8BD2DD58C42020BE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/wk7b8CBzV/QUlSsRAsXtAJ9Zg0e/dv7xQgIlpvs/z63TZsPsAQCgmhkW MsDOZFCEKqwMDkmkBThjeI8= =trmZ -----END PGP SIGNATURE----- --------------enig8D0894AB8BD2DD58C42020BE-- From sob@harvard.edu Mon Nov 24 14:04:02 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hAOJ3utf021253 for ; Mon, 24 Nov 2003 14:03:56 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) hAOJ4X73018007 for ; Mon, 24 Nov 2003 14:04:33 -0500 (EST) Received: by newdev.harvard.edu (Postfix, from userid 501) id BC2B186CDE; Mon, 24 Nov 2003 14:04:32 -0500 (EST) To: mcr@sandelman.ottawa.on.ca, phoffman@imc.org Subject: Re: [saag] certicom IPR claims In-Reply-To: <32660.1069692566@marajade.sandelman.ottawa.on.ca> Message-Id: <20031124190432.BC2B186CDE@newdev.harvard.edu> Date: Mon, 24 Nov 2003 14:04:32 -0500 (EST) From: sob@harvard.edu (Scott Bradner) cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 24 Nov 2003 19:04:02 -0000 > It the claim is spurious and unclear, then I do not believe that we > should list the IPR claim. Why? we (the IETF) does not "list claims" we publish, without evaluation, messages about IPR that are received by the Secretariat to do anything else raises a liability for the IETF Scott From smb@research.att.com Wed Dec 3 14:43:41 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB3JheD7022539 for ; Wed, 3 Dec 2003 14:43:40 -0500 (EST) Received: from linux.research.att.com (H-135-207-24-16.research.att.com [135.207.24.16])hB3JiLsc020289 for ; Wed, 3 Dec 2003 14:44:21 -0500 (EST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101])hB3JjQwr002787 for ; Wed, 3 Dec 2003 14:45:26 -0500 Received: from berkshire.research.att.com (raptor.research.att.com [135.207.23.32])hB3JiKZ06477 for ; Wed, 3 Dec 2003 14:44:20 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 6067B7B43 for ; Wed, 3 Dec 2003 14:44:20 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: Steve Bellovin To: saag@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Dec 2003 14:44:20 -0500 Message-Id: <20031203194420.6067B7B43@berkshire.research.att.com> Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.529858 Subject: [saag] 3DES vs. AES X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 03 Dec 2003 19:43:42 -0000 For new deployments, which cipher should be mandatory-to-implement, 3DES or AES? For protocols with an installed base, we've mandated 3DES, with AES as a "SHOULD". The IPsec WG has said something stronger: AES is a "SHOULD+", meaning that it will probably become a "MUST" in the next version. But what do we tell protocol designers who are designing new protocols? My personal preference is AES. For the low end, it's so much more efficient in software; for the high end, its 128-bit block size permits much more data to be encrypted with a single key. On the other hand, as John Gilmore has noted, 3DES has been studied for about 25 years. That's a lot of scrutiny; AES hasn't had nearly that much attention. --Steve Bellovin, http://www.research.att.com/~smb From ho@alum.mit.edu Wed Dec 3 16:29:34 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB3LTXD7024726 for ; Wed, 3 Dec 2003 16:29:33 -0500 (EST) Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) hB3LUDuP019617 for ; Wed, 3 Dec 2003 16:30:14 -0500 (EST) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id hB3LU8pu029067; Wed, 3 Dec 2003 14:30:08 -0700 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id hB3LTUQ5032328; Wed, 3 Dec 2003 14:29:30 -0700 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hB3LTTMg032324; Wed, 3 Dec 2003 14:29:29 -0700 Date: Wed, 3 Dec 2003 14:29:29 -0700 Message-Id: <200312032129.hB3LTTMg032324@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: smb@research.att.com In-reply-to: Yourmessage <20031203194420.6067B7B43@berkshire.research.att.com> Subject: Re: [saag] 3DES vs. AES Spam-Alum-Prob: 0.003437 Spam-Alum-Time: 0.515326 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 03 Dec 2003 21:29:34 -0000 Has 3DES been studied for 25 years? Maybe DES has. During the first 15 years of DES's life, the public study of it was done without the benefit of differential or linear cryptanalysis. The number of hours per trained mind that is the proper measure. One could argue easily that AES has had the benefit of as much "quality" examination as 3DES, perhaps more. Why don't the ultra (no pun) conservatives standardize 64-rotor Enigma? Hilarie From phoffman@imc.org Wed Dec 3 21:55:58 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB42tvD7000236 for ; Wed, 3 Dec 2003 21:55:57 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) hB42ucuk022349 for ; Wed, 3 Dec 2003 21:56:38 -0500 (EST) Received: from [10.0.62.104] (adsl-63-202-92-151.dsl.snfc21.pacbell.net [63.202.92.151]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB42uYic096718; Wed, 3 Dec 2003 18:56:35 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20031203194420.6067B7B43@berkshire.research.att.com> References: <20031203194420.6067B7B43@berkshire.research.att.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 3 Dec 2003 18:20:08 -0800 To: Steve Bellovin , saag@mit.edu From: Paul Hoffman / IMC Subject: Re: [saag] 3DES vs. AES Content-Type: text/plain; charset="us-ascii" ; format="flowed" Spam-Alum-Prob: 0.000001 Spam-Alum-Time: 0.527411 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Dec 2003 02:55:58 -0000 At 2:44 PM -0500 12/3/03, Steve Bellovin wrote: >For protocols with an installed base, we've mandated 3DES, with AES as >a "SHOULD". The IPsec WG has said something stronger: AES is a >"SHOULD+", meaning that it will probably become a "MUST" in the next >version. > >But what do we tell protocol designers who are designing new protocols? AES. If new protocols specify only TripleDES, that doesn't give them a clear forward path. If they make TripleDES a MUST and AES as SHOULD+, like we did in IKEv2, that forces new implementations to do both. They should just start with AES. --Paul Hoffman, Director --Internet Mail Consortium From jesse.walker@intel.com Thu Dec 4 09:50:37 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB4EoaD7011009 for ; Thu, 4 Dec 2003 09:50:36 -0500 (EST) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) hB4EpIxt026187 for ; Thu, 4 Dec 2003 09:51:18 -0500 (EST) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) major-outer.mc,v 1.11 2003/12/03 18:29:28 root Exp $) with ESMTP id hB4Epfq4028166 for ; Thu, 4 Dec 2003 14:51:41 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hB4Ej7c29519 for ; Thu, 4 Dec 2003 14:45:07 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) M2003120406510722594 ; Thu, 04 Dec 2003 06:51:07 -0800 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 4 Dec 2003 06:51:07 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [saag] 3DES vs. AES Date: Thu, 4 Dec 2003 06:51:07 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] 3DES vs. AES Thread-Index: AcO6Git1hOHjVVw3TpuEltoW5YRm7QAWf6yA From: "Walker, Jesse" To: "Steve Bellovin" , X-OriginalArrivalTime: 04 Dec 2003 14:51:07.0996 (UTC) FILETIME=[0CC9B9C0:01C3BA76] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.577601 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id hB4EoaD7011009 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Dec 2003 14:50:38 -0000 Steve, The AES block size is 128 bits. This means that if AES is secure and any reasonable mode of operation is used, then a single key can be applied to O(2^64) blocks of data. The 3DES block size is only 64 bits, so the security of 3DES under reasonable modes expires by O(2^32) blocks. If the application might be used with high speed links, then the tradeoff is clear: it should either consider AES, or else give very careful attention to rekeying if it goes with 3DES. A 10 GHz link encrypted link needs to transfer roughly O(2^27) 3DES blocks/sec, so a 3DES protected 10 GHz link should be rekeyed at least every 2^5 seconds. -- Jesse -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Steve Bellovin Sent: Wednesday, December 03, 2003 11:44 AM To: saag@mit.edu Subject: [saag] 3DES vs. AES For new deployments, which cipher should be mandatory-to-implement, 3DES or AES? For protocols with an installed base, we've mandated 3DES, with AES as a "SHOULD". The IPsec WG has said something stronger: AES is a "SHOULD+", meaning that it will probably become a "MUST" in the next version. But what do we tell protocol designers who are designing new protocols? My personal preference is AES. For the low end, it's so much more efficient in software; for the high end, its 128-bit block size permits much more data to be encrypted with a single key. On the other hand, as John Gilmore has noted, 3DES has been studied for about 25 years. That's a lot of scrutiny; AES hasn't had nearly that much attention. --Steve Bellovin, http://www.research.att.com/~smb _______________________________________________ saag mailing list saag@mit.edu https://jis.mit.edu/mailman/listinfo/saag From crawdad@fnal.gov Thu Dec 4 11:15:51 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB4GFpD7012540 for ; Thu, 4 Dec 2003 11:15:51 -0500 (EST) Received: from heffalump.fnal.gov (heffalump.fnal.gov [131.225.9.20]) hB4GGVXs029701 for ; Thu, 4 Dec 2003 11:16:31 -0500 (EST) Received: from conversion-daemon.heffalump.fnal.gov by heffalump.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) id <0HPD00B01OXUTU@heffalump.fnal.gov> for saag@mit.edu; Thu, 04 Dec 2003 10:16:31 -0600 (CST) Received: from [131.225.82.58] (skuld.dhcp.fnal.gov [131.225.82.58]) by heffalump.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTPSA id <0HPD00019P6SH2@heffalump.fnal.gov>; Thu, 04 Dec 2003 10:16:05 -0600 (CST) Date: Thu, 04 Dec 2003 10:16:03 -0600 From: Matt Crawford Subject: Re: [saag] 3DES vs. AES In-reply-to: To: Steve Bellovin Message-id: <28379546-2675-11D8-8B00-000A95A0BF96@fnal.gov> MIME-version: 1.0 X-Mailer: Apple Mail (2.606) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <20031203194420.6067B7B43@berkshire.research.att.com> Spam-Alum-Prob: 0.000945 Spam-Alum-Time: 0.527962 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Dec 2003 16:15:52 -0000 > AES. If new protocols specify only TripleDES, that doesn't give them a > clear forward path. If they make TripleDES a MUST and AES as SHOULD+, > like we did in IKEv2, that forces new implementations to do both. They > should just start with AES. If you make both of them MUSTs, that forces them to build in support for multiple algorithms, which they might not do with only one mandatory algorithm. From smb@research.att.com Thu Dec 4 12:41:05 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB4Hf4D7014157 for ; Thu, 4 Dec 2003 12:41:04 -0500 (EST) Received: from linux.research.att.com (H-135-207-24-16.research.att.com [135.207.24.16])hB4HfiXs018290 for ; Thu, 4 Dec 2003 12:41:44 -0500 (EST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101])hB4Hh4wr013519; Thu, 4 Dec 2003 12:43:04 -0500 Received: from berkshire.research.att.com (raptor.research.att.com [135.207.23.32])hB4HfhZ20810; Thu, 4 Dec 2003 12:41:43 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id E52157B43; Thu, 4 Dec 2003 12:41:42 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Philip J. Nesser II" Subject: Re: [saag] 3DES vs. AES In-Reply-To: Your message of "Thu, 04 Dec 2003 09:54:20 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Dec 2003 12:41:42 -0500 Message-Id: <20031204174143.E52157B43@berkshire.research.att.com> Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.558606 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Dec 2003 17:41:05 -0000 In message , "Philip J. Nesser II" writes: >It seems that the obvious choice would be BOTH AES and 3DES MUST be MUST. >At some point in the future we may recommend moving to MUST for AES and >SHOULD for 3DES. (or maybe not, some serious flaw in AES might be >discovered) > >If the protocol has a mechanism for multiple ciphers (and I can't think >of any that doesn't), than there is little extra overhead in requiring two >MUSTs. There are two objections. The first is code bloat; that can matter a lot for low-end devices. The second is more subtle: if a flaw is found in one, you aren't more secure if you have both unless lots of people disable the the faulty cipher. This objection was raised quite prominently during the debate over AES -- should there be one AES or two? > >The question in my mind is what is the primary cipher? Since there are >people here with serious cryptographic skills and knowledge, wouldn't it >be prudent to write a very short BCP saying something along the lines of: > >--- Currently the recommendation is to require both AES and 3DES >--- In the following cases (insert cases here...)AES is the recommended >primary cipher for these reasons...(insert reasons here...) >--- In the following cases (insert cases here...)3DES is the recommended >primary cipher for these reasons...(insert reasons here...) > Russ and I have already asked someone to write such a document. --Steve Bellovin, http://www.research.att.com/~smb From housley@vigilsec.com Thu Dec 4 13:16:12 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB4IGBD7014763 for ; Thu, 4 Dec 2003 13:16:11 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) hB4IGrxt017460 for ; Thu, 4 Dec 2003 13:16:53 -0500 (EST) Received: (qmail 28191 invoked by uid 0); 4 Dec 2003 18:16:29 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.40.157) by woodstock.binhost.com with SMTP; 4 Dec 2003 18:16:29 -0000 Message-Id: <5.2.0.9.2.20031204131556.0430c148@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 04 Dec 2003 13:16:36 -0500 To: Michael Richardson , saag From: Russ Housley Subject: Re: [saag] certicom IPR claims In-Reply-To: <2793.1069280926@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Spam-Alum-Prob: 0.000001 Spam-Alum-Time: 0.525296 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Dec 2003 18:16:13 -0000 I have asked Certicom to post an IPR notice, but so far, they have not done so. Russ At 05:28 PM 11/19/2003 -0500, Michael Richardson wrote: >Russ, you reposted the offer from Certicom on the MODP claims. > >Nothing was discussed about this at saag. >The offer seemed nonsensical to me, as I previously commented - the only >person that needs to run the algorithm (assuming we believe the claim) >is the ID editor. The offer to license numbers is clearly not legal. > >Can anyone shed any light on this? From rja@extremenetworks.com Thu Dec 4 13:21:00 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB4IKxD7014887 for ; Thu, 4 Dec 2003 13:20:59 -0500 (EST) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) hB4ILeXs022308 for ; Thu, 4 Dec 2003 13:21:40 -0500 (EST) Received: from extremenetworks.com (unknown [10.255.51.11]) by gnat.inet.org (Postfix) with ESMTP id 0338967106; Thu, 4 Dec 2003 13:28:20 -0500 (EST) Date: Thu, 4 Dec 2003 13:21:37 -0500 Subject: Re: [saag] 3DES vs. AES Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) To: Matt Crawford From: RJ Atkinson In-Reply-To: <28379546-2675-11D8-8B00-000A95A0BF96@fnal.gov> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Spam-Alum-Prob: 0.000002 Spam-Alum-Time: 0.529462 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Dec 2003 18:21:00 -0000 On Thursday, Dec 4, 2003, at 11:16 America/Montreal, Matt Crawford wrote: Earlier, someone else wrote: >> AES. If new protocols specify only TripleDES, that doesn't give them >> a clear forward path. If they make TripleDES a MUST and AES as >> SHOULD+, like we did in IKEv2, that forces new implementations to do >> both. They should just start with AES. > > If you make both of them MUSTs, that forces them to build in support > for multiple algorithms, which they might not do with only one > mandatory algorithm. Matt has a very good point. It is unlikely that the current use(s) of AES would be the last word -- so multiple algorithm support is very worthwhile in any event. Ran From ekr@rtfm.com Thu Dec 4 14:19:48 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB4JJlD7016135 for ; Thu, 4 Dec 2003 14:19:47 -0500 (EST) Received: from sierra.rtfm.com (sierra.rtfm.com [198.144.203.251]) hB4JKSXs013408 for ; Thu, 4 Dec 2003 14:20:28 -0500 (EST) Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id DEADB7187; Thu, 4 Dec 2003 11:20:25 -0800 (PST) Received: by romeo.rtfm.com (Postfix, from userid 556) id C677FAC4A; Thu, 4 Dec 2003 11:20:23 -0800 (PST) Sender: ekr@romeo.rtfm.com To: Paul Hoffman / IMC Subject: Re: [saag] 3DES vs. AES References: <20031203194420.6067B7B43@berkshire.research.att.com> From: Eric Rescorla Date: 04 Dec 2003 11:20:23 -0800 In-Reply-To: Message-ID: Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.540002 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: EKR List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Dec 2003 19:19:49 -0000 Paul Hoffman / IMC writes: > At 2:44 PM -0500 12/3/03, Steve Bellovin wrote: > >For protocols with an installed base, we've mandated 3DES, with AES as > >a "SHOULD". The IPsec WG has said something stronger: AES is a > >"SHOULD+", meaning that it will probably become a "MUST" in the next > >version. > > > >But what do we tell protocol designers who are designing new protocols? > > AES. If new protocols specify only TripleDES, that doesn't give them a > clear forward path. If they make TripleDES a MUST and AES as SHOULD+, > like we did in IKEv2, that forces new implementations to do both. They > should just start with AES. I have no problem with this. However, many of the protocols being designed are not "new protocols". Rather, they have dependencies on things like TLS or S/MIME. The MUSTs for those protocols should be the same as the underlying COMSEC protocol unless there's some really obvious reason to the contrary. -Ekr From gmj@pobox.com Thu Dec 4 14:23:25 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB4JNOD7016286 for ; Thu, 4 Dec 2003 14:23:24 -0500 (EST) Received: from mall.pulltheplug.com (mall.pulltheplug.com [199.173.12.2]) hB4JO5Xs016254 for ; Thu, 4 Dec 2003 14:24:05 -0500 (EST) Received: by mall.pulltheplug.com (Postfix, from userid 1003) id 640471045F; Thu, 4 Dec 2003 14:17:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mall.pulltheplug.com (Postfix) with ESMTP id 3366E526A4 for ; Thu, 4 Dec 2003 14:17:39 -0500 (EST) Date: Thu, 4 Dec 2003 14:17:39 -0500 (EST) From: George Jones X-X-Sender: gmj@mall.pulltheplug.com To: saag@mit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.585123 Subject: [saag] What is "strong" crypto ? X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: gmj@pobox.com List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Dec 2003 19:23:26 -0000 I'm working on updates to draft-jones-opsec-02.txt. One of the requirements is the use of "strong" crypto to protect management traffic. Of course, "strong" is a very relative, time sensitive term. One of the reviewers said: > Unfortunately, it's a function of customer needs which are going to vary > pretty widely. I think the best we can do is try to get vendors to provide > enough information about what they're doing so that customers can make a > reasonably informed decision. It might help to point out what is BCP in > current IETF protocols in these spaces. Which seems to be in line with RFC 3365: 3365> Finally, as to understanding cryptography, you don't have to. In 3365> other words, you do not need to become a cryptographer in order to 3365> effectively make use of cryptographic technology. Instead you make 3365> use of existing well understood ciphers and cipher suites to solve 3365> the engineering problem you face. 3365> 3365> One of the goals that we have in the Security Area of the IETF is to 3365> come up with guides so that protocol implementers can choose 3365> appropriate technology without having to understand the minutiae. Earlier, it says 3365> 7. MUST is for Implementors 3365> 3365> We often say that Security is a MUST implement. It is worth noting 3365> that there is a significant different between MUST implement and MUST 3365> use. 3365> ... 3365> However security must be a MUST IMPLEMENT so that end users will have 3365> the option of enabling it when the situation calls for it. Which is precisely what the opsec drafts are trying to nail down for the domain of large/backbone network gear. "strong" encryption provides a good mechanism for achieving secure remote management. The question is, for the non-crypto-expert (the poor schmuck who's just trying to purchase/deploy/operate a network), is there a good way to determine "strong" ? Have I missed relevant RFCs/BCPs ? Would an "Evaluating and Choosing Strong Crypto" BCP be in order ? Thanks, ---George Jones From phoffman@imc.org Thu Dec 4 16:00:04 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB4L03D7018143 for ; Thu, 4 Dec 2003 16:00:03 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) hB4L0hXs006670 for ; Thu, 4 Dec 2003 16:00:43 -0500 (EST) Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4L0eic024345; Thu, 4 Dec 2003 13:00:40 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 4 Dec 2003 13:02:40 -0800 To: gmj@pobox.com, saag@mit.edu From: Paul Hoffman / IMC Subject: Re: [saag] What is "strong" crypto ? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.541641 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Dec 2003 21:00:05 -0000 At 2:17 PM -0500 12/4/03, George Jones wrote: >The question is, for the non-crypto-expert (the >poor schmuck who's just trying to purchase/deploy/operate a network), >is there a good way to determine "strong" ? See , which will go into IETF last call Real Soon Now. Although we are describing how to match the strength of asymmetric encryption to symmetric encryption, we use the definition of "strong" as 90 bits in 1996. We say "The 90 bit number should be increased by about 2/3 bit/year, or about 96 bits in 2005." > Have I missed relevant >RFCs/BCPs ? Not that I know of. > Would an "Evaluating and Choosing Strong Crypto" BCP >be in order ? Probably. --Paul Hoffman, Director --Internet Mail Consortium From pbaker@verisign.com Thu Dec 4 16:08:17 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB4L8HD7018493 for ; Thu, 4 Dec 2003 16:08:17 -0500 (EST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) hB4L8vXs013840 for ; Thu, 4 Dec 2003 16:08:57 -0500 (EST) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.10/) with ESMTP id hB4L8tXD026175; Thu, 4 Dec 2003 13:08:56 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Dec 2003 13:08:55 -0800 Message-ID: <2A1D4C86842EE14CA9BC80474919782E01113271@mou1wnexm02.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: "'Steve Bellovin'" , saag@mit.edu Subject: RE: [saag] 3DES vs. AES Date: Thu, 4 Dec 2003 13:08:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.549799 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Dec 2003 21:08:18 -0000 > On the other hand, as John Gilmore has noted, 3DES has been > studied for > about 25 years. That's a lot of scrutiny; AES hasn't had nearly that > much attention. I am not sure this is true. There is a lot of analysis of DES, not so much on 3DES and the analysis that there is is not all that complimentary. There is the meet in the middle known plaintext attack that limits the security to twice DES, despite requiring keying material for tripple. There is the short block size leading to collision issues after relatively short streams of ciphertext. I would rather have AES which has been studied extensively as a next generation cipher rather than 3DES which was a sticking plaster on an old one. I do not like the idea of both, bad for doing crypto hardware. Phill From housley@vigilsec.com Thu Dec 4 16:28:48 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB4LSlD7018900 for ; Thu, 4 Dec 2003 16:28:47 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) hB4LTTxt021888 for ; Thu, 4 Dec 2003 16:29:29 -0500 (EST) Received: (qmail 347 invoked by uid 0); 4 Dec 2003 21:29:04 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.171.51) by woodstock.binhost.com with SMTP; 4 Dec 2003 21:29:04 -0000 Message-Id: <5.2.0.9.2.20031204162753.042f6150@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 04 Dec 2003 16:29:25 -0500 To: gmj@pobox.com, saag@mit.edu From: Russ Housley Subject: Re: [saag] What is "strong" crypto ? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.600615 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Dec 2003 21:28:48 -0000 Perhaps a reference to draft-orman-public-key-lengths is the best solution. This document about to be reviewed by the IESG, so it is likely to become an RFC before the OPSec documents. Russ At 02:17 PM 12/4/2003 -0500, George Jones wrote: >I'm working on updates to draft-jones-opsec-02.txt. One of the >requirements is the use of "strong" crypto to protect management >traffic. Of course, "strong" is a very relative, time sensitive term. >One of the reviewers said: > > > Unfortunately, it's a function of customer needs which are going to vary > > pretty widely. I think the best we can do is try to get vendors to provide > > enough information about what they're doing so that customers can make a > > reasonably informed decision. It might help to point out what is BCP in > > current IETF protocols in these spaces. > >Which seems to be in line with RFC 3365: > >3365> Finally, as to understanding cryptography, you don't have to. In >3365> other words, you do not need to become a cryptographer in order to >3365> effectively make use of cryptographic technology. Instead you make >3365> use of existing well understood ciphers and cipher suites to solve >3365> the engineering problem you face. >3365> >3365> One of the goals that we have in the Security Area of the IETF is to >3365> come up with guides so that protocol implementers can choose >3365> appropriate technology without having to understand the minutiae. > >Earlier, it says > >3365> 7. MUST is for Implementors >3365> >3365> We often say that Security is a MUST implement. It is worth noting >3365> that there is a significant different between MUST implement and MUST >3365> use. >3365> ... >3365> However security must be a MUST IMPLEMENT so that end users will have >3365> the option of enabling it when the situation calls for it. > >Which is precisely what the opsec drafts are trying to nail down for the >domain of >large/backbone network gear. > >"strong" encryption provides a good mechanism for achieving secure >remote management. The question is, for the non-crypto-expert (the >poor schmuck who's just trying to purchase/deploy/operate a network), >is there a good way to determine "strong" ? Have I missed relevant >RFCs/BCPs ? Would an "Evaluating and Choosing Strong Crypto" BCP >be in order ? > >Thanks, >---George Jones > > >_______________________________________________ >saag mailing list >saag@mit.edu >https://jis.mit.edu/mailman/listinfo/saag From tim.polk@nist.gov Thu Dec 4 16:59:37 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB4LxaD7019571 for ; Thu, 4 Dec 2003 16:59:36 -0500 (EST) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) hB4LwAXs026256 for ; Thu, 4 Dec 2003 16:58:10 -0500 (EST) Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id hB4Lvm19008786 for ; Thu, 4 Dec 2003 16:57:48 -0500 (EST) Message-Id: <5.1.0.14.2.20031204154730.02f56c78@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 04 Dec 2003 16:57:15 -0500 To: saag@mit.edu From: Tim Polk Subject: Re: [saag] 3DES vs. AES In-Reply-To: <20031203194420.6067B7B43@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.575959 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Dec 2003 21:59:38 -0000 I would certainly like to see AES become the mandatory algorithm in new protocols instead of 3DES. The security margin for 3DES should be adequate for a number of years, but AES seems to have all the tangible benefits in terms of performance and system design. It is probably true that AES hasn't had the same scrutiny as DES (yet). It has been just a little over 5 years since the AES candidates were announced. However, the selection process certainly accelerated the independent review process. Given the tools available for cryptanalysis (as Hilarie pointed out) and the energy focused on analyzing the candidate algorithms during the selection process, I feel pretty good about the level of scrutiny. Tim At 02:44 PM 12/3/2003 -0500, you wrote: >For new deployments, which cipher should be mandatory-to-implement, >3DES or AES? > >For protocols with an installed base, we've mandated 3DES, with AES as >a "SHOULD". The IPsec WG has said something stronger: AES is a >"SHOULD+", meaning that it will probably become a "MUST" in the next >version. > >But what do we tell protocol designers who are designing new protocols? >My personal preference is AES. For the low end, it's so much more efficient >in software; for the high end, its 128-bit block size permits much more >data to be encrypted with a single key. > >On the other hand, as John Gilmore has noted, 3DES has been studied for >about 25 years. That's a lot of scrutiny; AES hasn't had nearly that >much attention. > > --Steve Bellovin, http://www.research.att.com/~smb > > >_______________________________________________ >saag mailing list >saag@mit.edu >https://jis.mit.edu/mailman/listinfo/saag From paul.hoffman@vpnc.org Fri Dec 5 15:57:17 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB5KvGD7011263 for ; Fri, 5 Dec 2003 15:57:16 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) hB5KvvTP020193 for ; Fri, 5 Dec 2003 15:57:58 -0500 (EST) Received: from [63.202.92.152] (adsl-66-125-125-69.dsl.pltn13.pacbell.net [66.125.125.69]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5Kvtic067065 for ; Fri, 5 Dec 2003 12:57:55 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 5 Dec 2003 12:59:53 -0800 To: saag@mit.edu From: Paul Hoffman / VPNC Content-Type: text/plain; charset="us-ascii" ; format="flowed" Spam-Alum-Prob: 0.000313 Spam-Alum-Time: 0.558469 Subject: [saag] Fwd: Last Call: 'Determining Strengths For Public Keys Used For Exchanging Symmetric Keys' to BCP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 05 Dec 2003 20:57:17 -0000 Hilarie and I are still hoping for any last-minute comments on this document before it goes to the IESG. --Paul Hoffman >To: IETF-Announce :; >Cc: >From: The IESG >Subject: Last Call: 'Determining Strengths For Public Keys Used For Exchanging > Symmetric Keys' to BCP >Reply-to: iesg@ietf.org >Date: Fri, 05 Dec 2003 15:12:06 -0500 >Sender: owner-ietf-announce@ietf.org > >The IESG has received a request from an individual submitter to consider the >following document: > >- 'Determining Strengths For Public Keys Used For Exchanging Symmetric Keys ' > as a BCP > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2004-01-02. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-orman-public-key-lengths-06.txt From martin.euchner@siemens.com Thu Dec 4 03:43:47 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB48hkD7005661 for ; Thu, 4 Dec 2003 03:43:46 -0500 (EST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) hB48iRXs008680 for ; Thu, 4 Dec 2003 03:44:27 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id hB48iLS05010; Thu, 4 Dec 2003 09:44:22 +0100 (MET) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id hB48iLL18979; Thu, 4 Dec 2003 09:44:21 +0100 (MET) Received: from mchh273e.mchh.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id JAA12739; Thu, 4 Dec 2003 09:44:20 +0100 (MET) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Thu, 4 Dec 2003 09:44:20 +0100 Message-ID: <8C878B55C96F924389908D4A7384842A48BDDA@mchh2c7e.mchh.siemens.de> From: Euchner Martin To: "'Paul Hoffman / IMC'" , Steve Bellovin , saag@mit.edu, Euchner Martin Subject: RE: [saag] 3DES vs. AES Date: Thu, 4 Dec 2003 09:44:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.587087 X-Mailman-Approved-At: Sat, 06 Dec 2003 17:04:00 -0500 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Dec 2003 08:43:47 -0000 AES is certainly a preferred choice today and is gaining more and more broad acceptance in the industry due to its beneficial performance advantages over 3DES. Still, in order to mitigate any unforeseen risk of discovered potential weaknesses and leave opportunity for future more improved encryption algorithms (security, performance,...) that might sooner or later pop up, AES should not be made the one and only choice. Why not make AES a MUST but at the same time allow 3DES or equivalent as SHOULD for the next "engineering" period? With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | ICN M SR 3 mailto:Martin.Euchner@siemens.com | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul Hoffman / IMC [mailto:phoffman@imc.org] Sent: Thursday, December 04, 2003 3:20 AM To: Steve Bellovin; saag@mit.edu Subject: Re: [saag] 3DES vs. AES At 2:44 PM -0500 12/3/03, Steve Bellovin wrote: >For protocols with an installed base, we've mandated 3DES, with AES as >a "SHOULD". The IPsec WG has said something stronger: AES is a >"SHOULD+", meaning that it will probably become a "MUST" in the next >version. > >But what do we tell protocol designers who are designing new protocols? AES. If new protocols specify only TripleDES, that doesn't give them a clear forward path. If they make TripleDES a MUST and AES as SHOULD+, like we did in IKEv2, that forces new implementations to do both. They should just start with AES. --Paul Hoffman, Director --Internet Mail Consortium _______________________________________________ saag mailing list saag@mit.edu https://jis.mit.edu/mailman/listinfo/saag From pjnesser@Nesser.COM Thu Dec 4 12:34:13 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB4HYCD7013982 for ; Thu, 4 Dec 2003 12:34:12 -0500 (EST) Received: from arda.Nesser.COM ([192.104.59.100])hB4HYrxt011724 for ; Thu, 4 Dec 2003 12:34:54 -0500 (EST) Received: from arda.nesser.com (localhost [127.0.0.1]) by arda.Nesser.COM (8.12.8/8.12.6) with ESMTP id hB4HsKxs025271; Thu, 4 Dec 2003 09:54:20 -0800 (PST) Received: from localhost (pjnesser@localhost)hB4HsKMu025268; Thu, 4 Dec 2003 09:54:20 -0800 (PST) Date: Thu, 4 Dec 2003 09:54:20 -0800 (PST) From: "Philip J. Nesser II" To: Steve Bellovin Subject: Re: [saag] 3DES vs. AES In-Reply-To: <20031203194420.6067B7B43@berkshire.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.574102 X-Mailman-Approved-At: Sat, 06 Dec 2003 17:04:00 -0500 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Dec 2003 17:34:14 -0000 It seems that the obvious choice would be BOTH AES and 3DES MUST be MUST. At some point in the future we may recommend moving to MUST for AES and SHOULD for 3DES. (or maybe not, some serious flaw in AES might be discovered) If the protocol has a mechanism for multiple ciphers (and I can't think of any that doesn't), than there is little extra overhead in requiring two MUSTs. The question in my mind is what is the primary cipher? Since there are people here with serious cryptographic skills and knowledge, wouldn't it be prudent to write a very short BCP saying something along the lines of: --- Currently the recommendation is to require both AES and 3DES --- In the following cases (insert cases here...)AES is the recommended primary cipher for these reasons...(insert reasons here...) --- In the following cases (insert cases here...)3DES is the recommended primary cipher for these reasons...(insert reasons here...) ---> Phil On Wed, 3 Dec 2003, Steve Bellovin wrote: > For new deployments, which cipher should be mandatory-to-implement, > 3DES or AES? > > For protocols with an installed base, we've mandated 3DES, with AES as > a "SHOULD". The IPsec WG has said something stronger: AES is a > "SHOULD+", meaning that it will probably become a "MUST" in the next > version. > > But what do we tell protocol designers who are designing new protocols? > My personal preference is AES. For the low end, it's so much more efficient > in software; for the high end, its 128-bit block size permits much more > data to be encrypted with a single key. > > On the other hand, as John Gilmore has noted, 3DES has been studied for > about 25 years. That's a lot of scrutiny; AES hasn't had nearly that > much attention. > > --Steve Bellovin, http://www.research.att.com/~smb > > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag > From pjnesser@Nesser.COM Thu Dec 4 13:08:42 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB4I8fD7014617 for ; Thu, 4 Dec 2003 13:08:42 -0500 (EST) Received: from arda.Nesser.COM ([192.104.59.100])hB4I9Mxt011331 for ; Thu, 4 Dec 2003 13:09:23 -0500 (EST) Received: from arda.nesser.com (localhost [127.0.0.1]) by arda.Nesser.COM (8.12.8/8.12.6) with ESMTP id hB4ISoxs025416; Thu, 4 Dec 2003 10:28:50 -0800 (PST) Received: from localhost (pjnesser@localhost)hB4ISnkO025413; Thu, 4 Dec 2003 10:28:49 -0800 (PST) Date: Thu, 4 Dec 2003 10:28:49 -0800 (PST) From: "Philip J. Nesser II" To: "Steven M. Bellovin" Subject: Re: [saag] 3DES vs. AES In-Reply-To: <20031204174143.E52157B43@berkshire.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.588502 X-Mailman-Approved-At: Sat, 06 Dec 2003 17:04:00 -0500 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Dec 2003 18:08:43 -0000 On Thu, 4 Dec 2003, Steven M. Bellovin wrote: > In message , "Philip > J. Nesser II" writes: > >It seems that the obvious choice would be BOTH AES and 3DES MUST be MUST. > >At some point in the future we may recommend moving to MUST for AES and > >SHOULD for 3DES. (or maybe not, some serious flaw in AES might be > >discovered) > > > >If the protocol has a mechanism for multiple ciphers (and I can't think > >of any that doesn't), than there is little extra overhead in requiring two > >MUSTs. > > There are two objections. The first is code bloat; that can matter a > lot for low-end devices. No disagreement. > The second is more subtle: if a flaw is found > in one, you aren't more secure if you have both unless lots of people > disable the the faulty cipher. This objection was raised quite > prominently during the debate over AES -- should there be one AES or > two? So if you only have one MUST and a flaw in that cipher is found, the theory is that people will rev the protocol spec, scream from the heavens, and all the vendors will rush out patches/updates which everyone will immediately install it to avoid the faulty cipher? And since some vendors will only implement the MUST, the other cipher without the flaw will not be available on some implementations... At lease if you have two then someone running the server side of the protocol can update their server and not allow the faulty cipher, forcing clients to only use the non-flawed cipher. > > > >The question in my mind is what is the primary cipher? Since there are > >people here with serious cryptographic skills and knowledge, wouldn't it > >be prudent to write a very short BCP saying something along the lines of: > > > >--- Currently the recommendation is to require both AES and 3DES > >--- In the following cases (insert cases here...)AES is the recommended > >primary cipher for these reasons...(insert reasons here...) > >--- In the following cases (insert cases here...)3DES is the recommended > >primary cipher for these reasons...(insert reasons here...) > > > > Russ and I have already asked someone to write such a document. > Excellent. > --Steve Bellovin, http://www.research.att.com/~smb > > ---> Phil From jim_hughes@stortek.com Sat Dec 6 21:17:19 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB72HHD7005231 for ; Sat, 6 Dec 2003 21:17:18 -0500 (EST) Received: from sherman.stortek.com (sherman.stortek.com [129.80.22.146]) hB72I0XE021593 for ; Sat, 6 Dec 2003 21:18:00 -0500 (EST) Received: from sherman.stortek.com (localhost [127.0.0.1]) by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id hB72HxOW027689 for ; Sat, 6 Dec 2003 19:17:59 -0700 (MST) Received: from [10.0.1.3] ([129.80.74.64]) by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id hB72Hv31027676; Sat, 6 Dec 2003 19:17:57 -0700 (MST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4775C486-285C-11D8-9839-000A95A27482@stortek.com> Content-Transfer-Encoding: 7bit From: james hughes Subject: Re: [saag] 3DES vs. AES Date: Sat, 6 Dec 2003 21:23:00 -0500 To: "Philip J. Nesser II" X-Mailer: Apple Mail (2.606) Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.653038 X-Mailman-Approved-At: Sat, 06 Dec 2003 22:44:49 -0500 cc: james hughes cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 07 Dec 2003 02:17:19 -0000 As a vendor, I would strongly recommend that only one cipher be must, and that cipher be AES. Implementing two ciphers is more than twice as hard as one since you need to control the selection. If you have 2 ciphers, the chances of a flaw being found in one of them is twice as if you have one cipher. I agree that time does lower the probability of a problem, but does not eliminate it. The size of the cipher is an issue. 3DES is 64 bit and AES is 128 bit. This difference has significant impact on several modes of operation (like cycle size of OFB, and collisions in hash modes). Having new standards implement 3DES leaves them in the past, and we all know that the life of these ciphers is significant. I was very vocal at the AES meeting (along with several others) that one is needed to be picked, not two. Picking AES is still conservative because AES has been accepted by US and Europe (soon Japan) as a government algorithm. The Algebraic attacks that have been published are controversial within the community and have not been verified with real results. Europe https://www.cosic.esat.kuleuven.ac.be/nessie/deliverables/ press_release_feb27.pdf US http://www.nstissc.gov/Assets/pdf/fact%20sheet.pdf Japan http://www.ipa.go.jp/security/enc/CRYPTREC/fy15/ cryptrec20030620_repe.html Note that 3DES is not listed in NESSIE as approved (it may still be grandfathered in) and that 3DES has not been approved for classified. My suggestion is that AES is all that is necessary and that all new standard (that have the opportunity to start fresh) should use AES. It would be OK for AES MUST and 3DES SHOULD+ Thanks jim On Dec 4, 2003, at 1:28 PM, Philip J. Nesser II wrote: > > > On Thu, 4 Dec 2003, Steven M. Bellovin wrote: > >> In message >> , "Philip >> J. Nesser II" writes: >>> It seems that the obvious choice would be BOTH AES and 3DES MUST be >>> MUST. >>> At some point in the future we may recommend moving to MUST for AES >>> and >>> SHOULD for 3DES. (or maybe not, some serious flaw in AES might be >>> discovered) >>> >>> If the protocol has a mechanism for multiple ciphers (and I can't >>> think >>> of any that doesn't), than there is little extra overhead in >>> requiring two >>> MUSTs. >> >> There are two objections. The first is code bloat; that can matter a >> lot for low-end devices. > > No disagreement. > >> The second is more subtle: if a flaw is found >> in one, you aren't more secure if you have both unless lots of people >> disable the the faulty cipher. This objection was raised quite >> prominently during the debate over AES -- should there be one AES or >> two? > > So if you only have one MUST and a flaw in that cipher is found, the > theory is that people will rev the protocol spec, scream from the > heavens, > and all the vendors will rush out patches/updates which everyone will > immediately install it to avoid the faulty cipher? And since some > vendors > will only implement the MUST, the other cipher without the flaw will > not > be available on some implementations... At lease if you have two then > someone running the server side of the protocol can update their server > and not allow the faulty cipher, forcing clients to only use the > non-flawed cipher. > > >>> >>> The question in my mind is what is the primary cipher? Since there >>> are >>> people here with serious cryptographic skills and knowledge, >>> wouldn't it >>> be prudent to write a very short BCP saying something along the >>> lines of: >>> >>> --- Currently the recommendation is to require both AES and 3DES >>> --- In the following cases (insert cases here...)AES is the >>> recommended >>> primary cipher for these reasons...(insert reasons here...) >>> --- In the following cases (insert cases here...)3DES is the >>> recommended >>> primary cipher for these reasons...(insert reasons here...) >>> >> >> Russ and I have already asked someone to write such a document. >> > > Excellent. > > >> --Steve Bellovin, http://www.research.att.com/~smb >> >> > > ---> Phil > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag > From jari.arkko@piuha.net Sun Dec 7 04:35:44 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB79Zh5K011355 for ; Sun, 7 Dec 2003 04:35:43 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) hB79aPXE005912 for ; Sun, 7 Dec 2003 04:36:25 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C450C6A905 for ; Sun, 7 Dec 2003 11:36:21 +0200 (EET) Message-ID: <3FD2F380.3040901@piuha.net> Date: Sun, 07 Dec 2003 11:31:44 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu Subject: Re: [saag] 3DES vs. AES References: <4775C486-285C-11D8-9839-000A95A27482@stortek.com> In-Reply-To: <4775C486-285C-11D8-9839-000A95A27482@stortek.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Spam-Alum-Prob: 0.000827 Spam-Alum-Time: 0.527539 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 07 Dec 2003 09:35:44 -0000 My preference is a MUST for AES. Regarding the support of multiple algorithms: it is a MUST as well, but I believe it is sufficient to mandate that on its own and not indirectly through making 3DES a SHOULD. SHOULD is a quite strong keyword, and remember that Steven's question was about new protocols, not about what to do with IPsec and other existing things. If I was building a product based on a new standard, I would put in AES and another cipher of comparable characteristics -- maybe one of the other AES candidates, maybe Blowfish. But not 3DES. --Jari From crawdad@fnal.gov Mon Dec 8 09:51:54 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB8Epr5K006136 for ; Mon, 8 Dec 2003 09:51:53 -0500 (EST) Received: from woozle.fnal.gov (woozle.fnal.gov [131.225.9.22]) hB8EqZrs017489 for ; Mon, 8 Dec 2003 09:52:35 -0500 (EST) Received: from conversion-daemon.woozle.fnal.gov by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) id <0HPK00D01ZZCXC@woozle.fnal.gov> for saag@mit.edu; Mon, 08 Dec 2003 08:52:35 -0600 (CST) Received: from [131.225.82.58] by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTPSA id <0HPK001MMZZNRG@woozle.fnal.gov>; Mon, 08 Dec 2003 08:52:35 -0600 (CST) Date: Mon, 08 Dec 2003 07:39:11 -0600 From: Matt Crawford Subject: Re: [saag] 3DES vs. AES In-reply-to: <4775C486-285C-11D8-9839-000A95A27482@stortek.com> To: james hughes Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.606) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <4775C486-285C-11D8-9839-000A95A27482@stortek.com> Spam-Alum-Prob: 0.139433 Spam-Alum-Time: 0.523637 cc: saag@mit.edu cc: "Philip J. Nesser II" X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 08 Dec 2003 14:51:54 -0000 On Dec 6, 2003, at 8:23 PM, james hughes wrote: > As a vendor, I would strongly recommend that only one cipher be must, > and that cipher be AES. Implementing two ciphers is more than twice as > hard as one since you need to control the selection. That's the point I was trying to make, but spoken from the other side of the fence. If you don't require two, some will not allow the possibility of a second cipher. From nw141292@binky.central.sun.com Mon Dec 8 10:51:03 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB8Fp15K007437 for ; Mon, 8 Dec 2003 10:51:01 -0500 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) hB8FphXE022148 for ; Mon, 8 Dec 2003 10:51:44 -0500 (EST) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hB8FpgUP004098; Mon, 8 Dec 2003 07:51:42 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) with ESMTP id hB8Fpfo4028385; Mon, 8 Dec 2003 08:51:41 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) hB8FlGYY026146; Mon, 8 Dec 2003 09:47:16 -0600 (CST) Received: (from nw141292@localhost)hB8FlFFo026145; Mon, 8 Dec 2003 07:47:15 -0800 (PST) Date: Mon, 8 Dec 2003 07:47:15 -0800 From: Nicolas Williams To: Matt Crawford Subject: Re: [saag] 3DES vs. AES Message-ID: <20031208154715.GI887@binky.central.sun.com> References: <4775C486-285C-11D8-9839-000A95A27482@stortek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Spam-Alum-Prob: 0.000005 Spam-Alum-Time: 1.381528 Spam-Alum-Trained: Yes cc: james hughes cc: saag@mit.edu cc: "Philip J. Nesser II" X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 08 Dec 2003 15:51:03 -0000 On Mon, Dec 08, 2003 at 07:39:11AM -0600, Matt Crawford wrote: > On Dec 6, 2003, at 8:23 PM, james hughes wrote: > >As a vendor, I would strongly recommend that only one cipher be must, > >and that cipher be AES. Implementing two ciphers is more than twice as > >hard as one since you need to control the selection. > > That's the point I was trying to make, but spoken from the other side > of the fence. If you don't require two, some will not allow the > possibility of a second cipher. One can always specify a "null" algorithm and AES/whatever so that there are at least two algorithms to negotiate. The "null" algo. would, of course, be intended to be disabled at all times, except, crucially, when interop testing. It is important that IETF protocols support negotiation of cryptographic algorithms and authentication and key exchange protocols so that there is a better upgrade path than protocol obsolescence. But it isn't enough to have negotiation built into a spec if it later turns out that implementation bugs or spec vagueness makes the negotiation unworkable, which is why we must have MUST-implement "null" algorithms where initially only one real algorithm is to be a MUST- implement, so that negotiation can be shown to be workable. Cheers, Nico -- From rja@extremenetworks.com Mon Dec 8 11:03:45 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB8G3i5K007776 for ; Mon, 8 Dec 2003 11:03:44 -0500 (EST) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) hB8G4QXE001980 for ; Mon, 8 Dec 2003 11:04:26 -0500 (EST) Received: from [10.18.3.100] (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 7805F67105 for ; Mon, 8 Dec 2003 11:11:47 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: References: <4775C486-285C-11D8-9839-000A95A27482@stortek.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <30BD36BF-2998-11D8-BE20-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [saag] 3DES vs. AES Date: Mon, 8 Dec 2003 11:04:23 -0500 To: saag@mit.edu X-Mailer: Apple Mail (2.606) Spam-Alum-Prob: 0.001264 Spam-Alum-Time: 1.521791 Spam-Alum-Trained: Yes X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 08 Dec 2003 16:03:46 -0000 On Dec 08, 2003, at 08:39, Matt Crawford wrote: > On Dec 6, 2003, at 8:23 PM, james hughes wrote: >> As a vendor, I would strongly recommend that only one cipher be must, >> and that cipher be AES. Implementing two ciphers is more than twice >> as hard as one since you need to control the selection. > > That's the point I was trying to make, but spoken from the other side > of the fence. If you don't require two, some will not allow the > possibility of a second cipher. I'm not sure that I agree with Jim that it is *necessarily* "more than twice as hard as one", having implemented protocols with cryptography myself a few times now (though indeed Jim has implemented such things several times himself over the years). I definitely agree that supporting two is a bit more difficult than supporting only one. The degree of additional difficulty is highly dependent on how thoughtful one designs one's implementation architecture, IMHO. If one has the right implementation architecture (to Matt's point), then supporting a 2nd algorithm is a bit more work but not a huge deal. If one does not have the right implementation architecture, then supporting a 2nd algorithm could be arbitrarily more complex. Again echoing Matt's point, the history of applied cryptography is filled with instances where after some time period the public community discovers a significant problem with an algorithm, algorithm mode, or some other aspect of using an algorithm. So we ought to be incenting implementers to have an implementation architecture that would permit changing the algorithm (etc.) later on -- when we discover issues with the currently specified approach. Further, AES (and particularly AES counter-mode) do not have anywhere near the level of published cryptaanalysis that exists for 3DES. There is no way that AES could have that level this year or next year. So conservative, prudent application of cryptography would say that we ought to require both 3DES and AES for the near-term, with an eye to dropping the 3DES mandate *after* there is more published cryptanalysis of AES. In the event the community chooses not to require more than one algorithm be implemented in the near-term, I would strongly urge that the community require the open specification of both 3DES and AES for the near-term. That way, end users who prefer one of those algorithms over the other would be able to point their equipment suppliers at an open specification that would provide interoperability via that user's preferred algorithm (even if the user's preferred algorithm was not the IETF's mandatory algorithm). [please substitute "algorithm, mode, etc." where "algorithm is used above, I'm intending a broad meaning not a narrow one. :-] I suspect that all perspectives on this topic have been expressed on this list by now, but maybe not. Ran Atkinson rja@extremenetworks.com From smb@research.att.com Mon Dec 8 11:49:06 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB8Gn45K008571 for ; Mon, 8 Dec 2003 11:49:04 -0500 (EST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111])hB8GnkXE006671 for ; Mon, 8 Dec 2003 11:49:46 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by mail-pink.research.att.com (Postfix) with ESMTP id DABBD100342; Mon, 8 Dec 2003 11:49:12 -0500 (EST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-green.research.att.com (Postfix) with ESMTP id 27B00F3A97; Mon, 8 Dec 2003 11:49:41 -0500 (EST) Received: from berkshire.research.att.com (sigaba.research.att.com [135.207.23.169])hB8GnjZ24442; Mon, 8 Dec 2003 11:49:45 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id E13607B43; Mon, 8 Dec 2003 11:49:44 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Nicolas Williams Subject: Re: [saag] 3DES vs. AES In-Reply-To: Your message of "Mon, 08 Dec 2003 07:47:15 PST." <20031208154715.GI887@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Dec 2003 11:49:44 -0500 Message-Id: <20031208164945.E13607B43@berkshire.research.att.com> Spam-Alum-Prob: 0.000004 Spam-Alum-Time: 1.315835 Spam-Alum-Trained: Yes cc: Matt Crawford cc: james hughes cc: "Philip J. Nesser II" cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 08 Dec 2003 16:49:06 -0000 In message <20031208154715.GI887@binky.central.sun.com>, Nicolas Williams write s: > >It is important that IETF protocols support negotiation of cryptographic >algorithms and authentication and key exchange protocols so that there >is a better upgrade path than protocol obsolescence. To me, this part is a no-brainer, and I think it's been reflected in virtually all IETF cryptographic mechanisms over the years. They MUST be algorithm-agile, because algorithms *will* change. > >But it isn't enough to have negotiation built into a spec if it later >turns out that implementation bugs or spec vagueness makes the >negotiation unworkable, which is why we must have MUST-implement "null" >algorithms where initially only one real algorithm is to be a MUST- >implement, so that negotiation can be shown to be workable. > This is the question we really need to focus on -- do we have to have two mandatory-to-implement algorithms to help guard against specfication or implemenation bugs? --Steve Bellovin, http://www.research.att.com/~smb From phoffman@imc.org Mon Dec 8 11:53:21 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB8GrJ5K008690 for ; Mon, 8 Dec 2003 11:53:19 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) hB8Gr4rs016471 for ; Mon, 8 Dec 2003 11:53:04 -0500 (EST) Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8Gr0ic006564; Mon, 8 Dec 2003 08:53:01 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: <4775C486-285C-11D8-9839-000A95A27482@stortek.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 8 Dec 2003 08:55:04 -0800 To: Matt Crawford , james hughes From: Paul Hoffman / IMC Subject: Re: [saag] 3DES vs. AES Content-Type: text/plain; charset="us-ascii" ; format="flowed" Spam-Alum-Prob: 0.000169 Spam-Alum-Time: 1.000620 Spam-Alum-Trained: Yes cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 08 Dec 2003 16:53:21 -0000 At 7:39 AM -0600 12/8/03, Matt Crawford wrote: >If you don't require two, some will not allow the possibility of a >second cipher. Then that's the vendor's problem. Every new protocol that uses crypto will have some sort of algorithm negotiation/announcement mechanism. That might be negotiations as we have today, or it might be just a protocol version number ("version 1 means AES" -> AES is broken -> IETF acts quickly -> "version 2 means TripleDES"). --Paul Hoffman, Director --Internet Mail Consortium From nw141292@binky.central.sun.com Mon Dec 8 12:09:31 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB8H9N5K009022 for ; Mon, 8 Dec 2003 12:09:28 -0500 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) hB8HA4rs000379 for ; Mon, 8 Dec 2003 12:10:05 -0500 (EST) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hB8HA2UP025044; Mon, 8 Dec 2003 09:10:03 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) with ESMTP id hB8HA2o4014058; Mon, 8 Dec 2003 10:10:02 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) hB8H5bYY026257; Mon, 8 Dec 2003 11:05:37 -0600 (CST) Received: (from nw141292@localhost)hB8H5a6P026256; Mon, 8 Dec 2003 09:05:36 -0800 (PST) Date: Mon, 8 Dec 2003 09:05:36 -0800 From: Nicolas Williams To: "Steven M. Bellovin" Subject: Re: [saag] 3DES vs. AES Message-ID: <20031208170536.GJ887@binky.central.sun.com> References: <20031208154715.GI887@binky.central.sun.com> <20031208164945.E13607B43@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031208164945.E13607B43@berkshire.research.att.com> User-Agent: Mutt/1.4i Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 2.536020 Spam-Alum-Trained: Yes cc: Matt Crawford cc: james hughes cc: "Philip J. Nesser II" cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 08 Dec 2003 17:09:32 -0000 On Mon, Dec 08, 2003 at 11:49:44AM -0500, Steven M. Bellovin wrote: > In message <20031208154715.GI887@binky.central.sun.com>, Nicolas Williams write > s: > > > >It is important that IETF protocols support negotiation of cryptographic > >algorithms and authentication and key exchange protocols so that there > >is a better upgrade path than protocol obsolescence. > > To me, this part is a no-brainer, and I think it's been reflected in > virtually all IETF cryptographic mechanisms over the years. They MUST > be algorithm-agile, because algorithms *will* change. Good. But the quite reasonable position of some that requiring AES and 3DES bloats HW designs has clouded this no-brainer. Separating the negotiation issue from the AES-and/or-3DES issue should clarify it. > >But it isn't enough to have negotiation built into a spec if it later > >turns out that implementation bugs or spec vagueness makes the > >negotiation unworkable, which is why we must have MUST-implement "null" > >algorithms where initially only one real algorithm is to be a MUST- > >implement, so that negotiation can be shown to be workable. > > > This is the question we really need to focus on -- do we have to have > two mandatory-to-implement algorithms to help guard against > specfication or implemenation bugs? I think the re-keying requirements of 3DES alone are enough to make it a lame requirement. But even ignoring that, I think we need to make two algorithms mandatory-to-implement, even if one be the "null" algorithm, just so we can ensure the ability of implementations to negotiate between them, thus proving the upgrade-by-adding-crypto-suites path. By the following anecdote I hope to illustrate the point that unused facilities may turn out to be unusable, perhaps even worse than useless. In the SECSH WG we've discovered that a facility meant for extending the key exchange portion of the SSHv2 protocol cannot really be used for that purpose because of the way deployed implementations handle that facility; not surprisingly the draft specs were vague on the point, merely labelling a structure's last field as "reserved." Fortunately the algorithm negotiation portion of the SSHv2 protocol does work in deployed implementations as specified and other, less apetizing paths for extending its key exchange portion remain. (I hope that algorithm negotiation will NOT be removed from Draft Standard protocols when progressing to Standard just because AES managed to stand the test of time (if it does)!) Cheers, Nico -- From rodney@canola-jones.com Mon Dec 8 12:12:48 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB8HCk5K009117 for ; Mon, 8 Dec 2003 12:12:47 -0500 (EST) Received: from yancy.pkiclue.com (yancy.pkiclue.com [209.172.115.117]) hB8HDMXE024347 for ; Mon, 8 Dec 2003 12:13:28 -0500 (EST) Received: from node2.canola-jones.com (IDENT:rodney@localhost [127.0.0.1]) by yancy.pkiclue.com (8.9.3/8.9.3) with ESMTP id JAA11059 for ; Mon, 8 Dec 2003 09:14:10 -0800 Message-Id: <5.2.0.9.2.20031208085913.04f380b0@127.0.0.1> X-Sender: pkiclue@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 08 Dec 2003 09:08:01 -0800 To: saag@mit.edu From: rodney@tillerman.to Subject: Re: [saag] 3DES vs. AES In-Reply-To: <30BD36BF-2998-11D8-BE20-00039357A82A@extremenetworks.com> References: <4775C486-285C-11D8-9839-000A95A27482@stortek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Spam-Alum-Prob: 0.001171 Spam-Alum-Time: 1.431117 Spam-Alum-Trained: Yes X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 08 Dec 2003 17:12:49 -0000 I don't care how hard it is to implement two crypto algorithms. It's certainly not significantly harder than, oh, say, implementing IKE from the ground up. I don't think that's an excuse to not do it. So I disagree with that argument. Cue Barbie(tm) voice... Security is hard I think we should have at least two algorithms. Crypto is not something we can, from an engineering perspective, ever say is "working". The best we can do is say it is "not known not to work". Therefore we should be designing future systems to fail over if possible. I think it would be architecturally irresponsible not to do this. For new protocols, I disagree that negotiating algorithms is a problem. If it is, then we're designing broken protocols. I think that in NEW protocols it should be mandatory that crypto algorithms, and other things, be properly negotiable. This would make it possible to switch off a fielded algorithm if a problem were to be discovered. So if someone comes up with a 3 line perl script to crack AES, one side of a peer pairing could switch off AES and use 3DES or whatever the other algorithm is. For new protocols, I disagree that negotiating algorithms is a problem. If it is, then we're designing broken protocols. I think AES and 3DES are the logical two choices. AES, while younger, has been explicitly studied in a modern industrial context which, while we can argue if ENOUGH study has been done, at least we can observe the studying. 3DES is one of the last remaining cold-war artifact of the pre-commercial security world - while it has been around a long time it has always had only quasi-official status and therefore I don't think it is correct to claim it is safer because it has been studied longer. From tim@dierks.org Mon Dec 8 12:32:26 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB8HWO5K009530 for ; Mon, 8 Dec 2003 12:32:24 -0500 (EST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) hB8HX6rs017718 for ; Mon, 8 Dec 2003 12:33:07 -0500 (EST) Received: (qmail 82276 invoked from network); 8 Dec 2003 17:33:05 -0000 Received: from okkod.pair.com (HELO PONGO.dierks.org) (209.68.2.80) by relay.pair.com with SMTP; 8 Dec 2003 17:33:05 -0000 X-pair-Authenticated: 209.68.2.80 Message-Id: <6.0.0.21.2.20031208121947.062eaea0@127.0.0.1> X-Sender: 127.0.0.1:2110:tdierks@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.21 Date: Mon, 08 Dec 2003 12:33:03 -0500 To: saag@mit.edu From: Tim Dierks Subject: Re: [saag] 3DES vs. AES In-Reply-To: <5.2.0.9.2.20031208085913.04f380b0@127.0.0.1> References: <4775C486-285C-11D8-9839-000A95A27482@stortek.com> <5.2.0.9.2.20031208085913.04f380b0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Spam-Alum-Prob: 0.001771 Spam-Alum-Time: 1.324293 Spam-Alum-Trained: Yes X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 08 Dec 2003 17:32:27 -0000 While it would be most convenient to take the route of specifying multiple algorithms as mandatory and hoping to keep our options open for later, there is a real problem: in the presence of active attacks, supporting multiple algorithms can degenerate into an attacker being able to force you into using the weakest of them. The only alternative I can see which allows a true "belt & suspenders" protection model is to make both algorithms a MUST to implement and a MAY to be available in any actual connection, and furthermore require that all implementors offer the user or administrator of a system the ability to disable one algorithm. That is, all products must be capable of both, with user configurability as to whether to support one or both. Alternately, any particular protocol could choose to place its bet by making one or the other MUST. Protocols which either provide protection for the negotiation mechanisms or which don't consider active attack to be part of their threat model could allow negotiation between multiple SHOULD algorithms. It seems to me that providing protection for the negotiation mechanism requires an authentication as part of the protocol. - Tim From nw141292@binky.central.sun.com Mon Dec 8 13:05:39 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB8I5b5K010187 for ; Mon, 8 Dec 2003 13:05:37 -0500 (EST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) hB8I6Jrs008929 for ; Mon, 8 Dec 2003 13:06:19 -0500 (EST) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hB8I6HPh016321; Mon, 8 Dec 2003 11:06:17 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) with ESMTP id hB8I6Go4008069; Mon, 8 Dec 2003 11:06:17 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) hB8I1pYY026275; Mon, 8 Dec 2003 12:01:51 -0600 (CST) Received: (from nw141292@localhost)hB8I1pLY026274; Mon, 8 Dec 2003 10:01:51 -0800 (PST) Date: Mon, 8 Dec 2003 10:01:51 -0800 From: Nicolas Williams To: Paul Hoffman / IMC Subject: Re: [saag] 3DES vs. AES Message-ID: <20031208180151.GK887@binky.central.sun.com> References: <4775C486-285C-11D8-9839-000A95A27482@stortek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.831609 Spam-Alum-Trained: Yes cc: Matt Crawford cc: james hughes cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 08 Dec 2003 18:05:39 -0000 On Mon, Dec 08, 2003 at 08:55:04AM -0800, Paul Hoffman / IMC wrote: > At 7:39 AM -0600 12/8/03, Matt Crawford wrote: > >If you don't require two, some will not allow the possibility of a > >second cipher. > > Then that's the vendor's problem. Every new protocol that uses crypto > will have some sort of algorithm negotiation/announcement mechanism. > That might be negotiations as we have today, or it might be just a > protocol version number ("version 1 means AES" -> AES is broken -> > IETF acts quickly -> "version 2 means TripleDES"). The upgrade-by-obsolescence upgrade path will always "work," of course. But the upgrade-by-adding-modules upgrade path is, methinks, more economical, and following it will take less time and effort, probably far less, to implement and deploy than the upgrade-by-obsolescence path. The Secure Shell protocols may make for a relevant case study: Weaknesses in the SSHv2 cryptographic suites have been found, and new cipher modes have been proposed for SSHv2 -- which proposals are not controversial when it comes to algorithm negotiation. The migration to use of the new SSHv2 cipher modes will require much less time and effort than the migration from SSHv1 to SSHv2, mostly for two reason: a) it's much less work to implement these new modes than it is to implement the rest of SSHv2, and b) the new modes do not alter the protocol's semantics, thus posing no interesting deployment problems other than the typical patch distribution problem. If, OTOH, upgrading SSHv2's algorithms required a new IETF BoF->WG->docs->review->RFC publication deathmarch, can you see deployment of a new version of the protocol happening in a reasonable time frame? The scope of the effort would have to be extremely limited, negotiation between the various versions of the protocol might turn out to be difficult to perform securely (i.e., w/o enabling downgrade attacks), and the opportunity cost of so limiting the scope of the effort could mean pushing other reviews of the functionality of the protocol many years further. I'm particularly concerned about downgrade attacks in version negotiation. If the old version does not provide for this then the upgrade path to a new version will be bumpy. Come to think of it, this should be a separate consideration in every protocol designed at the IETF. Cheers, Nico -- From rja@extremenetworks.com Mon Dec 8 13:15:25 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB8IFO5K010404 for ; Mon, 8 Dec 2003 13:15:24 -0500 (EST) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) hB8IG5rs015375 for ; Mon, 8 Dec 2003 13:16:05 -0500 (EST) Received: from [10.18.3.100] (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 432BC67105; Mon, 8 Dec 2003 13:23:30 -0500 (EST) In-Reply-To: <5.2.0.9.2.20031208085913.04f380b0@127.0.0.1> References: <4775C486-285C-11D8-9839-000A95A27482@stortek.com> <5.2.0.9.2.20031208085913.04f380b0@127.0.0.1> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <96634842-29AA-11D8-BE20-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [saag] 3DES vs. AES Date: Mon, 8 Dec 2003 13:16:05 -0500 To: rodney@tillerman.to X-Mailer: Apple Mail (2.606) Spam-Alum-Prob: 0.000030 Spam-Alum-Time: 1.305848 Spam-Alum-Trained: Yes cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 08 Dec 2003 18:15:26 -0000 On Dec 08, 2003, at 12:08, rodney@tillerman.to wrote: > I think AES and 3DES are the logical two choices. AES, while younger, > has > been explicitly studied in a modern industrial context which, while we > can argue > if ENOUGH study has been done, at least we can observe the studying. > 3DES is > one of the last remaining cold-war artifact of the pre-commercial > security world - > while it has been around a long time it has always had only > quasi-official > status and therefore I don't think it is correct to claim it is safer > because > it has been studied longer. It is untrue that DES "always had only quasi-official status". DES has always been an official US Government standard (specifically a Federal Information Processing Standard or FIPS) and it is also standardised by other governments. Further, DES was for many years officially the basis for official ANSI standards relating to security for the financial world. AES is also a FIPS, so the "official approval" status of AES is no different than it was for DES. DES has been studied openly for several decades, with ample publications (particularly including the Biham-Shamir analysis) while AES has only been studied (equally openly) for a few years, so it is quite reasonable reasonable to have much more confidence in DES than AES. Ran rja@extremenetworks.com From rja@extremenetworks.com Mon Dec 8 13:17:12 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB8IHB5K010450 for ; Mon, 8 Dec 2003 13:17:11 -0500 (EST) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) hB8IHsXE012132 for ; Mon, 8 Dec 2003 13:17:54 -0500 (EST) Received: from [10.18.3.100] (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id D45AA67105; Mon, 8 Dec 2003 13:25:18 -0500 (EST) In-Reply-To: <6.0.0.21.2.20031208121947.062eaea0@127.0.0.1> References: <4775C486-285C-11D8-9839-000A95A27482@stortek.com> <5.2.0.9.2.20031208085913.04f380b0@127.0.0.1> <6.0.0.21.2.20031208121947.062eaea0@127.0.0.1> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [saag] 3DES vs. AES Date: Mon, 8 Dec 2003 13:17:54 -0500 To: Tim Dierks X-Mailer: Apple Mail (2.606) Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.944842 Spam-Alum-Trained: Yes cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 08 Dec 2003 18:17:13 -0000 On Dec 08, 2003, at 12:33, Tim Dierks wrote: > While it would be most convenient to take the route of specifying > multiple algorithms as mandatory and hoping to keep our options open > for later, there is a real problem: in the presence of active attacks, > supporting multiple algorithms can degenerate into an attacker being > able to force you into using the weakest of them. That is not true if the protocols are properly designed, IMHO. And if the protocols are not properly designed, there are likely other active attacks that would be practical anyway. Ran From nw141292@binky.central.sun.com Mon Dec 8 13:20:00 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB8IJw5K010523 for ; Mon, 8 Dec 2003 13:19:58 -0500 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) hB8IKers018210 for ; Mon, 8 Dec 2003 13:20:40 -0500 (EST) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hB8IK8xA013875; Mon, 8 Dec 2003 10:20:08 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) with ESMTP id hB8IK7o4014044; Mon, 8 Dec 2003 11:20:08 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) hB8IFgYY026285; Mon, 8 Dec 2003 12:15:42 -0600 (CST) Received: (from nw141292@localhost)hB8IFfTu026284; Mon, 8 Dec 2003 10:15:41 -0800 (PST) Date: Mon, 8 Dec 2003 10:15:41 -0800 From: Nicolas Williams To: Tim Dierks Subject: Re: [saag] 3DES vs. AES Message-ID: <20031208181541.GL887@binky.central.sun.com> References: <4775C486-285C-11D8-9839-000A95A27482@stortek.com> <5.2.0.9.2.20031208085913.04f380b0@127.0.0.1> <6.0.0.21.2.20031208121947.062eaea0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.21.2.20031208121947.062eaea0@127.0.0.1> User-Agent: Mutt/1.4i Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.481794 Spam-Alum-Trained: Yes cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 08 Dec 2003 18:20:00 -0000 On Mon, Dec 08, 2003 at 12:33:03PM -0500, Tim Dierks wrote: > While it would be most convenient to take the route of specifying multiple > algorithms as mandatory and hoping to keep our options open for later, > there is a real problem: in the presence of active attacks, supporting > multiple algorithms can degenerate into an attacker being able to force you > into using the weakest of them. If one is not careful one may leave not only a algorithm negotiation open to downgrade attacks but also protocol major version negotiation. Downgrade attacks are a separate concern, and IETF protocols should definitely protect against those. And it isn't hard to do so either. [...] > It seems to me that providing protection for the negotiation > mechanism requires an authentication as part of the protocol. Definitely, authentication has to be part of the picture in order to prevent downgrade attacks. But authentication need not be a part of the immediate negotiation and key exchange. That's how IKEv2 works, for example; first there's a KE exchange, complete with unprotected negotiation of various parameters, followed by a CERTREQ/CERT/AUTH exchange which binds authentication to the KE, including the negotiation step, which binding defeats downgrade attacks. In fact, authentication could take place at a different network layer if one considers channel bindings. Another way to put this is that anonymous channels do not provide much security by themselves, particularly against downgrade attacks, but one may establish a secure-but-anonymous channel at one time and authenticate it a little later. Authenticating the channel later requires a cryptographically secure _name_ for the channel - which rfc2743 calls "channel bindings." (I'm very interested in this topic :) I propose that downgrade attacks are a red herring in this discussion; we know how to protect negotiations. Let's debate instead the merits of REQUIREing both, AES and 3DES, or just one, and which one and "null." Cheers, Nico -- From rodney@canola-jones.com Mon Dec 8 13:36:19 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB8IaH5K010932 for ; Mon, 8 Dec 2003 13:36:17 -0500 (EST) Received: from yancy.pkiclue.com (yancy.pkiclue.com [209.172.115.117]) hB8IaxXE025830 for ; Mon, 8 Dec 2003 13:37:00 -0500 (EST) Received: from node2.canola-jones.com (IDENT:rodney@localhost [127.0.0.1]) by yancy.pkiclue.com (8.9.3/8.9.3) with ESMTP id KAA11345 for ; Mon, 8 Dec 2003 10:37:51 -0800 Message-Id: <5.2.0.9.2.20031208103549.053120b8@127.0.0.1> X-Sender: pkiclue@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 08 Dec 2003 10:36:31 -0800 To: saag@mit.edu From: rodney@tillerman.to Subject: Re: [saag] 3DES vs. AES In-Reply-To: <96634842-29AA-11D8-BE20-00039357A82A@extremenetworks.com> References: <5.2.0.9.2.20031208085913.04f380b0@127.0.0.1> <4775C486-285C-11D8-9839-000A95A27482@stortek.com> <5.2.0.9.2.20031208085913.04f380b0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.346808 Spam-Alum-Trained: Yes X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 08 Dec 2003 18:36:19 -0000 At 01:16 PM 12/8/2003 -0500, RJ Atkinson wrote: >On Dec 08, 2003, at 12:08, rodney@tillerman.to wrote: >>I think AES and 3DES are the logical two choices. AES, while younger, has >>been explicitly studied in a modern industrial context which, while we >>can argue >>if ENOUGH study has been done, at least we can observe the studying. >>3DES is >>one of the last remaining cold-war artifact of the pre-commercial >>security world - >>while it has been around a long time it has always had only quasi-official >>status and therefore I don't think it is correct to claim it is safer because >>it has been studied longer. > >It is untrue that DES "always had only quasi-official status". I didn't say DES. I said 3DES. >DES has always been an official US Government standard (specifically >a Federal Information Processing Standard or FIPS) and it is >also standardised by other governments. And 3DES hasn't had a FIPS number, until recently, I believe. From rja@extremenetworks.com Mon Dec 8 14:15:50 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB8JFm5K011689 for ; Mon, 8 Dec 2003 14:15:49 -0500 (EST) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) hB8JGVXE024284 for ; Mon, 8 Dec 2003 14:16:31 -0500 (EST) Received: from [10.18.3.100] (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 7E12C67105; Mon, 8 Dec 2003 14:23:56 -0500 (EST) In-Reply-To: <5.2.0.9.2.20031208103407.04d7f838@127.0.0.1> References: <5.2.0.9.2.20031208085913.04f380b0@127.0.0.1> <4775C486-285C-11D8-9839-000A95A27482@stortek.com> <5.2.0.9.2.20031208085913.04f380b0@127.0.0.1> <5.2.0.9.2.20031208103407.04d7f838@127.0.0.1> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0774299C-29B3-11D8-BE20-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [saag] 3DES vs. AES Date: Mon, 8 Dec 2003 14:16:30 -0500 To: Rodney Thayer X-Mailer: Apple Mail (2.606) Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.157197 Spam-Alum-Trained: Yes cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 08 Dec 2003 19:15:50 -0000 On Dec 08, 2003, at 13:35, Rodney Thayer wrote: > At 01:16 PM 12/8/2003 -0500, RJ Atkinson wrote: >> It is untrue that DES "always had only quasi-official status". > > I didn't say DES. I said 3DES. 3DES has also been a US Government standard for years and included in ANSI standards for years, so it has "official" rather than "quasi-official" status going back quite some while now. >> DES has always been an official US Government standard (specifically >> a Federal Information Processing Standard or FIPS) and it is >> also standardised by other governments. > > And 3DES hasn't had a FIPS number, until recently, I believe. ANSI has specified 3DES for years in its financial standards, which are very much official (ANSI is recognised by ISO even), and FIPS is not the only form of US Govt standard. FIPS, by itself, is "official" rather than "quasi-official". So my original comments were entirely correct. Ran rja@extremenetworks.com From uri@lucent.com Mon Dec 8 14:26:33 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB8JQW5K011932 for ; Mon, 8 Dec 2003 14:26:32 -0500 (EST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163])hB8JRFXE001934 for ; Mon, 8 Dec 2003 14:27:15 -0500 (EST) Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) ESMTP id hB8JR6008593 for ; Mon, 8 Dec 2003 13:27:07 -0600 (CST) Received: by nwmail.wh.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id hB8Hkc403849; Mon, 8 Dec 2003 12:46:38 -0500 (EST) Received: from lucent.com by nwmail.wh.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id hB8Hkaq03840; Mon, 8 Dec 2003 12:46:36 -0500 (EST) Message-ID: <3FD4B8FB.5060201@lucent.com> Date: Mon, 08 Dec 2003 12:46:35 -0500 From: Uri Blumenthal Organization: Lucent Technologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en-us, en, ru MIME-Version: 1.0 To: jari.arkko@piuha.net Original-CC: saag@mit.edu Subject: Re: [saag] 3DES vs. AES References: <4775C486-285C-11D8-9839-000A95A27482@stortek.com> <3FD2F380.3040901@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Spam-Alum-Prob: 0.003245 Spam-Alum-Time: 0.705391 Spam-Alum-Trained: Yes cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 08 Dec 2003 19:26:34 -0000 On 12/7/2003 4:31 AM, Jari Arkko wrote: > My preference is a MUST for AES. I support. From tytso@thunk.org Mon Dec 8 14:36:03 2003 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB8Ja15K012187 for ; Mon, 8 Dec 2003 14:36:01 -0500 (EST) Received: from thunker.thunk.org (thunk.org [140.239.227.29]) hB8JahXE009545; Mon, 8 Dec 2003 14:36:43 -0500 (EST) Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1ATRB5-0003Vx-00; Mon, 08 Dec 2003 14:36:20 -0500 Received: from tytso by thunk.org with local (Exim 4.24) id 1ATRB3-0006xC-QY; Mon, 08 Dec 2003 14:36:17 -0500 Date: Mon, 8 Dec 2003 14:36:17 -0500 From: "Theodore Ts'o" To: "Steven M. Bellovin" Subject: Re: [saag] 3DES vs. AES Message-ID: <20031208193617.GA26521@thunk.org> References: <20031208154715.GI887@binky.central.sun.com> <20031208164945.E13607B43@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031208164945.E13607B43@berkshire.research.att.com> User-Agent: Mutt/1.5.4i Sender: "Theodore Ts'o" X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Spam-Alum-Prob: 0.000004 Spam-Alum-Time: 1.382466 Spam-Alum-Trained: Yes cc: Matt Crawford cc: james hughes cc: saag@mit.edu cc: "Philip J. Nesser II" X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 08 Dec 2003 19:36:03 -0000 On Mon, Dec 08, 2003 at 11:49:44AM -0500, Steven M. Bellovin wrote: > This is the question we really need to focus on -- do we have to have > two mandatory-to-implement algorithms to help guard against > specfication or implemenation bugs? Well, in the case of Kerberos V5, a specification error in RFC 1510 where an encryption type was not specified in a PDU where it desperately needed to be specified was not specified until the first time we tried to use an alternate encryption type, forcing us to change how we interpreted key types and encryption types (observation: trying to have as a separable concepts key types and encryption types, and the concept that there could be multiple valid combinations of key types and encryption types was a really bad idea; it's a great idea from a computer science point of view, but terrible idea from a computer engineering point of view...). So arguably, if you don't test support for multiple encryption types, you run the very high risk of something not being right. Does that mean that there must be two mandatory-to-implement algorithms? Not necessarily, as long as *someone* actually attempts to implement one or more optional algorithms as well as the mandatory ones, and tests to make sure the protocol actually works as designed... - Ted From phoffman@imc.org Mon Dec 8 14:40:49 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hB8Jel5K012317 for ; Mon, 8 Dec 2003 14:40:47 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) hB8JfTrs014218 for ; Mon, 8 Dec 2003 14:41:30 -0500 (EST) Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8JfRic058700 for ; Mon, 8 Dec 2003 11:41:27 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20031208193617.GA26521@thunk.org> References: <20031208154715.GI887@binky.central.sun.com> <20031208164945.E13607B43@berkshire.research.att.com> <20031208193617.GA26521@thunk.org> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 8 Dec 2003 11:43:32 -0800 To: saag@mit.edu From: Paul Hoffman / IMC Subject: Re: [saag] 3DES vs. AES Content-Type: text/plain; charset="us-ascii" ; format="flowed" Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.055045 Spam-Alum-Trained: Yes X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 08 Dec 2003 19:40:49 -0000 At 2:36 PM -0500 12/8/03, Theodore Ts'o wrote: >So arguably, if you don't test support for multiple encryption types, >you run the very high risk of something not being right. Does that >mean that there must be two mandatory-to-implement algorithms? Not >necessarily, as long as *someone* actually attempts to implement one >or more optional algorithms as well as the mandatory ones, and tests >to make sure the protocol actually works as designed... Given that vanity crypto is on the rise (again, sigh), this seems likely to happen. --Paul Hoffman, Director --Internet Mail Consortium From fluffy@cisco.com Fri Dec 26 15:06:33 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id hBQK6W11016908 for ; Fri, 26 Dec 2003 15:06:32 -0500 (EST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) hBQK6U2n012968 for ; Fri, 26 Dec 2003 15:06:31 -0500 (EST) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 26 Dec 2003 12:09:29 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hBQK4NQu015845 for ; Fri, 26 Dec 2003 12:04:24 -0800 (PST) Received: from [192.168.0.4] (sjc-vpn3-230.cisco.com [10.21.64.230]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALA44665; Fri, 26 Dec 2003 12:04:23 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 26 Dec 2003 12:04:21 -0800 Subject: Re: [saag] 3DES vs. AES From: Cullen Jennings To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Spam-Alum-Prob: 0.000052 Spam-Alum-Time: 0.550001 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 26 Dec 2003 20:06:33 -0000 I'm in favor of AES for new protocols and sadly this belief has little to do with the relative properties of the two. For whatever reasons, a very significant portion of customers that buy crypto related equipment demand AES, the bulk of the rest seem happy with AES thought they may be happy with other things too. When I do a poll of what crypto would be acceptable for users of VoIP equipment, AES is the clear winner. Some of these users know nothing about crypto other than AES sounds cool, some of these users are pretty serious mathematicians - who am I to tell them they are wrong. Lots of implementers pretty much have to do AES and would rather not do multiple algorithms. Cullen